This is an article from DZone’s 2022 Enterprise Application Security Trend Report.
For more:
A wave of cyber incidents in recent years, such as the SolarWinds supply chain attack, Accellion data breach, Exchange Server, and Log4j vulnerabilities, have exposed the “fragility” of modern businesses and the challenges in information security. The outcome of a cyber event can range from a minor business operations disruption to “crippling financial and legal costs” (Alan P., GCST). Despite how increasingly sophisticated threat actors have become, the typical attack scenarios remain the same, and thus analysts and responders can adequately address these events using previous tactics.
Effective incident response (IR) playbooks are the best antidote to unpredictable attacks. A practical IR playbook is key to stay organized and lead to minimal risk. According to Jyotsana Gupta, an “incident response is a process that allows you to respond quickly and effectively to a cybersecurity breach” (Wire19). IR playbooks enable analysts to respond to an incident consistently, ensure correct procedures are followed, and provide organizations with a roadmap to determine where processes can be automated and enhanced to improve critical response time.
What goes into creating an IR playbook? We will discuss how to design an IR playbook for an organization, covering topics such as assembling your IR team, identifying critical systems, creating notification procedures, and conducting post-incident review. For those eager to design a large-scale IR playbook, NIST and SANS are the two most popular incident response frameworks for granular IR planning approaches. While they differ in categorizing the incident response phases, both follow the same basic process.
How to Build an Incident Response Playbook
What’s your plan? While Indiana Jones might say, “I don’t know, I’m making this up as I go,” good luck trying that line on customers and regulators. To begin drafting the IR playbook, some companies require engagement from critical business units to form an incident response (IR) team, while other large organizations may already have an established, dedicated computer security incident response team (CSIRT). The core of the IR or CSIRT team will usually be IT or cybersecurity staff, and the ideal sponsor is from the C-Suite, such as the CISO, who will help empower the team with resources to act swiftly and drive accountability across the organization. Other members may be drawn from the IT operations staff, the vulnerability and risk management team, security engineers and architects, and intelligence analysts. Extended partners may include other capabilities, such as PR, HR, and legal.
Figure 1: Hierarchy of a CSIRT/IR team
Identify the Crown Jewels
The next step to the IR playbook is to identify the “crown jewels” of the organization — the critical systems, services, and operations that, if impacted by a cyber event, would disrupt business operations and cause a loss of revenue. Similarly, understanding the collected data type, how it is transmitted and stored, and who should access it must be mapped to ensure data security.
Identifying and mapping critical systems can be accomplished through penetration tests, risk assessments, and threat modeling. A risk assessment is often the first tool to identify potential attack vectors and prioritize security events. However, to achieve a proactive stance, organizations are increasingly leveraging threat intelligence and modeling to identify and address vulnerabilities and security gaps early on before a known attack occurs. The primary goal is to identify weaknesses or vulnerabilities with assets to reduce the attack surface and close all the security gaps.
This guide will focus on web application security as our attack scenario. Why web application security? Applications have become the backbone of most organizations, making web applications, websites, and web-based services a prime target for malicious threat actors attempting to exploit vulnerable application code. As is stated by Gupta:
Web applications are attractive targets for the following reasons:
- Complexity – Web applications have inherent complex source code, making it likely that an app contains unpatched vulnerabilities or is open to code manipulation.
- High-value rewards – Attackers can manipulate source code to access valuable data, including personal and sensitive business information.
- Easy execution – attacking web applications is usually straightforward with automation and large-scale attacks targeting multiple sites simultaneously (Wire19).
Understand the Threats
The next step is creating notification procedures led by the IR or CSIRT team. In the attack scenario (Figure 2), the IR team or CSIRT will often begin with basic security procedures of securing web applications, such as deploying and configuring a web application firewall (WAF) or configuring access control policies. The security team might block cyber attacks using WAF rules to block active exploits and prevent further damage.
Figure 2: Sample attack scenario response workflow
Web application configurations allow and deny access by creating policy rules in the web access layer. A baseline example is focusing on URL category filtering by creating policies:
- Allow users to access all organizations’ approved social networking sites such as LinkedIn and block other sites such as TikTok.
- Allow users to access personal email accounts but prevent sending email attachments.
When WAFs and configurations are in place, the web application is monitored for suspicious activity. The communication aspect of the IR playbook comes into play when careful logging and monitoring at the application level detect suspicious activity, such as repeated access attempts or unexpected user accounts being created. Suspicious activity is often detected using a security information and event management (SIEM) solution or through regular security testing using a web vulnerability scanner (Alan P., GCST).
After detecting a security incident, the IR team should “triage it,” meaning they should determine the appropriate action to limit short-term consequences and stop minor incidents from growing into large-scale attacks (Alan P., GCST). But what happens when the cyber event cannot be contained, and the evidence of a data breach is quickly mounting?
According to Alan P., “global cyberattacks have served as a reminder that plugging security holes is often the easiest part.” Threat actors such as advanced persistent threats (APT) don’t conduct hit-and-run attacks. These attacks “infiltrate target systems to maintain a stealthy and persistent presence. Eliminating the entry point is the start of a long and arduous process” with the IR or CSIRT team (Alan P., GCST).
Determine Communication Channels
When outages in programs or degradation of system performance occur, communication must be clear and effective. Communication will directly impact your team’s responsiveness to threats. While the CSIRT team is focused on analysis, containment, and remediation, proper incident response communications to leadership and read-in members are critical to success.
Managers should be informed of the situation and understand the implications to give their team the next steps to respond to an incident. Many users have questions such as whether the users should keep working or turn off their machines. What is worse are users unplugging machines with the belief it will stop the issue from spreading (David Landsberger, CompTIA).
The next phase is to manage staff and customers. Gupta notes:
After a data breach, there might be a legal obligation to notify data owners (i.e., per the GDPR). The jurisdiction and data class will determine whether you must report the incident to the relevant authorities and provide updates when new information is available (Wire19).
A few examples of how to communicate an incident to staff and customers include:
- An email for internal incident response
- A status page
- A message via chat channels within your team (e.g., Slack)
- Outward-facing communication with clients and customers through public relations teams
Enable Postmortems
Molly Star (Lightstep Blog) states: “Incident response management doesn’t end when the incident is resolved. Your playbook should detail your postmortem process, from documentation and discussion to action items.” Postmortem follow-up is essential because the organization needs to review how they can improve the security of their systems and, in other words, “harden” their perimeter.
The first step is to identify the root cause of the cyber event via the logs on your firewall/WAFs or through the SIEM. By identifying the root cause, remediation can begin to prevent the same or similar cyber events. No solution is perfect, and even if an organization is doing everything right, it is best to adopt an assume-breach mentality.
Figure 3: Summary of incident response process
Conclusion
Data breaches are inarguable and demonstrate a failure to secure systems, and it’s on the organization to respond quickly and effectively. Having a tested IR playbook in hand, continually practiced through tabletop exercises, can help your team cross the finish line while minimizing material impact to the company. Incidents can have a lasting impact, even if adequately handled. A developer-driven, security-first mindset is worth considering. It has a positive ripple effect on the business if developers and security teams can work together and learn lessons from previous incidents.
This guide is a wake-up call to implement holistic information security practices that have both developers and security teams moving toward the same goal as a collective. Dedicating time to threat model with developers to build secure code upfront is a small resource investment that has the potential to yield significant gains for the business in the long term. After all, it can shrink the attack surface, reducing impact should an incident occur.
References:
This is an article from DZone’s 2022 Enterprise Application Security Trend Report.
For more:
