Just when news reports about individual data breaches were starting to get predictable, we got SolarWinds. And then Accellion. And Exchange Server. In a world where the next cybersecurity incident is only a matter of time, having a solid web incident response plan is a must for any organization.
Why You Need an Incident Response Plan
Not so long ago, many organizations believed that security incidents were something that only happened to others. The recent wave of cyberattacks against infrastructure components used by thousands of organizations has exposed the fragility of information security in modern businesses. The consequences of a successful cyberattack can range from a minor disruption of business operations to crippling financial and legal costs, so when things do go wrong, you need to know who should be doing what. An effective incident response plan is vital to keep your actions organized and minimize operational risk.
How to Define Your Security Incident Response Process
Your response will vary depending on the scope and type of incident. You will need to react differently to, say, a phishing attack that installs malware in your local network than to a data breach caused by an SQL injection. To make sure that your security policies cover all cases, it’s best to take an existing incident response framework as the starting point for building your own process. If you already have an overall cybersecurity framework, the incident response process should be included in its scope and cover all areas of IT security, including web application security.
Typical Incident Response Steps for Web Application Security
The two most popular incident response frameworks come from NIST and SANS. While they differ in how they group and name the phases of incident response, both follow the same basic process. Based on this, here are six basic steps for incident handling in web application security: Prepare, Detect, Contain, Address, Recover, and Learn.
Step 1: Prepare
Preparation is by far the most important stage of incident response. To secure your web assets, you first need to know what assets you have – and surprisingly many organizations don’t even know that. Similarly, to ensure data security, you need to know what your data is, where it resides, who should have access to it, and how critical it is to your business.
Next, you need some kind of risk assessment process so you know what security events and impacts you are preparing for. Depending on your policies and requirements, this could involve formal threat modeling or a more informal approach to threat intelligence and identifying the most likely attack vectors.
In the preparation stage, you are likely to identify weaknesses or blind spots that you need to address. For example, if you use a tool like Netsparker to run asset discovery followed by a vulnerability scan, you may find forgotten or unmaintained websites that are vulnerable to attack. These issues will need to be addressed to reduce your attack surface and close all the gaps, so you might call this Step 0: Prevent.
Whatever you put in your incident response plan, you need someone to implement it when things go wrong. Your incident response (IR) team will often simply be your IT security team, though large organizations may have a dedicated computer security incident response team (CSIRT). In either case, you will need to have specific team members on call and ready to follow established procedures.
Step 2: Detect
Web application attacks and data breaches are often only detected after many days or even months – or not detected at all, especially if they have no direct impact on operations. Careful logging and monitoring at the application level can help to detect suspicious activity, such as repeated access attempts or unexpected user accounts being created. You can use a security information and event management (SIEM) solution to coordinate these monitoring efforts. Regular security testing using an accurate and up-to-date web vulnerability scanner is also vital not only to prevent attacks but also to find new vulnerabilities that attackers could already have exploited.
Step 3: Contain
After a web security incident is detected, your IR team needs to triage it and decide on the best course of action to minimize short-term impact and prevent minor issues from escalating into full-blown incidents. For example, if you detect that a critical vulnerability in one of your business applications is being actively exploited, the containment phase might involve setting up your web application firewall (WAF) to block this specific attack and prevent any further damage. Advanced vulnerability scanners like Netsparker can even integrate with popular WAF platforms to do this automatically.
Step 4: Address
Once the immediate threat is under control, you need to fix or otherwise address the issue permanently. Continuing the example of your critical vulnerability, after deploying a WAF rule to block attacks in the containment phase, your security team would take the vulnerability report and create a fix ticket for developers. In the case of Netsparker, this process can also be automated to streamline communication and minimize the response time.
Recent global cyberattacks have served as a reminder that plugging security holes is often the easiest part. Advanced threat actors don’t do hit-and-run attacks but rather infiltrate target systems to maintain a stealthy and persistent presence. Eliminating the entry point is only the start of a long and arduous process where your IT security and administrators check all potentially affected systems for malicious code such as web shells and then clean or rebuild them.
If you’ve had a data breach, you may also have legal obligations to take care of, such as GDPR-mandated notifications. Depending on the type of data and your jurisdiction and industry, you might need to report the incident to law enforcement or the relevant regulatory bodies and update this notification as more information becomes available.
Step 5: Recover
While most web application security incidents won’t require a full disaster recovery process, you need to have incident recovery procedures in place for every eventuality and every level of the application stack. In IT security, everything is connected, so a web application breach could be just one part of a wider attack that affects other systems or threatens business continuity. Regardless of the incident, the overriding goal of your recovery process should be to restore normal service while minimizing damage and disruption to business operations.
Step 6: Learn
Once the fire is out, you can move to post-incident activities such as a post-mortem or root cause analysis. This phase is probably the most important for improving long-term security since many web attacks are performed by reusing and adapting existing techniques. For example, fixing only a specific injection vulnerability without actually making the relevant part of the application code more secure may allow attackers to modify the attack payload slightly and breach the application again. By analyzing each incident and drawing the right lessons, you can go back to step 1 – and be better prepared for the next attack.