In-depth analysis comes at a cost – so does a breach!

by in CyberRes

The 2020 Verizon’s Data Breach Investigations Report (DBIR) showed that 43% of all data breaches analyzed by Verizon were the result of a web application vulnerability. This more than doubled over the previous year.

In-depth analysis comes at a cost – so does a breach

An example of how weaknesses in an application can result in a data breach was announced by KrebsOnSecurity on 28 April. It was reported that an API weakness of a partner website to Experian let anyone with a name and a mailing address look up someone else’s credit score, impacting millions of Americans. You can find examples like this incident in the news every week.

One of the trends identified in the Fortify Application Security Top Trends for 2021 White Paper is the increasing use of hyper-convenient security scanning tools that cloud platform and dev tool chain vendors are offering. Lightweight Static Analysis Security Testing (SAST) tools are leveraged by development teams to comply with security scanning requirements many times as an alternative to using more robust SAST tools like Fortify Static Code Analyzer (SCA).

So, while exploits through application vulnerabilities are on the rise, less capable SAST tools are increasingly being used to try and identify these vulnerabilities and weaknesses. Really? Seems like teams are setting their organizations up for a potential breach by taking short cuts on thorough applications security testing during development.

Why we do SAST

The purpose of SAST is to help programmers detect vulnerabilities in their software as early as possible. We are managing application risks and need visibility into application weaknesses and vulnerabilities to properly manage that risk effectively. I don’t believe we should sacrifice quality SAST scan results just to check a compliance box. When minimizing the friction of security testing to CI/CD pipelines is the allure of these hyper-convenient scanning tools, we need SAST tools like Fortify SCA that can provide low friction and high-quality scan results.

Under the Covers - How Fortify SCA Works

Fortify SCA provides accurate results and detects a breadth of issues unmatched by other static testing technologies. As Gartner said in their 2020 Magic Quadrant for Application Security Testing report, "Fortify is known for its depth and accuracy of results, which meets the needs of enterprise customers that then leverage contextual-based analysis."

But how is this done? In 2007, Fortify Founder and Chief Scientist Brian Chess co-authored the book Secure Coding with Static Analysis (available on O’Reilly). As Chess describes in chapter four, and still true to this day, at a high level, SAST tools work this way:

SAST tools work this way

Fortify SCA uses a large knowledge base of rules to model important attributes of the program under analysis. These security coding rules are expanded and updated regularly by CyberRes’ Fortify Software Security Research (SRR) team and grouped into Secure Coding Rulepacks. The Rulepacks describe general secure coding idioms for popular languages and public APIs, out of the box. Fortify SCA employs the use of eight analyzers that perform different types of analysis to detect potential security vulnerabilities in source code. After the source code is translated, SCA analyzers can use both Fortify Secure Coding Rulepacks and customer specific security rules (custom rules) to identify vulnerabilities in a codebase. 

Each analyser is designed to perform a different type of analysis. Here are descriptions of some of the analyzers:

  • Data Flow analyzer - finds security issues that involve tainted data (user-controlled input) that is put to potentially dangerous use. This analyzer uses interprocedural taint propagation analysis to detect the flow of data between a source (site of user input) and a sink (dangerous function call or operation). This analysis enables Fortify SCA to precisely identify many different types of security problems.
  • Control Flow analyzer - finds security issues in programs that have insecure sequences of operations. The analyzer models each security property as a state machine and reports a vulnerability when a state machine enters an error state.
  • Structural analyzer - matches arbitrary program constructs in source code. Unlike other analyzers, it is not designed to find problems that arise from flow of execution or data. Instead, it detects issues by identifying certain patterns of code
  • Higher-order analyzer – a sub-analyzer for a specific kind of data-flow analysis that's relevant for code highly reliant on function objects (a.k.a. lambdas). The analyzer first detects how function objects flow and then how data flows through that function object. This is incredibly important for dynamic languages like JavaScript and TypeScript, and their supporting frameworks like Node.js, Angular and React. 

Lint-like SAST tools may identify rudimentary defect detection capabilities, but you will need the techniques employed by analyzers like the ones above to provide more comprehensive security defect detection.

What about the "Noise?"

One of the concerns leveled against Fortify SAST has been that scan results can include too much “noise”, meaning too many false positives. As characterized by Chess,  

“…a false positive is a problem reported in a program when no problem actually exists.”

False positives are certainly undesirable and there are ways of filtering them within SCA. Most often these false positives stem from a matter of their context, but from a security perspective, false negatives are much worse. With a false negative, security issue exists in the scanned codebase, but the SAST tool does not report it. Back to Chess and our fundamental philosophy at Fortify,

“The penalty for a false positive is the amount of time wasted while reviewing the result. The penalty for a false negative is far greater. Not only do you pay the price associated with having a vulnerability in your code, but you live with a false sense of security stemming from the fact that the tool made it appear that everything was okay.”

All SAST tools are guaranteed to produce some false positives and some false negatives. Simplifying the developer experience and providing an easy way of meeting security testing compliance requirements is why hyper-convenient SAST tools attempt to produce a low number of false positives and are more willing to accept false negatives. We at Fortify strike a different balance between these. We believe false positives should be controlled, but false negatives would blind the organization to application risks.

Scan Speeds Still Matter

Back to the desire to have fast scan speeds to minimize friction for the development teams, but to strike the right balance between false positives and false negatives. A goal of the CyberRes Fortify team is to assist organizations in building secure software fast by automating and integrating all testing types, including SAST, throughout the CI/CD pipeline. The Fortify 20.2.0 release had a focus on getting customers faster time to value.

There were lots of core upgrades, new features, and fine tuning in this release. The results were up to 2x faster scans, 30%+ more accuracy (reduced noise), better support for modern applications, increased scalability, all while continuing to shift security left, making Fortify SCA more developer friendly.

One of the new features is a SAST Speed Dial. With Speed Dial you have better control of that balance between the speed and accuracy of your static testing by tuning the depth of the scan based on application needs. So, if you really do want to reduce the depth of a scan and increase scan speeds by 50% you can use dial settings, saving deep SAST scans for when you need them. Check out the video Control the speed of scans with Speed Dial for more on this feature.

Why In-depth Security Testing Matters

Threat actors are increasing the volume and complexity of their attacks. The penalty for overlooked application-level security defects is high and organizations of all shapes and sizes are not immune from a breach and their impact. Data collected by MetaCompliance listed these recent breaches and their estimated costs:

All of the above breaches weren’t caused by app-level vulnerabilities. However, are shortcuts in thorough application security testing worth the potential cost impact of a breach like these?

Learn more about Fortify SAST and how it provides in-depth testing of codebases at the speed of DevOps:

 

More Information

Join our Fortify Community. Have technical questions about Application Security products? Visit the Fortify discussion forum.  Keep up with the latest Tips & Info about Application Security. We’d love to hear your thoughts on this blog. Log in or register to comment below.

Labels:

Application security
Anonymous