Security incident definition
In the context of web application security, an incident is defined as a violation, or attempted violation, of an application’s security policies. Examples include network breaches, vulnerability exploits, unauthorized access attempts, data theft and the altering of site content (e.g., defacing).
What is incident response
Incident response is the process of preventing and mitigating such threats. It requires enterprises to take an organized approach to blocking security breaches and improving network defenses.
This is done by:
- Identifying an application’s weak spots.
- Hardening security perimeters against future assaults.
- Safeguarding access to sensitive parts of an application.
It’s important to note that even unsuccessful attempts should be treated as incidents. Ignoring them could leave your organization blind to emerging threats and vulnerable to future assaults.
Web application firewalls (WAFs) play an important role in any incident response strategy. Understanding how they’re used can help you in developing an effective incident response policy for your enterprise.
The incident response lifecycle
The incident response lifecycle can be broken up into three phases: preparation, detection/analysis and post incident activity. WAF technology plays a different role during each phase, increasing preparedness and enabling rapid data-driven response that helps improve your security posture.
The preparation phase
Incident preparedness is a two-part process that consists of setting up security configurations, and then testing an application for weaknesses.
Setting up security configurations
A number of steps help you prepare for an incident while safeguarding access to sensitive parts of your application, including:
Deploying a WAF – The primary tool for mitigating and collecting data from web application incidents. Positioned on the edge of your network, a WAF analyzes your incoming traffic while identifying and blocking all application layer attack attempts. These include common threats such as SQL injections or cross-site scripting (XSS), application-specific exploit attempts (e.g., CMS vulnerabilities) and more.
Through built-in reputational and behavioral analysis, most WAFs even offer a measure of protection against zero-day threats.
Setting up custom security rules – Most WAFs let you tweak their default security rules and introduce custom security policies to address your specific needs. Typically, such rules can granularly filter web traffic, access privileges and user inputs. Custom policies can be issued based on such factors as:
- Request methods (POST or GET)
- HTTP/S header values
- URL parameters
- IP and geolocation data
- Behavior (e.g., access rates on a request or session level)
Configuring access control policies – This is the process of identifying and securing those parts of your website and web application containing sensitive information (e.g., employee/customer records).
Safeguarding sensitive data is usually done using two-factor authentication (2FA), which provides additional access control security. During login, it requires another verification method—something the user has—to access specific areas of an application (e.g., CMS control panel).
A common example is a session access code sent to the user’s mobile phone, which they then enter into a login dialog box along with their username and password (something the user knows).
Security orchestration – The process of streamlining security measures into a cohesive workflow. This includes:
- Predefining the roles and tasks of every security team member.
- Integrating your application’s unique security procedures into a centralized program.
- Standardizing processes to improve response times and minimize errors.
Doing so speeds up mitigation times and frees personnel to perform other tasks.
Testing for weaknesses
The next step in your preparation phase is to test your application for any soft spots that could be exploited.
This is usually done with a penetration (pen) test — either an automated or manual system that gathers information on vulnerabilities and then stages attacks to identify where a perpetrator might strike.
Afterward, security policies and access controls settings can be readjusted to address soft spots identified by the testing.
Incident detection and analysis
Once deployed, your security measures will inspect and filter all incoming web traffic. In the event of an incident, they’ll block any malicious request, issue an alert and document details about the attempt in an aggregated security log.
The log includes such information as:
- The perpetrator’s IP and geolocation data
- The attack vector used (type and request details)
- The perpetrator’s HTTP fingerprint
- The entry page for the attempt
Here, relevance and granularity are key. Having access to a detailed security event description, you’ll be able to understand incidents and provide the most appropriate responses.
Depending on the WAF, evidence can be collected and presented in real-time, enabling a nearly instantaneous, data-driven response to any attack attempt.
Additionally, many WAFs come with a SIEM integration option, enabling security analysis using your existing event management tools.
Post-incident activity
The last phase in the incident response lifecycle is devoted to applying lessons learned during the earlier phases. This is a three-part process that includes:
- Reviewing incident logs to determine if an attack uncovered any possible soft spots in your security configuration.
- Tweaking WAF rules and introduce new policies to eliminate weaknesses.
- Testing the new rules, while being mindful of false positives.
Rinse and repeat
Working through the incident response lifecycle is a continual process. Detection and analysis flows into post incident activity, which directly impacts preparedness.
Every incident, attempted or otherwise, provides a valuable learning opportunity. Treating them as such enables you to keep improving your security posture while better preparing your application to defend against future incidents.
