How to Detect Security Incidents Targeting Web Applications

Photo by Shamin Haky on Unsplash

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 steps for incident handling in web application security: Prepare, Detect, Contain, Address, Recover, and Learn.

Preparation is by far the most essential 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 your data, 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 will likely identify weaknesses or blind spots you must 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 vulnerable to attack. These issues must 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 must have specific team members on call and ready to follow established procedures.

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 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 to prevent attacks and find new vulnerabilities that attackers could already have exploited.

After a web security incident is detected, your IR team needs to triage it and decide on the best action to minimize short-term impact and prevent minor issues from escalating into full-blown incidents. For example, suppose you detect a critical vulnerability in one of your business applications being actively exploited. In that case, the containment phase might involve setting up your web application firewall (WAF) to block this attack and prevent further damage. Advanced vulnerability scanners like Netsparker can even integrate with popular WAF platforms automatically.

Once the immediate threat is under control, you must fix or permanently address the issue. Continuing the example of your critical vulnerability, your security team would take the vulnerability report and create a fixed ticket for developers after deploying a WAF rule to block attacks in the containment phase. 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 starts 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.

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 broader attack that affects other systems or threatens business continuity. Regardless of the incident, the overriding goal of your recovery process should be to restore regular service while minimizing damage and disruption to business operations.

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 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 return to step 1 – and be better prepared for the next attack.

Tags: SaaSWeb Application