Incident response found its way into our technological vernacular back in 1988 when the first internet worm—dubbed “The Morris Worm”—was released. In response, the Computer Emergency Response Team/ Coordination Center (CERT/CC) by DARPA was formed.
The goal of this nascent organization was to provide a central hub for communicating and coordinating a response to security incidents. In a nutshell, the goal of incident response is to quickly contain and mitigate an incident, with an impetus to limit damage while reducing recovery time and costs.
Incident Response Remains a Significant Challenge
A recent report published by Dark Reading in concert with several technology companies such as Palo Alto Networks, “How Enterprises Respond to the Incident Response Challenge,” seeks to understand the practice of incident response across enterprises. Some of the questions the report explores include:
- How enterprises are building their incident response teams and processes
- How they are responding to new breaches
- How potential compromises are detected
- What tools and processes they use to remediate problems and improve their cyber defenses in the future
One key takeaway from the report is that security leaders appear to overestimate their ability to detect and respond to security incidents. The implication is that security incidents take longer to remediate as well as require more time and resources. And the longer it takes to remediate a malicious event, the greater spread and detrimental impact across an organization. Indeed, research shows that successful intrusions require an average of 20 minutes before a malicious breakout occurs. Yet, half of organizations worldwide take 78 or more days to even detect a breach.
Closing the “gap” with more security headcount is not the answer. According to the latest cybersecurity workforce study by (ISC)2, almost two-thirds of organizations report a shortage of cybersecurity staff, and more than one-third disclose that lack of skilled or experienced security personnel is their number one workplace concern.
When it comes to security incidents and their prevalence and frequency, security vulnerabilities in systems, applications, or the network are cited as one of the top three most common security incidents by 21% of respondents. Only phishing (35%), ransomware (27%), unsuccessful login attempts (27%), and malware attacks on security tools (26%) were listed more often.
Application Vulnerabilities Grow in Concern
One of the areas of exploration in the report includes what actually constitutes an incident response. Compared with 2019, 2020 responses reveal, in general, an increase across all categories, thus reflecting an ongoing maturation of security in organizations and widespread consensus that the volume of malicious attacks continues to climb.
For example, the report shows anomalous use of an organization’s internal systems, applications, or networks grew from 43% in 2019 to 69% in 2020, and a suspected case of unauthorized use of applications or data by an employee or other credentialed user jumped from 46% in 2019 to 66% in 2020.
Furthermore, multiple unsuccessful attempts to log into a system, application, or network grew from 35% in 2019 to 54% in 2020, a further reminder that probe attempts, while not causing real damage, can result in an actual attack exploit if successful.
Incident Response and AppSec
Taking an audit of the most common types of security incidents provides an at-a-glance view of attack vectors and methodologies. Understanding the various forms of attacks (probes or true exploits) helps identify system weaknesses and potential entry points, including third-party risks, with only 41% of organizations intermittently keeping in touch with business partners on incident response matters.
An audit also helps security teams with budget allocation and securing leadership engagement, especially when managing sensitive data such as personally identifiable information (PII) that can be an attractive target for ransomware attacks. With privacy regulations and legislation such as the European Union’s General Data Protection Regulation (GDPR) and California Consumer Privacy Act (CCPA) mandating stiff penalties and fines for compliance violations, organizations must carefully heed security controls and best practices.
And because applications store as well as transact data, which passes through application programming interfaces (APIs) and in and between on-premises and cloud environments, security and development teams must heed these requirements carefully. A good starting point for many is the National Institute of Standards and Technology (NIST) SP 800-53 requirements, especially the new standards around interactive application security testing (SA-11[9], IAST) and runtime application self-protection (SI-7[17], RASP).
Per the report findings, most organizations may be dangerously overestimating their ability to detect security incidents. Over 36% of respondents find it difficult to determine the extent of an incident. For attacks and successful intrusions in runtime, the amount of time and resources needed to identify the underlying vulnerability and then verify its remediation can be substantial. This directly impacts both development and security teams, slowing code commits and release cycles while degrading efficiencies.
In addition to the above, false positives are listed in the report as a reoccurring problem—22% cite time responding to false alerts as one of their top incident response challenges. While the study does not look into the source of false positives (e.g., email security, network security, perimeter), the problem most certainly is as great or even greater in the case of application security (AppSec). In particular, false positives resulting from AppSec not only incur significant time on the part of incident response specialists but they also have a huge impact on development teams.
The Problem of Perimeter Defenses, AppSec, False Positives, and False Negatives
Perimeter defenses—namely, web application firewalls (WAFs)—lack the application context to understand what traffic means and how the data will be used. Specifically, using JSON objects or network-optimized binary exchanges that cannot be understood due to the lack of context, perimeter defenses that rely on a single network transport inspection cannot evaluate the way data is parsed, coded, and pieced together with other parts of the application. In short, this outside-in approach lacks the context, intelligence, and visibility to accurately identify attacks that can successfully exploit an application vulnerability.
This results in false positives—and for that matter false negatives. For applications in runtime, each of the false positives is identified as an incident, requiring investigation by the incident response team. In the case of the false negatives, when they are missed, they result in successful intrusions that must be remediated by both the incident response team and development team. With the amount of time and resources required to fix a vulnerability in production being upwards of 100 times more than fixes done in development, the impact can be dramatic on an organization.
RASP as a Solution to the Incident Response AppSec Problem
So, what can be done to address this problem of false positives and false negatives and their deleterious impact on incident response? As a starting point, perimeter-based security needs to be supplemented with or replaced by a completely new approach to AppSec. Rather than trying to protect applications in runtime from the outside-in, an opposite approach is needed—from the inside-out. It also requires the use of security instrumentation that resides within the application runtime, with sensors deployed across the entire application stack.
This instrumented security model provides continuous protection so that as soon as an attack reaches a vulnerability, the RASP solution instantly blocks the exploitable runtime event without affecting the application. The new NIST standards for RASP provide the recipe for the solution:
“Runtime application self-protection technology can reduce the susceptibility of software to attacks by monitoring its inputs, and blocking those inputs that could allow attacks. It can also help protect the runtime environment from unwanted changes and tampering. When a threat is detected, runtime application self-protection technology can prevent exploitation and take other actions [e.g., sending a warning message to the user, terminating the user’s session, terminating the application, or sending an alert to organizational personnel]. Runtime application self-protection solutions can be deployed in either a monitor or protection mode.”
Incident response is a critical linchpin in how organizations manage their risk. An incident risk program that is weighed down with inefficiencies, or even alert fatigue, resulting from false positives can become a serious risk factor in and of itself. The corollary is true as well. Reducing security incidents to a much smaller list can empower and focus an incident response team, enabling them to become significantly more effective—in terms of speed and efficiency. At the same time, shrinking or eliminating the list of false negatives also has the same effects and even more so on the overall risk to an organization.
For a more in-depth examination of the challenges of perimeter defenses and AppSec, check out the white paper, “Perimeter Security Noise Leaves Applications Vulnerable to Attacks.”
