• Skip to main content
  • Skip to primary sidebar
  • Skip to footer

DevelopSec

  • Home
  • Podcast
  • Blog
  • Services
    • Secure Development Training
    • Advisory Services
    • Application Penetration Testing
    • Application Security and SDLC Program Review
  • Resources
  • About
  • Schedule a Call

dast

June 7, 2018 by James Jardine Leave a Comment

Choosing Application Security Tools

There are lots of security tools available, so how do you know which one to pick?

If your security team is not including the application teams in the decision, you run a big risk of failure. The security team does get the ability to form relationships with vendors. We see them at conferences. We know people that work there. Because our focus is on security, we know the tools that exist in our space and we have an idea of which ones may be better than others. Of course, this is often due to what we hear from others, rather than our own experience with those tools.

Picking a tool in a vacuum is less than ideal. Sure, the tool may have five stars and has great detection rates. However, if the tool doesn’t fit into the development process and causes more overhead and friction, it will end up failing. A tool with 100% accuracy is still useless if it is not actually being used.

I have seen over and over where a security group acquires a tool, especially static analysis, and a few months later they realize it is just sitting on the shelf. Like all of us, we are excited when we get a new toy. We use it, learn it. Then, the newness wears off. Without the proper processes in place, this can happen with security tools as well. We don’t want this to happen to you.

The first step in determining which tools make sense is to understand the development process now and where it is going. Lets talk about static analysis for a moment. If your development process doesn’t make use of continuous integration and doesn’t plan to then that is not a high priority feature of the tool you receive. Have you considered what IDE the developers use?

I once had a situation where static analysis was about to be rolled out. The security team worked to pick a vendor and get the ball rolling. It was later in the process that the development team was brought on board with the conversation. They asked questions that were less of a priority to the security team, but more of a priority to them. For example, The tool provided a plugin for their IDE. However, when digging deeper, the plugin ran a few versions behind. So what had appeared to be a good setup, now looked a little less efficient since the plugin may not work. This isn’t a deal breaker, but depending on how you were planning on this solution working, it adds friction to the process. The more friction, the more pain.

The next step is understanding who will ultimately be using this tool? For those that listen to the podcast on a regular basis and follow my blogs, you know I am a huge fan of the application teams having direct access to these tools. In my opinion, static analysis is a developers tool. It is there to evaluate the source code and identify policy violations that only the developer can resolve. Giving them access and control over that function and embedding it into their process reduces that friction. Don’t confuse this with the idea that security is not getting the results. Security still needs to have insight into what is going on with security flaws within the application. But to be efficient, the results of these tools need to fit into the flow of how development works. Not be one-off reports under different processes.

This is no different, in my opinion, than dynamic analysis or interactive analysis. These are tools that should be used by the QA group. The group that is responsible for testing and most likely already has automated testing capabilities. They are trained in identifying bugs, reporting, and tracking them. Building these types of tools into their process just makes sense. How many listeners have their own stories of the security team exporting a thousand page report out of that dynamic scanner and sending it to the application team as a pdf? I have been there. Even I won’t read through that report.

The moral of the story here is that if we don’t understand how development works, what type of tools they already use, and what they can handle, we will probably pick a solution that will be ineffective, or at the very least, cause us a lot more work. The goal is not to just shove tools onto the development teams and say do this. As application security representatives, our goal is to help build better applications. That doesn’t mean that our job is to run all the tools and hound the application teams to fix items. By understanding the environments and processes we can pick tools that will fit much better, allowing us to focus our time on building out other solutions or processes for the organization. We are still relied upon to provide the expert advice and guidance to the issues that are identified.

If you are considering implementing these types of tools, take a moment to sit down with all involved parties to get everyone on board. A well laid out plan will go much further than a shotgun approach.

Filed Under: General Tagged With: application security, AppSec, awareness, dast, iast, owasp, pen testing, penetration testing, pentest, qa, sast, secure design, secure development, security, security testing, security training, testing, top 10, vendors

August 30, 2016 by James Jardine Leave a Comment

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.

Filed Under: General Tagged With: dast, developer, dynamic analysis, qa, sast, secure code, secure development, security, security expert, static analysis, training

Primary Sidebar

Stay Informed

Sign up to receive email updates regarding current application security topics.

Contact Us:

Contact us today to see how we can help.
Contact Us

Footer

Company Profile

Are you tackling the challenge to integrate security into the development process? Application security can be a complex task and often … Read More... about Home

Resources

Podcasts
DevelopSec
Down the Security Rabbithole (#DTSR)

Blogs
DevelopSec
Jardine Software

Engage With Us

  • Email
  • GitHub
  • Twitter
  • YouTube

Contact Us

DevelopSec
1044 South Shores Rd.
Jacksonville, FL 32207

P: 904-638-5431
E: james@developsec.com



Privacy Policy

© Copyright 2018 Developsec · All Rights Reserved