SECURITY INFLUENCERS BLOG

Security influencers provide real-world insight and “in-the-trenches” experiences on topics ranging from application security to DevOps and risk management

START FREE TRIAL

When Legacy Application Security Becomes Your “Mr. Hyde”

Agile and DevOps are critical linchpins in digital transformation. Agile focuses on the development life cycle of modern software development life cycle (SDLC), whereas DevOps spans across development, testing, and operations life cycles. Enterprises recognize their importance and have rapidly adopted one or both—enabling development teams to accelerate their code development and release cycles. But the deployment of more software and the evolution of existing software places significant constraints on decades-old application security approaches. Legacy application security testing and scanning tools were simply not built for modern SDLC—Dr. Jekyll has transformed into Mr. Hyde for many organizations.

Penetrating Testing Challenges

Dating back decades, penetration testing occurs to the “right” in the development life cycle and is comprised of intentional, simulated cyberattacks aimed at testing the fitness of applications. Ethical hackers leverage schemes and tools to assail networks and applications in an effort to preclude falling victim to cyberattacks after deployment.

Yet, because penetration testing tools are used at the end of the SDLC, the time required to triage, diagnose, and remediate the potential vulnerabilities that are found often spirals out of control. Research shows that vulnerabilities found in testing cost 10x more to fix than those detected in coding (Table 1). Waiting until beta is 19x more and until the actual release is 29x more.

sdlc-vulnerabilities

[Table 1] The further right that vulnerability fixes shift in the SDLC, the higher the cost.

Application Security Testing Challenges

Application security scanning tools, such as static application security testing (SAST) or dynamic application security testing (DAST), involve running source code through software that seeks out potential vulnerabilities that could be exploited by attackers. The time required to run application security scans can be a significant time requirement. For organizations using Agile and DevOps where release cycles occur daily or every few days, this presents a significant challenge; running security scans that take hours to complete every day or two consumes valuable time and resources.

But running the application security scan is just the start of the work for the security and development teams when it comes to application security scanning. Application security specialists must compile large quantities of data and manually evaluate it, triage and diagnose the scanned data, identify the root cause of vulnerabilities, and verify remediation fixes (including if any bugs or vulnerabilities occurred as a result of the vulnerability remediation).

Too Many Tools Contribute to Complexity and Inefficiencies

Those teams charged with application security must manage multiple scanning and penetration testing tools, most of which do not integrate and reside on islands that must be manually connected through application programming interfaces (APIs). Over two-thirds of organizations report their security team spends more time managing security tools than effectively defending against threats.

Security tool sprawl certainly extends to application security, with many organizations using SAST, DAST, and software composition analysis (SCA) tools that are connected through an API to a security information and event management (SIEM) solution for aggregation of findings. And the tool sprawl situation is getting worse, with security teams adding more tools for API security, microservices security, and other niche application security areas. Even more concerning is the fact that only half of organizations report their application security toolsets are integrated into their continuous integration/continuous deployment (CI/CD) pipeline (see Table 2). This disconnect creates more development inefficiencies, delays, and ultimately risk.

ci-cd-pipeline-integration

[Table 2] Most organizations use multiple application security tools, with many lacking CI/CD pipeline integration.

Application Security Specialists Are Hard to Find and Retain

Putting aside for the moment the amount of time required to manage all of these processes, finding, hiring, and retaining the application security specialists needed to manage this life cycle of activities can be a significant challenge for organizations. Cybersecurity in general is facing a serious deficiency of skills and professionals. The global security workforce is now estimated at more than 4 million, with 65% of companies currently reporting the need for skilled staff in critical areas.

Complicating matters is the resulting outcomes of the pandemic. In the aforementioned Contrast Security survey, more than two-thirds of respondents indicate they need to add more application security staff. Yet, less than one-quarter say they are able to do so—27% indicate they need to do so but cannot find a suitable candidate, while 18% admit they cannot currently hire.

The typical tenure for an application security engineer is less than one year.

When it comes to application security, potential outcomes of the skills gap and shortage include release delays and product degradation—analyst investigations take longer, remediation steps get missed and become more complex, and incident response gets postponed. The cybersecurity gap is translating into tangible impact, with half of organizations directly tying it to higher risk (moderate or extreme). And application security is named as one of the areas where the gaps are the most glaring. 

Legacy Application Security Translates Into More Time and Cost

Manual processes are a critical contributing factor. The time it takes application security specialists to compile and organize penetration and scanning reports is substantial. The amount of time it takes to run scans and prepare the results into actionable intelligence grows as the frequency of scans increases—and organizations are not pleased with the outcome: Only 10% believe they are resolving critical vulnerabilities in an efficient manner.

Organizations that have embraced Agile and DevOps are conducting penetration tests and scanning for vulnerabilities on a much more frequent basis—and the resulting reports that must be compiled are growing in size and scope. This growth in frequency means the number of vulnerabilities—or purported vulnerabilities—that require triage, diagnosis, and remediation are skyrocketing. Thus, it should be no surprise that more than one-quarter of organizations indicate they fix vulnerabilities once a day; nearly 60% fix vulnerabilities a couple times per week.

70% of CIOs report their teams spend more than half of their time finding the cause before they’re able to fix system problems.

Admittedly, it takes a lot of time to manually sort through lengthy reports and to compile them into something that can be used. In a recent report, 70% of CIOs indicate their teams spend more than half their time finding the cause before they are able to fix system problems.

Manually triaging, diagnosing, and remediating vulnerabilities compounds the problem. In regard to the latter, because penetration testing and scanning tools—both SAST and DAST—rely on signature-based engines and do not analyze vulnerabilities based on whether they are exercised by the application in question, they generate large piles of false positives. Indeed, application security specialists can spend upwards of one-quarter of their time triaging and diagnosing false positives.

Implications of False Negatives That Shift Right

On a similar note, application security scanning is known to generate false negatives—missed vulnerabilities that often do not get fixed until production. However, as discussed above, vulnerability fixes in production are upwards of 29x more than if they were fixed during coding (see Table 1). Indeed, nearly 30% of organizations in the survey Contrast Security just completed indicate it takes more than 15 hours of their security operations (SecOps) team to triage, diagnose, and remediate a vulnerability in product—and this does not include the time required of developers (see Table 3).

In addition to the cost and time factors of vulnerabilities in production, risk is also an important concern factor. While 98% of application vulnerability attacks never hit a vulnerability, the 2% is still something organizations must heed—particularly considering the fact that individual applications receive an average of 13,000 vulnerability attacks each month.

vulnerability-shifts-right

[Table 3] When vulnerability remediation shifts further right, the time required to fix the vulnerability increases exponentially.

Reinventing Decades-old Application Security

Modern SDLC offers organizations significant opportunities; applications enable the digital interactions that are critically important. However, organizations will be unable to realize the full potential of these digital transformation efforts unless they evolve to a different application security approach—legacy solutions simply cannot scale to meet the demands of modern SDLC. An application security approach that embeds security instrumentation within the software and takes an inside-out view—contra legacy application security that employs an outside-in model—transforms security from a business inhibitor to a business enabler.

For more information on how to ensure your legacy application security does not turn into Mr. Hyde, register to attend our upcoming webinar, “Digital Transformation Thwarted: When Your AppSec Tools, Scanning, and Resources Become Your Mr. Hyde.”

 

 

Patrick Spencer

Patrick Spencer

Patrick Spencer (Ph.D.) leads the content marketing and PR/Communications team at Contrast. He has nearly a decade and a half of experience in various senior marketing roles within the cybersecurity sector and is the recipient of numerous corporate and industry awards. After leaving the corporate world to start his own agency several years, Patrick joined Fortinet to lead content marketing and research. His many duties included serving as the editor in chief for The CISO Collective. Patrick’s roots in cybersecurity go back to Symantec, where he spent nearly a decade in senior marketing roles of increasing scope and responsibility. While at Symantec, he served as the editor in chief for CIO Digest, an award-winning digital and print publication containing strategies and insights for the technology executive. In addition to the above roles, Patrick has also served in various senior- and executive-level marketing capacities at several SaaS-based marketing companies.

SUBSCRIBE TO THE BLOG