Through the Executive Lens: Prioritizing Application Security Vulnerabilities


It’s an old axiom in the security business that your security is only as good as your weakest link. Today, as the number of security threats and attack vectors continues to grow, so too does the number of tools security teams have at their disposal to find and block them. Also growing is the pile of data that security teams must sift through to identify where their systems might be vulnerable. Given all the data, how do you prioritize your efforts?

First, a couple of statistics. According to Tim Clark, SAP contributor to Forbes, 84 percent of all cyber-attacks are happening on the application layer. The 2018 Verizon Data Breach Investigations Report (DBIR) states that web application attacks were responsible for 38 percent of data breaches. And an IBM white paper states that “the costs of discovering defects after release are significant: up to 30 times more than if you catch them in the design and architecture phase.” Conclusion: Start by focusing on your application security initiatives.

Within the AppSec space, the variety of vulnerability analysis tools fall into two broad groups: tools that analyze your source code and tools that do dynamic analysis. Each tests for a different type of vulnerability, so a portfolio approach to using them will give you the most comprehensive results—and the most data to sift. You can narrow your focus and prioritize issues in a number of ways.

IDE tools

Use source code scanning tools that integrate with the tools your developers use every day, like their integrated development environment (IDE). Some static analysis tools have IDE plug-ins that let your developers do vulnerability analysis directly in the IDE.

This approach to “shifting security left” in the software development life cycle (SDLC) has several benefits. One is that it distributes the load of looking at vulnerabilities across the entire development organization and makes the team more aware of developing secure code as part of their daily job. Second, it reduces the total number of security issues that make it into the code to be scanned at CI/CD build time.

Whichever tool you pick, be sure that the developer scans use the same engines as the central scans. Otherwise, correlating results across the two scan types won’t work well. And if that plug-in supports multiple analysis types, so much the better.

False-positive rate

Choose vulnerability scanning tools with low false-positive rates. Not only do false positives increase the volume of data to sift through, but too many false positives in a developer’s queue breeds malaise and disinterest in fixing them.

Developer training and measurement

Add security training to your developers’ personal development goals, and measure security issues as part of their MBOs. Learning about common vulnerability types, such as cross-site scripting, will make the team more efficient. Adding metrics around software security as part of a team’s MBOs will ensure that developers treat security on par with quality and feature delivery. Nothing changes behavior more than a combination of incentives and measurement by one’s boss.

Risk correlation

This one is harder than you might think. Several tools let you aggregate the results from different tools into one view showing the risk profile of a given app based on those results. The challenge is in correlating data that comes from different tools, each with its own categorizing methodology. Ideally, you’d have a tool that normalizes the results across tools and lets you filter issues based on things like security category and industry standards, such as the OWASP Top 10 or CWE categories.

A few tools offer other features, such as showing open/closed issues over time so you can see progress, and the ability to filter results from one tool by the results of another. For example, if your static analysis tool says you’ve got 1,000 issues, but your open source scanning tool reports that 800 of those are in open source components, your developers can focus on fixing the 200 that you know are uniquely in your source code.

Summing it up

The work of the security team is never done, but by focusing on specific AppSec initiatives and applying some well-tested strategies and tools, you can do a lot to prioritize the most important issues to focus on.

About the author: Neal Goldman is Senior Product Manager at Synopsys, with over 25 years of product management, marketing, and business development experience at a variety of technology vendors.

 

Copyright 2010 Respective Author at Infosec Island via Infosec Island Latest Articles "https://ift.tt/2U2DImb"

Comments

Popular posts from this blog

Evernote cuts staff as user growth stalls

The best air conditioner

We won't see a 'universal' vape oil cartridge anytime soon