We often say that in cybersecurity, it’s important to think about “when” an attack will occur, not “if” it will occur. And while being proactive is touted as the key to an organization’s most effective security posture, one should never dismiss the value of reactive security practices, either. Building up your defences against attacks and cyber risks is important, as is knowing how to detect malicious actors who have breached your systems.
Having these strengths can discourage incidents from escalating into major data breaches. And data breaches, as we know, can lead to financial, reputational and legal repercussions that may be detrimental, even devastating, to an entire organization and all of its operations.
Organizations may never completely eradicate security incidents, but they can establish procedures to help minimize their effects. Preparing for an incident and knowing how to brace for its eventual impact is a solid method of prevention against cyber attacks. This is where incident response comes into play.
Difference between a security event and an incident
Before we delve into incident response, let’s explore what a “security incident” is, and how it differs from a “security event.” These terms can be confusing, and the line that separates them is somewhat blurred.
Security alerts help organizations detect cyber attacks and potential malicious behaviour quickly. These alerts are produced by an array of security tools that security analysts ingest for their valuable work. And because these alerts indicate security events which can be false positives or false negatives, they need to be analyzed.
For example, if an analyst in the SOC receives an alert from their SIEM, they’ll need to determine whether that event is a true positive with a negative impact on the organization, such as a financial or reputational risk. If determined to have a potential impact on the confidentiality, integrity or availability of the organization’s information security, it becomes a security incident. That’s when it warrants initiation of the incident response protocol.
So, in plain English, a security event is just that—an event that needs further examination. It might be a false alarm, and only becomes a security incident when it’s determined to have a potential for damaging effect.
What is incident response (IR)?
When a security incident occurs, it’s essential for your organization to be ready for whatever comes next as well as how to respond. Incident response (IR) is a methodical approach, one that includes policies and procedures to prepare for, detect, contain and recover from a security incident.
The goals of incident response are to limit damage, reduce recovery time, lessen costs the incident may cause, and for the organization to recover as quickly as possible. Incident response ensures that the organization can get “back to normal”—meaning the state the system was in before the incident occurred—and is equipped with the techniques and knowledge needed to prevent the incident’s reoccurrence. It also allows organizations to establish best practices for damage prevention while helping to inform other, more proactive security practices.
A rather important note about incident response is that it’s not only an IT process, but a business process as well, helping organizations with continuity and quick decision-making. Because security incidents can have both short-term and long-term effects on an organization, incident response can be considered part of the business continuity process, with its goal of maintaining normal business operations and minimizing the impact of unexpected events.
Additionally, security incidents carry with them a slew of potential financial losses due to the high data recovery costs, breaches of regulatory compliance and legal fees, and reputational damage that a breach involving customer data can bring. Incident response can help by containing the incident before it gets to the harshest consequences.
Technology is, of course, an important part of incident response. Security automation can be used for specific IR activities. Some of the more important tools of IR technology include endpoint detection and response (EDR), firewalls, intrusion prevention systems (IPS), vulnerability management, security incident and event management (SIEM), cyber forensics, and the like.
Yet as important as technology is for incident response, people are even more important; an effective incident response process requires a diverse team of experts to support it. An incident response team needs to be a well-rounded complement, with SOC teams and triage analysts who work 24/7 and are the first line of defense to receive and filter out false positive and false negative alerts, security analysts who work directly with affected networks to research and analyze events and incidents, and cyber forensics analysts who recover and analyze artifacts from affected networks.
There’s also the incident response manager who oversees and prioritizes activities during the IR process and communicates with stakeholders. Threat intelligence researchers should be available to provide cyber threat intelligence to incident response teams that will equip with actionable information to prioritize and make faster decision and help reduce the stream of irrelevant alerts. Additionally, there should be legal representation to offer guidance for addressing potential charges and other legal difficulties that security breaches can bring.
What is an incident response plan?
An incident response plan is the documentation that outlines an organization’s instructions for their staff to detect, respond, document and recover from security incidents. Such a plan needs to align with the organization’s level of acceptable risk, and detail the main responsibilities of their incident response process.
For an organization to have a successful security program, having an IR in place is indispensable. Its goal is to establish and test the measures necessary to reduce the impact of a security incident. And even though an IR plan’s importance is clear, many organizations don’t have one. Or they have it, but not one that is developed to the level that it can truly be effective.
According to a survey by Ponemon, 77% of businesses admit they lack a formal incident response plan that is applied consistently across the organization, with nearly half saying that their plan is informal.
While an IR plan isn’t a one-size-fits-all approach, most of them share common components. These include details on an organization’s entire approach to incident response, how it supports their business objectives, the exact activities the process entails, the roles and responsibilities of those included in IR activities, the IR team’s communication channels with the rest of the organization, third-parties and customers, and key metrics that showcase the effectiveness of the IR process (such as the number of detected incidents, missed incidents, incidents that required action, repeated incidents, the timeline of remediation, and more).
The steps of an incident response plan
Besides the common details contained in each incident response plan, there are also two industry standards for IR frameworks that go into action when cyber threats are detected. These are the NIST and SANS frameworks.
NIST (National Institute of Standards and Technology) is a government agency that works in many areas of technology including cybersecurity. The NIST Cybersecurity Framework is one of the most popular methodologies for managing cybersecurity risk, part of which is the NIST Computer Security Incident Handling Guide.
The NIST suggests an incident response process that involves these four steps:
- Preparation
- Detection and Analysis
- Containment, Eradication and Recovery
- Post-Incident Activity
SANS (SysAdmin, Audit, Network and Security) is a private organization that specializes in information security and cybersecurity training, and is known for offering one of the most popular infosec certifications available. With its sole focus on security, SANS has become an industry standard for many things, one of which is their Incident Handler’s Handbook. And while similar to NIST, the SANS incident response process follows six steps:
- Preparation
- Identification
- Containment
- Eradication
- Recovery
- Lessons Learned
The two processes offered in the NIST and SANS frameworks have basically the same components and stream, but differ in verbiage and number of steps, or rather, what is clustered in each step. Because each step is dedicated to an entire phase of the process, for the purpose of this article we’ll explore the SANS framework, and detail each phase of its incident response process.
1. Preparation
A proper incident response plan begins with preparation, and both NIST and SANS frameworks are clear on that. To prepare for incidents, there needs to be action on several fields and for each component of the IR process. Organizations need to review their current security measures and their effectiveness, and perform a risk assessment to uncover any vulnerabilities as well as their priority (and severity). A list of all IT assets, rating their priority, including which ones are critical and hold sensitive data is also needed. This will then inform detailed response steps and procedures.
In this step, the responsibilities and assignment of roles is established for the incident response team, including effective staff training for responding and documenting incidents as well as the tools and technology needed to advance and automate the process.
2. Identification
Using the tools, roles and procedures gathered from the preparation phase, the IR team works to detect and identify security incidents and breaches. Using threat intelligence feeds, IPS, firewalls and SIEM, the IR team ingests and correlates this data to get to the indicators of attack and detect a breach. When one is detected, they work to identify the attack, its source, breadth of the breach and the goals of the attackers. All steps taken in this phase are documented, evidence is collected, and communication is initiated with stakeholders, legal representation and potentially authorities.
3. Containment
The containment phase of the IR plan works to stop the attack by isolating it before it causes major damage to the affected system. The containment strategy that was also outlined in the first phase of preparation will depend on the level of damage a specific incident can cause, the type of incident, what are the critical services that need to stay available when taking affected systems offline and whether it will entail a long-term or a short-term solution.
Steps to take in the containment phase include a system backup while keeping forensic evidence from the attack that can be used for both further analyses and legal matters, applying temporary fixes that can keep critical systems up, removing backdoors left by attackers and addressing the root cause of the attack.
4. Eradication
Eradication deals with removing the threat from affected systems completely, and restoring them to the state they were in before the security incident occurred (or as close to it as possible), all while minimizing potential data loss.
Steps in the eradication phase include a complete wipe and a re-image of the affected systems’ hard drives, prevention of the root cause (such as patching a vulnerability that the attacker exploited), upgrading software versions and, in general, performing basic security best practices as well as scanning the affected system once again to ensure any residue of the malicious content is removed.
The eradication phase is only complete when the last trace of the attack is eliminated from the system.
5. Recovery
In the recovery phase, additional tests and analysis are performed to verify that the threat is gone from the affected systems, allowing them to be brought back online. Next is defining the time and date to restore all services and operations, as well as to perform tests and ensure systems are fully functional as they go live. All of this is accompanied with continuous monitoring after the incident to observe for any anomalous behaviour.
6. Lessons learned
Last but certainly not least is one of the most important steps in the incident response process. In the weeks following the end of the incident, the IR team should collect and compile all relevant information about the incident to see what lessons can be learned. This is why documentation should be maintained throughout the process, providing the incident report that will answer these key questions:
- What happened?
- When did it happen?
- How well did the IR team deal with the incident?
- What steps were taken?
- Was the process properly communicated?
- What have we learned?
Answers will help identify ways in which the IR process can be improved, and will better inform the metrics that can be used as a comparison benchmark for future incidents.
Incident response plan best practices
While there are industry-standard IR frameworks to follow, you may still be left wondering how to begin building your plan? What are the most important things to consider? We’ve highlighted the five best practices to follow when embarking on building out an incident response plan.
Identify critical assets
Gaining visibility over all assets that hold critical information, are attractive to attackers, and need defending is the first step to take in any incident response plan, and in security programs in general, for that matter.
Security and IR teams need to maintain visibility across all these assets to decrease any delays in incident response, by knowing exactly where the incident happened. Knowing which data is critical for business operations and which hold sensitive information will also help in the prioritization of incident response activities.
Maintain clear channels of communication
We’ve mentioned communication guidelines as an important part of incident response, but it’s something we should reiterate as it’s a part of the process that’s frequently overlooked. Once the incident response process is initiated there need to be clear guidelines on how and what information should be communicated to the management, different departments, affected customers, the press and/or law enforcement, and how that information should be delivered.
Each of these parties will differ in what, when and how the information will be communicated. That’s why having a predefined plan addressing the appropriate ways of sharing information is a significant factor in reducing stress levels and panic when the news about a breach finally hits.
Keep it simple
It’s important to remember that security incidents are stressful situations. During these times, it can be difficult to act carefully and follow a set of convoluted, overly complicated steps. This is why keeping your incident response clear and simple is the way to go. And while keeping it simple, it’s still important to to accurately include specific procedures, steps and responsibilities and to avoid making it too general. This way, your staff will be confident when an attack occurs that they are taking the necessary steps, and they’ll find it easy to implement your IR plan from start to finish.
Create a series of incident response playbooks
An incident response plan is a generalized descriptor for all of the steps your team needs to take if an incident occurs, but it can be only the beginning. A collection of incident response playbooks can help tremendously in fleshing out a more detailed course of action. With highly detailed procedures to be followed when a particular type of security incident occurs, these playbooks are tailored to your organization’s operations and business goals and are regularly updated as your infrastructure evolves.
As no two cyber threats are the same, each should be addressed with its very own playbook and should include ransomware, malware, how to handle a data breach, phishing, cyber extortion, DDoS attacks, insider threats, and the like.
Test the plan
Setting up an incident response plan is important, but it’s not a one-and-done deal. It’s important to test the plan continuously, from the moment it was initially created, and to periodically conduct security drills.
In a security drill, you would experience an attack simulation and go through each step of the IR plan to ensure there are no gaps or weak spots that could become dangerous stepping stones for a response to a real attack. Additionally, as your infrastructure and business in general changes, your IR plan should follow and always be kept up to date.
Final words
Incident response is considered one of the basics of any security program, but is often overlooked, at least in a formal way, in terms of having a plan in place along with the right team and the necessary technology. With revenue, reputation and customer trust on the line, the ability to quickly and effectively detect and respond to security incidents is crucial for any organization.
And what better way to start than with visibility over all of your assets? SecurityTrails provides a way for you to do exactly that. With our exceptional intelligence tool SurfaceBrowser™ you’ll be able to discover unseen areas of any online infrastructure: IP blocks, domains, DNS records, SSL certificates and more.
Get critical data on your organization and eliminate the blindside that can create dangerous gaps in your incident response plan!
Source of Article
![10 beste antivirus Black Friday/Cyber Monday deals [ACTIEF 2021]](https://nasniconsultants.com/wp-content/uploads/2021/10/10-beste-antivirus-black-friday-cyber-monday-deals-actief-2021-270x162.png)
