The Right Way To Shift Right in Application Security

Protection Must Go Where the Attacks Happen: in Production

As web applications and application programming interfaces (APIs) continue to be leading attack vectors for breaches, security leaders are seeking new approaches to stem the tide of successful attacks. There is now a consensus that applications must be protected in production as well as in development. But not all existing runtime tools are up to the task. The latest version of the Contrast Protect runtime application protection and observability solution has some unique advantages that offer security leaders a saner, smarter approach to thwarting application threats.

Security Debt Starts in Development

Application vulnerabilities in business applications are a growing component of enterprise risk. Still, most seasoned security and DevOps leaders operate under the realistic assumption that they cannot eliminate every vulnerability. So, their challenge lies in determining which vulnerabilities will go unresolved and for how long. In other words, they assume security debt, with the intention of reducing it as quickly as possible, given the constraints of the business.

The pressures to reduce security debt grow as application development evolves. In waterfall development environments, pen testing can expose critical vulnerabilities by imitating presumed attacker behaviors. But this manual, ad hoc, and expensive process could not scale with digital transformation, as agile development became more common.

So, developers began performing vulnerability scanning in development, essentially shifting application security to the left, with the aim of catching vulnerabilities early in the software development life cycle (SDLC). This is important, because the earlier vulnerabilities are exposed, the sooner security teams can analyze their criticality and make informed decisions about mitigation.

Still, security debt continues to build in development, and vulnerabilities slip into production, where they become targets for cyberattacks. In a State of DevSecOps Report, nearly every respondent admitted that the average application their organization has in production contains four or more vulnerabilities. Further, over a period of 12 months, nearly two-thirds of organizations sustained at least three attacks that successfully exploited software vulnerabilities.

Unremedied Vulnerabilities Pose Significant Business Risk

There are various reasons why vulnerabilities slip into production code. Some of these relate to deficiencies of legacy static application security testing (SAST) and dynamic application security testing (DAST) tools that produce high volumes of false positives and false negatives. Other reasons are related to the time constraints of the development teams.

To get a sense of the impact of unremedied vulnerabilities, consider a recent Ponemon Institute study commissioned by IBM, which found that 42% of respondents whose companies had suffered a breach attributed the cause to a known but unpatched security vulnerability.

By now, security leaders recognize that vulnerabilities must be addressed, not just in development but also at every stage of the SDLC. That means shifting application security efforts to the right as well, performing testing and mitigation on the runtime code, in the production environment.

Two primary challenges exist in shifting right: 1) knowing what vulnerabilities exist, and 2) knowing how to prioritize remediation efforts to ensure that all the critical vulnerabilities are fixed. These have been two persistent challenges for security leaders.

In our latest DevSecOps survey, nearly every respondent admitted that the average application in production where they work has four or more vulnerabilities, and 61% said they had sustained at least three attacks that successfully exploited vulnerabilities over 12 months.

Perimeter Tools Miss Unknown Threats

With today’s evolving threat landscape, it is impossible to identify all the vulnerabilities that may exist at the time code is released to production. A code feature can be recognized as a vulnerability only if there is a known possible exploit of that feature. So, previously unknown, or zero-day, attacks can only be mitigated, not prevented. And successful mitigation is crucial, as zero-day threats comprise upwards of 50% of all malware.

The known vulnerabilities aren’t any easier to deal with, as they are numerous and rapidly multiplying. Security teams and developers cannot realistically expect to fix them all. In order to prioritize code fixes, they need to know not only which vulnerabilities are present in the application but also which of those are likely to be exploited in production, as well as the impact of each exploit on the organization. Then, they must rely on SecOps to protect any remaining vulnerabilities once applications are in production.

To provide this protection, SecOps has long relied on perimeter-based application security solutions such as web application firewalls (WAFs), which rely on known-attack signatures to block suspicious application-bound traffic. These perimeter solutions are undeniably valuable for protecting the organization from distributed denial of service (DDoS) and other network attacks. However, they lack deep visibility into what happens when application vulnerabilities are exposed to real threats in runtime.

This makes WAFs a rather blunt tool for vulnerability protection. On the one hand, because their rules are only as current as their last update, they miss zero-day exploits. On the other hand, because the rules are signature-based, they erroneously block all behaviors that match the signature, including harmless probes. Thus, they generate a high volume of alerts, with many false positives. This leads to alert fatigue and high staff turnover, both among security teams and among developers, who have to cope with the deluge of security fixes in addition to their other development tasks.

WAFs lack deep visibility into what happens when application vulnerabilities are exposed to real threats in runtime. This makes them a rather blunt tool for vulnerability protection.

Helping Runtime Applications Help Themselves

Runtime application protection and observability has been recognized as an effective way to fill this gap. The idea is to help an application protect itself by incorporating security into the running application wherever it resides on a server. Runtime application protection and observability tools intercept calls to the application and analyze the application’s response to those calls. If the behavior is interpreted as harmful, alerts can be sent to a security information and event management (SIEM) system.

Industry standards support runtime application protection. Guidelines from the National Institute of Standards and Technology (NIST) specifically require state-of-the-art security instrumentation for “application self-protection at runtime.” Meanwhile, the latest version of the Payment Card Industry Data Security Standards (PCI DSS) includes several control requirements that security teams can satisfy with runtime application protection and observability solutions. The following are some examples:

• Control 6.5: Address common coding vulnerabilities in software-development processes.
• Control 6.6: For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks.
• Control 10.2: Implement automated audit trails for all system components.

As a pioneer in runtime application protection, Contrast has also embraced this self-protection concept. The latest evolution of the Contrast Protect runtime application protection and observability solution exceeds industry standards, both in accuracy and performance. Several key features contribute to this ability:

• Instrumentation. Using agents embedded in the application code, Contrast Protect observes potential threats in the runtime environment, analyzes their impact, and blocks and reports on any business-impacting threats. This in-context information enables SecOps teams to prioritize vulnerabilities and DevOps teams to optimally allocate resources to fix them.

• Contrast Protect employs a unique, multistep algorithm we call Runtime Exploit Prevention™ (REP) to analyze application runtime events and confirm exploitability. Then, Contrast Protect automatically blocks confirmed breach attempts during real-time code execution. This significantly improves the likelihood of thwarting zero-day attacks.
  For example, if a SQL injection attack alters the expected syntax of a SQL query, Contrast Protect instantly blocks this exploitable runtime event without affecting the application before a breach can occur and, optionally, sends an alert to the SIEM system. Conversely, if a SQL injection attack never reaches a SQL query, Contrast Protect recognizes this as a harmless probe, does not block it, and does not trigger a false-positive alert in the SIEM system.
  
  Because of the efficiency of the REP algorithm and the fact that the agent is embedded in the code, the detection, analysis, and blocking happen in sub-millisecond time frames, even under the heaviest attack loads. No external perimeter-based solution can match this.

• Contrast Protect agents deploy easily without requiring security or development staff to make any changes to the source code. Because it is instrumented into the runtime code, Contrast Protect stays with the code through version upgrades, ports to different operating systems, migrates to and from cloud environments, and other changes. It seamlessly scales within every instance of an application, without configuration or tuning, no matter where the application is deployed, on-premises or in the cloud.

The latest evolution of the Contrast Protect runtime application protection and observability solution exceeds industry standards, both in accuracy and performance.

Sharper Tools Lower Cost of Remediation in Production

Shifting right with runtime application protection and observability is essential, not only because a greater proportion of vulnerabilities slip into production code. It is also important due to the growth in the overall number of vulnerabilities to which applications are exposed. Most of these vulnerabilities arise in code that is custom developed for the application, though some come from open-source frameworks and libraries, which developers are increasingly using to shorten their development cycles.

The problem with assessing the risk of vulnerabilities in open-source software is that while the potential pool of Common Vulnerabilities and Exposures (CVEs) is vast, only a fraction of these CVEs actually pose a risk for any particular application. A recent Contrast study on open-source security found that the average application contains 118 third-party libraries. Yet only 38% of libraries in an application are active, and only 31% of classes in active libraries are invoked. The reality is that less than 10% of active code in an application is open-source libraries.

Only CVEs in invoked libraries and classes should be flagged as alerts in a SIEM system and prioritized for mitigation. And the only practical way to identify these CVEs is to observe the application in runtime and intelligently assess CVE risk. With its embedded agents and REP algorithm, Contrast Protect provides this nuanced insight, which maximizes security effectiveness while minimizing the impact on DevOps productivity and application performance.

In contrast to legacy perimeter-defense approaches that look at security from the outside in, Contrast embeds security within software using sensors to detect both known and unknown vulnerabilities with continuous, embedded protection and observability. To explore these issues in greater depth, check out the following resources:

Podcast: Recommendations for Protecting Applications in Production From Known and Unknown Attacks

Solution Brief: State-of-the-Art Runtime Application Protection and Observability Is AppSec Exactly Where It Is Needed—in Production Runtimes