Interactive Application Security Testing (IAST) Tools

The security industry started on security testing automation journey almost a decade ago! First there were Static Analysis Security Testing (SAST) Tools and then there were Dynamic Analysis Security Testing (DAST) tools. Neither tools lived up to the expectations for various reasons, but primarily due to the large number of False Positives in SAST tools and difficulty automating DAST tools that require manual intervention needed to train the tool and triage results. Contrast Security was one of the early pioneers in a new space called Interactive Application Security Testing (IAST) to fill this gap! In this post we will discuss IAST tools and what they bring to the table.

Effectiveness of IAST Tools Over SAST/DAST Tools

IAST tools look to combine the best of what SAST tools and DAST tools offer, but with out the baggage these tools bring with them. The basic principle of IAST tools is that you configure your application with an IAST agent that can track the request from its “source” to the “sink” and determine is there is a vulnerability in the path due to a missing Sanitizer or an Encoder.

The agent is configured at the Runtime and has better context of the execution than a SAST tool and this allows IAST to provide better results with lower false positives compared to a SAST tool. Unlike DAST tools ISAT tools do not drive the application, but depend upon automated functional test cases or manual testing to drive the application and the agent runs in the background identifying vulnerabilities in the execution path. However, this is also a drawback of the IAST tools, in the sense that if you do not have sufficient test coverage either through automated testing or manual testing the effectiveness of IAST would be limited as the agent can only see the code that is executed. The agent does some analysis at startup, but the results you get there are comparable to what SAST tool provides. So, if you are planning to get an IAST tool, make sure that you have sufficient test coverage for your application either through automated or manual functional testing.

Does IAST eliminate manual pen testing?

This is a frequently asked question from senior management when you recommend big investment on any security tool including IAST. Although IAST offers significant improvements over traditional SAST or DAST tools, the tooling is not there at the moment to completely eliminate manual pen testing. Yes, the tools are much better now at identifying certain category of application security vulnerabilities such as XSS vulns, Injection vulns, Open Source Software vulns etc., but the tools are not able to identify vulnerabilities in business logic, back doors in the code, privilege escalation type of attacks etc. The way to look at the tools is to help you catch low hanging fruit so that you can free up pen testers to focus on more complex attacks on your applications! You need to augment security testing tools with robust code reviews and focused pen testing to fortify your application security!

Commercial IAST Tools

  1. Contrast Security is the leader in this space! Contrast has been on this journey longer than others and have improved their capabilities, language/framework coverage over the years. Contrast Security seems to check off on most of the capabilities you look for in a security testing tool! Contrast does a good job of identifying vulns in the Open Source Software (OSS) you use in your application. In addition to identifying OSS vulns, the tool would identify if you are using that component in your application. About 80% of the Open Source Software you include in your application is dead weight and is never used! So, having tool that would help you identify if you are using a vulnerable OSS component is a big win for prioritizing fixes for your OSS components!
  2. Seeker from Synposys is another IAST tool for you to consider! Seeker differentiates itself in this space by not only identifying a vulnerability, but also actively tries to exploit the vulnerability thus eliminating any false positives reported by the tool. The advantage with Seeker is that it is part of Synopsys that offers broad range of security testing tools: Coverity for SAST, BlackDuck for OSS scanning, Seeker for IAST. As Synopsys integrates these products and matures the platform, you will have single pane of glass for vulnerabilities reported across SAST, DAST, OSS, and IAST tools. Isn’t that an appealing proposition?
  3. Veracode and Checkmarx are on the early stages of building out IAST capabilities on their platforms. Watch out for updates from these vendors. The competition will only make the products better and will be win-win for the Consumers!

Trust, but verify your IAST Tools!

IAST is a Runtime tool, so you must verify that the agent is compatible for the languages, frameworks and libraries that you use including the specific versions that you use. Unlike a SAST tool where you may get partial coverage depending on how much code you throw at the SAST tool, IAST tool may be “all” or “nothing” if the tool is not able to detect “sources” and “sinks” in the versions of languages/frameworks that you use. So, it is imperative to evaluate the tool within your environment!

In Conclusion

If you budget for only one testing tool Test, I would strongly encourage you to consider IAST! But also be aware of the pitfalls of IAST:

  • Verify the tools in your enviroment for the languages/frameworks and the versions you use
  • Make sure you have effective test coverage in your organization via automated or manual pen testing. IAST is only as good as the test coverage!

 

Advertisements

SAST: Static Code Analysis to identify Security Vulnerabilities

What is SAST?

SAST stands for Static Application Security Testing. Before ShiftLeft became fashionable, security companies were thinking wouldn’t it be better to identify security vulnerabilities while the Developer is writing the code as opposed to later in the process. What a futuristic thought?

Static Application Security Testing (SAST) tools analyze source code or compiled code to identify security vulnerabilities. The intent of SAST tools is to Shift Security Testing to the left and allow Developers to scan code, identify and fix vulnerabilities during the software development process. SAST solutions have been available in the industry for 10+ years. Fortify, AppScan, Checkmarx, Veracode are some of the leading commercial SAST providers. There are mature Open Source tools and frameworks such as SonarQube, FindSecurityBugs, PMD, that have plugins/rules to scan for security vulnerabilities and the tools allow you to implement custom rules applicable for the software languages and frameworks used in your organization.

How do SAST tools analyze the code?

SAST tools are very effective at identifying the use of insecure APIs.  For e.g.,

  1. Use of Dynamic SQL that could lead to SQL Injection vulnerabilities
  2. Insecure use of Encryption & Hashing APIs such as the use of weak encryption and hashing algorithms
  3. Information disclosure with logs and stack traces emitted to stdout, stderr
  4. Use of deprecated APIs that are vulnerable

The commercial SAST tools provide deeper analysis by building Data Flow Analysis wherein the tools build a model of untrusted inputs from Source (say HTML Form) to a Sink (say a Database). SAST tools than analyze the Data Flow models to identify if the untrusted input is properly sanitized with input validations and output encoding to defend against Injection and XSS type of attacks. The tools allow you to customize the sanitizers to account for your custom libraries to whittle down false positives.

The SAST tools either consume raw source code or Binary code for analyzing the code.

Open Source Tools are very good in identifying vulnerabilities in the first category but fall woefully short in doing complex Data Flow Analysis that span multiple modules.

Coverage and Effectiveness of SAST Tools

The advantage of using SAST tools is that they offer coverage across many categories and industry standards such as OWASP Top-10, SANS 25, PCI DSS, HIPAA, CWEs etc across many languages and frameworks. Some organizations use SAST as a mechanism to be compliant with regulatory requirements such as PCI DSS.

Most of the tools have coverage for Java, JavaScript, .NET, Mobile (iOS & Android), Python, Ruby etc. and the vendors keep adding support to new and upcoming languages such as Go.

You can think of SAST as offering coverage that is mile wide but only an inch deep! The tools are very noisy and produce false positives. Don’t be under the impression that you can drop these tools in your environment and run them on autopilot! This will only drive Developers away from adopting these tools and lose goodwill with them! You need to spend time and resources training the tools by creating customizations that apply for the languages, frameworks that are used in your organization! For e.g., if you have custom input validators, you need to train the tool to recognize these validators or else the tool would report false positives in injection vulnerabilities.

SAST Tools Evaluation Criteria

Given the number of commercial tool vendors, what are some of the considerations for evaluating and selecting a SAST tool? I would rate the tools based on the following criteria:

  1. Does the tool cover the languages and frameworks used in your organization?
  2. Does the tool cover industry vulnerabiltiy categories such as OWASP Top 10, SANS 25, PCI DSS etc?
  3. Is the tool customizable to limit false positives being reported?
  4. Does the tool provide mitigation guidance and is the guidance customizable?
  5. Does the tool integrate with Build Pipeline to automate static analysis during Build time and fail the build if based on preset policies?
  6. Does the scan performant? Especially, if the tool is integrated into the pipeline, the scans have to be performant. Does the tool allow incremental scans to speed up the scans?
  7. Does the tool have an IDE plugin that integrates with the Developer IDE and allows the Developer to scan code during Development and consume the scan results from your Build Pipeline scans?
  8. Is there a usable dashboard and reporting capability that allows your Security team to identify vulnerable applications and work with the application teams to mitigate the vulnerabilities?
  9. Does the vendor offer on-demand training or coaching is the Developer needs further assistance?
  10. Does the tool integrate with Bug tracking systems such as Jira and productivity tools such as Slack or ChatOps?
  11. Does the tool integrate with your Authentication and Authorization systems?

The vendors demonstrate their tools with readily available vulnerable applications such as WebGoat. OWASP Benchmark project also provided a suite of test cases and code to help evaluate these tools. The project also ranks open source SAST tools and commercial SAST tools although they do not call out the commercial tools due to licensing constraints.

In my opinion, the tools are highly tuned to work for test apps such as WebGoat and the best way to evaluate a tool is to throw a variety of applications that you have in your organization against the tool and see what you get!

In Conclusion

Given the coverage and effectiveness shortfall associated with SAST tools, is there a place for SAST tools in your Development process? I believe there is value in having SAST tools in your arsenal. But, instead of looking at SAST tools as the be all and end all, I would consider using SAST tools as guardrails that can help Developers avoid common security anti-patterns and adhere to secure coding practices!

If your organization does not currently use SAST tools, there is no reason for not adopting Open Source Tools that are free and make them available for your Developers today!

 

 

Error Handling: Prevent Information Disclosure

Are your developers handling unexpected server side errors? If server side error handling is weak, attackers can gain insights in to the technology stack being used in your applications and use that information to exploit known vulnerabilities in the technology stack as reported on National Vulnerability Database (NVD).

Typically un-handled server side errors bubble up as stack-traces, default error pages disclosing web server/app server names, version numbers etc. If an attacker were to know that your application is using Apache Structs 2, the recent OS Command Injection vulnerability disclosed in Apache Structs2 provides an easy attack vector for an attacker to compromise your application. Why would you let anyone know that you are using Apache Struts with lax error handling?

What are the common techniques used for error handling in applications?

Exceptions can happen in any tier of your application – UI/Mid-tier/Data-tier. Typically any modern language offers try/catch/finally to handle exceptions. Also, the web tier offers configuration to handle any uncaught exception and display generic error messages when un-handled exceptions are raised in code. Although configuring the web tier to handle un-handled exceptions provides you the safety net, educate your developers to handle exceptions in all tiers of the code. In addition to helping prevent information disclosure, having  proper exception handling logic allows your application to gracefully fail and provide debug information in the logs to help you triage those stubborn issues that typically only happen sporadically in production environments.

OWASP also provides guidance on exception handling that is worth giving a quick read.

No body wants to see stack-traces reported on their web sites, which is a bad user experience, but on top of that you are providing valuable information to attackers. This is an easy one to fix with proper education to your Development teams !

 

OWASP (Open Web Application Security Project)

I recently came across this Blog on AppSec related topics at https://appsecfordevs.com. I found the articles to be very pertinent and helpful to me. Please take a look at this Blog is you are in the Application Security domain.

AppSec For Devs

If you are new to Application Security domain, OWASP has a treasure trove of information on getting you started on path to a great career in application security as a Security Architect, Penetration Tester, Security Assurance Engineer etc. The OWASP Website is located @ https://www.owasp.org/index.php/Main_Page

Some of the main things that I learnt from the OWASP Website are:

  1. Top 10 Web Application Vulnerabilities that are published every 3 years. This list allows you to prioritize your dollars on what defenses you need to build for securing your web application assets. They have recently released the Release Candidate for 2016 OWASP Top 10. The additions to the 2016 list are: a) Automated detection and remediation of vulnerabilities. b) Lack of sufficient security controls in APIs (for e.g. REST APIs). I agree that most organizations that are re-architecting their sites using REST/CSA technologies are missing basic security controls such as authorizations, output escaping…

View original post 229 more words

Open Source Software (OSS) – Do you know what you are vulnerable to?

Do you know what percent of software that runs in your application is Open Source libraries?

Do you know if your application is vulnerable because you are using a version of OSS library that is old and has known vulnerabilities?

Are you still writing custom software for your plumbing code instead of using OSS libraries?

If you answered “yes” to any of these questions, you have some work to do, my friend !

If you answered “yes” to the last question, you must be either working for Microsoft or wasting your organizations resources on something that you could get for free, and probably better software than what you could write yourself.

In any case, a large number of organizations: (a) use OSS libraries in their custom software development;  (b) have OSS libraries in their environment from commercial products they use

You can take the time to query CVE Database for the OSS libraries that are in your environment. This is obviously tedious with 1000’s of libraries and various versions that you need to keep track.

There are commercial vendors out there who offer products that solve this problem for a fee. Some of the well known vendors in this space are:

  1. Nexus Lifecycle from Sonatype
  2. Blackduck

OWASP has a free version “OWASP Dependency Track Project

Although the free version has limited capabilities, it is a pretty good start if you are constrained by resources. However, the commercial products provide extensive coverage of the OSS components you use in your organization across Licence management, Vulnerabilities and Architecture.

The capabilities provided by commercial tools and make case for your dollars are listed below:

  1. Scan for OSS components with know vulnerabilities during development or build pipeline with IDE Plugins and CI/CD integration plugins
  2. Set policies to fail builds in CI/CD if OSS components fail compliance against enterprise policies
  3. The products provide coverage for Licence compliance, Vulnerability checks, and compliance with Architecture policies
  4. The products allow automation of your OSS procurement process by blocking download of OSS components with know vulnerabilities and fail compliance against set policies
  5. Dashboard of your OSS vulnerability posture
  6. Integration with Bug tracking tools for resolution
  7. Real time updates if your apps are using OSS components that have zero day vulnerabilities

If your organization is using Sonatype products such as SonarQube, Nexus Pro, etc., OSS Scanning products from Sonatype: Nexus Lifecycle and Nexus Firewall provide efficiency of integration in to the echo system. The Developers can have better user experience with tool set and that is more than half the battle getting developers to consume findings from Security products.

Please share if your organization is using any of these products or others to keep a health check on the OSS libraries that you have exposure to in your organization.

OWASP (Open Web Application Security Project)

If you are new to Application Security domain, OWASP has a treasure trove of information on getting you started on path to a great career in application security as a Security Architect, Penetration Tester, Security Assurance Engineer etc. The OWASP Website is located @ https://www.owasp.org/index.php/Main_Page

Some of the main things that I learnt from the OWASP Website are:

  1. Top 10 Web Application Vulnerabilities that are published every 3 years. This list allows you to prioritize your dollars on what defenses you need to build for securing your web application assets. They have recently released the Release Candidate for 2016 OWASP Top 10. The additions to the 2016 list are: a) Automated detection and remediation of vulnerabilities. b) Lack of sufficient security controls in APIs (for e.g. REST APIs). I agree that most organizations that are re-architecting their sites using REST/CSA technologies are missing basic security controls such as authorizations, output escaping etc., making them susceptible to attacks.
  2. Cheatsheets that are provided explain the attack vector, defenses to mitigate the vulnerability and verification of the mitigation are very useful for any application developer. XSS Cheatsheet can be found here. Scroll to the bottom to find cheatsheets for other categories of vulnerabilities.
  3. Open Source tools and libraries such as ZAP Proxy, ESAPI, CSRF Guard, Anti-Samy have been invaluable to me. These tools and libraries have wide exposure and used by security professionals there by providing the assurance that they have been sufficiently vetted for security vulnerabilities. ESAPI has input validation, output escaping and decoding routines that come in handy for any developer.
  4. One of the most recent OWASP projects that I am interested in is OWASP Benchmark that evaluated and published Security Testing Tools for their efficacy, coverage, false positives to false negative ratios allowing you to compare various tools and services that are available in the market place.
  5. I have extensively used OWASP Webgoat for learning when I started on the career path as an Application Security professional. I used the app to evaluate various security testing tools and last but not least teach application security vulnerabilities and mitigations for Development teams.
  6. Last but not least, explore the full range of projects that the OWASP community has made available for helping you secure you web application assets.