Incident Response (IR) & It’s Lifecycle
“It takes 20 years to build a reputation and few minutes of cyber-incident to ruin it.” — Stephane Nappo
In this article we are going to discuss very interesting and much important domain of Cyber Security i.e Incident Response. If you are new to this field then this article is surely going to help you understand the Incident response and it’s life cycle to an extend where you can say you know something about IR now.
When referencing incident response (IR), it can be instinctive to conjure up images of firefighting, focused on reactive action taken to quickly respond to and handle an active security incident during what is usually a high-pressure, high-stakes situation. We are all familiar with the stories of ever-evolving adversaries wreaking immediate (or delayed) havoc to an organization’s business operations, and causing lasting detrimental impact to their reputation and bottom line.
So worried about what i am talking about, don’t worry. Let’s deep dive and understand IR and It’s lifecycle.
What is Incident Response (IR) ?
The National Institute of Standards and Technology (NIST) defines incident response (or incident handling) as “the mitigation of violations of security policies and recommended practices,” while SANS Institute defines incident handling as an “action plan for dealing with intrusions, cyber-theft, denial of service, fire, floods, and other security-related incidents.”
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.
Incident Response Lifecycle
Hang around security and incident management pros long enough, and you’ll notice a pattern. The smartest people in these industries think in cycles, not straight lines.
So a question arises why even do we need to learn about IR life cycle? Why is that? What’s that even mean? That means every incident and outage isn’t an isolated event with a beginning and end point (though it may seem like that). Incidents are a learning opportunity.
Learning about the incident response lifecycle and its framework will help you and your organization understand the accessibility of sensitive information, thereby allowing you to prevent breaches and mitigate threats by educating others and identifying vulnerabilities.
Just because a service is “operational” again, doesn’t mean your team’s work is over. Post-incident activities should have you putting plans on future roadmaps, changing the way you prepare for future incidents, and discovering new things to build which will prevent more incidents in the future. It’s a never-ending cycle of improvement, and there are a few different ways to think about the various stages, depending on what school of thought you subscribe to.
The incident response lifecycle is your organization’s step by step framework for identifying and reacting to a service outage or security threat. There are mainly 2 institutes whose incident response management steps have become industry standards : NIST and SANS. We would be discussing NIST lifecycle here.
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.
1. The preparation phase
Every Incident preparedness is carried out via two-part process that consists of setting up security configurations, and then testing an application for weaknesses.
Setting up security configurations
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.
2.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.
3. 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.
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.
Before summing up, this meme is enough to know how much IR means to an organization.
This was all for today, will be coming up with such interesting articles soon.