All businesses inevitably face a security incident.
It's only a matter of time, and when it does happen, your organization's response will impact your company’s reputation, time, and revenue. To minimize any major repercussions, you have to plan a response before a security incident actually happens.
Creating an effective incident response plan will go a long way in dealing with security incidents and will give you a dependable framework to set up the operating procedures. Make sure you communicate the incident response policy precisely to all teams across the organization and work to implement the policy during an actual cyber attack.
What is incident response?
An incident response plan is a well-defined and systematic approach for handling and managing a security incident in a way that it causes a minimum impact on an organization. The approach is targeted at limiting the damages and reducing response time and costs.
Security incidents are not just a technical issue, but they are also a problem that affects businesses from various angles. If not handled properly, they can cause legal troubles, resulting in imposing hefty fines on your organization, depending on the type of information or assets that become compromised.
To avoid such situations, create an incident response policy so that you'll know what to do and how to limit the damage if an unfortunate incident happens.
Before taking a deep dive into understanding incident response in detail, let's take a moment to clarify the jargon and terminologies we will use in the article. IT managers use specific terms based on their previous experience in the industry, which can create confusion as others may understand the meaning differently.
The most fundamental terms here are eventand incident. An event is any observable occurrence in a system or a network, not necessarily malicious. National Institute of Standards and Technology (NIST) special publication defines an incident as a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices.
If you've worked in the ITSM industry before, you may recall a different definition of an incident. Both refer to unplanned interruption in the service or reduction in the quality of service. Still, in this article, we will focus more on an incident related to computer security that compromises an organization's cybersecurity.
Why is incident response important?
Hackers are consistently evolving, and so are their methods. With a range of attack vectors perfectly capable of converging a cyber attack at your business' digital forefront, you cannot afford to be experimenting with your response strategy.
You should have a definite and straightforward course of action set up before an event occurs. Amid the present cyber threat landscape, it's not a matter of if a security breach happens. It's more inclined toward when, and when a cybersecurity incident occurs, you have to be ready.
An incident response plan enables you to become proactive during a security crisis and provides you the necessary clarity to contain it and help your organization recover. Moreover, it presses on a preventive approach. In addition to laying the groundwork for the response, it helps organizations learn from incidents and put preventative and remediation measures to avoid them in the future.
The reasons why an incident response plan is important are:
Protecting data: Data is the backbone of businesses. Its security is essential for both the organization and its clients. The incident response (IR) plan helps you elevate security by introducing modern methods in data protection based on lessons learned from previous incidents.
Maintaining trust: A breach can cost you the hard-earned trust of your customers, investors, and other stakeholders. The incident response plan enables you to address a data breach incident appropriately and limit its impact at the earliest. It will help you maintain the trust and confidence of all the stakeholders involved.
Safeguarding revenue: In security incidents, revenue suffers a substantial impact. Be it in the form of a ransom in a ransomware attack or fines imposed by regulating authorities, or when a customer takes their business elsewhere. For public companies, it primarily reflects on their stock prices in the market. IR plans empower you to act on an incident in a structured way to stop revenue drainage and handle the attack quickly.
Conclusively, the faster you deal with a security incident with a well thought out plan, the better you can help your organization minimize its impact. You have many moving parts in a security incident: third-party contractors, legal and government authorities, press, and others.
A proper incident response plan will help you retain clarity on the course of action amid stressful times. It'll make the chaotic time just a little less hectic and a lot more effective.
4 phases of an incident response
Before delving into the four phases of incident response, it's paramount that you've got a communication plan in place, so when an actual incident occurs, you won't be struggling to mobilize your computer security incident response team effectively. It’s advisable to equip your team with incident response software to automate various processes, and/or provide them with the necessary tools to find and resolve security breaches.
First, reserve a place where your team can assemble and work toward a response. This place is commonly called a war room or command center. If your teams are deployed at different locations, consider having a secure channel of communication. Avoid relying on your former communication channels as you wouldn't initially know if they were compromised.
Tip: Traditional communication ways can be the best choice in adverse situations. For example, sharing an image of a whiteboard containing the details via email or instant messaging.
If your team members work remotely, consider equipping them with a secure video conferencing software and utilizing its features, like breakout rooms, to ensure effective collaboration.
Set up a contact repository covering everyone in the incident response teams and have an on-call person, even during the night. It's best if the on-call responsibility is shared by a few members who cater to it on a routine basis. As mentioned before, a security incident is only a matter of time, and it can happen even at 3 a.m. Having an on-call person would guarantee your organization the support it needs from your team in adverse situations.
During an incident, your teams need an arsenal of hardware and software to combat the raging cyber attack. It's advisable to preselect those tools to train your teams on them, so they are ready to use.
You can also help prevent a cyber attack by equipping the business with the best security tools. Typically, this would be the lookout of IT operations staff, but you can add your suggestions based on your experience and learnings from handling incidents. You'd need a digital forensic toolkit to conduct a thorough analysis of the IT environment.
Perhaps including the costs of hardware and software in your budget would help you strategize on an incident response team's financial aspect. Next, you'll need technical resources and information to be able to assess the incident properly. You can conduct threat modeling to plan and optimize network security operations.
These technical resources needed by your team can be divided into five categories, as follows:
Port lists: The lists of various ports, protocols, and services
Documentation: A list of operating systems, applications, security products, and protocols of the network you want to respond to
Current baselines: To know the software that you'd need to install on a particular system or server
Cryptographic hashes: Collection of all cryptographic hashes for all critical files, including your baseline applications that serve as a digital fingerprint
Network diagrams: To enable IR teams to speed up the response instead of scanning and understanding the network architecture
2. Detection and analysis
Before putting your incident response plan into effect, you have to be sure that an incident has occurred. In order to detect an incident, you'd have to look for precursors or indicators.
Precursors: These are signs that hint at the possibility of an incident in the future.
For example, if your logs show that someone has conducted port scanning or vulnerability scanning on your system. This is a precursor, as attackers might scan the system for vulnerabilities before initiating the cyberattack. Also, if a new security vulnerability is found in one of the third-party software solutions you use, it can also be regarded as a precursor. The hacker might reverse engineer this vulnerability to converge an attack on your organization.
Indicators: These are signs that an incident may have occurred or may occur now.
An example of an indicator can be when your intrusion detection system alerts you about a malicious software attempting to beacon out from one of your hosts on the network. In the same vein, the signs that indicate something malicious is happening now can be treated as indicators.
In the detection phase, you've to look for the indicators of compromise (IOC). These are signs that tell you with high confidence that an incident has occurred. Typically, you can look for malware signatures, URLs, or domain names of malicious websites, botnet command and control servers, and many more.
You'll get these signs from intrusion detection, and prevention systems, SIEM systems, antispam and antivirus systems, file integrity checking software are other third-party monitoring tools. You can also leverage the publicly available information such as the latest vulnerabilities updated on the national vulnerability database and other reliable sources.
Now once you have identified the indicators, the next step is to conduct an analysis. It is important as you might get signs of an incident from unreliable sources. For example, a user claiming that their system has gone dead slow. This can be due to malware or it can merely be a corrupted program. You have to make sure if there was a real intrusion and then begin the response.
It's advisable to have a team of incident handlers who can conduct a thorough analysis of the signs.
Incident handlers will classify a sign into three categories:
Benign: These are false positives, where the analyst has examined the sign and its evidence and confirmed that it's not a troublemaker.
Malicious: These are signs that an actual incident has occurred, after which the team begins the incident response.
Suspicious: These are signs where the analyst is not sure if they are benign or malicious. These signs are analyzed by a senior analyst thereafter.
With modern technology ramping up at pace, such analysis is conducted through automation, but you still need real, breathing, and living human resources to make the right decisions in managing this triage. To make the right decision, the incident response team should gain an in-depth understanding of the baseline of the organization's IT assets and endpoints. If you know how normal looks, you can quickly point out the strange stuff.
Technology like SIEM systems equips your team with capabilities such as event correlation and threat intelligence. You can examine logs across different verticals of your organization and predict the possibility of an incident based on permutations and combinations of certain activities.
Tip: Consider having a centralized knowledge base of these incidents to share the knowledge and help other analysts experiencing a similar situation.
Ensure you document everything: alerts, indicators, actions, and the incident response process carried out in the plan. It serves as an excellent knowledge sharing resource. Now that you have identified the malicious activities and events, the next step is to prioritize the incidents you're dealing with.
You can prioritize your response to incidents based on your organization's requirements. Every company has different priorities, and they'd expect your response strategy to align with the same. Some may prioritize based on functional impact (effect on normal operations), informational impact (effect on availability and integrity of data within the IT systems), or recoverability effort (the effort it would take to recover from the event).
When you've prioritized the incident response, the final consideration in the detection and analysis phase is to notify people and the procedure to do it. The procedure can include no notification, email, or even a wake-up call at 3 a.m., based on the severity of the incident. Also, plan who you'd notify beforehand so that you can mobilize your team effectively.
3. Containment, eradication, and recovery
Now you have identified the incidents and prioritized them. The next step is to contain the incident and prevent further damage.
There are a few containment strategies that you can use:
Isolation: It involves disconnecting the affected system from a network, shutting it down, or blocking certain functionality on the victimized machine to limit the damage.
Mitigation: This strategy buys you time so that you can enforce your eradication methodology and allocate resources effectively.
Sandboxing: It includes separating a system from other critical systems and programs.
The choice of containment strategy largely depends on the nature of the incident, the organization's lookout, and the potential damage it can cause. Isolation can be a good solution in certain cases, but probably not the best one for others. For example, if your system is infected with malware, you'd be inclined to shut it down or disconnect it from the network. But when the work station serves as the domain controller, email server, or web server, shutting it down would do more harm than good, as you'd be welcoming a denial of service on your own.
Similarly, there are times when malware is programmed to deal with isolation. If the trojan detects your system is being shut down, it can encrypt your data and even delete it. In such situations, responders move ahead with the mitigation strategy.
As mentioned above, the mitigation strategy buys you time to carry out eradication and allocate resources. To do that, you can logically isolate the compromised asset in the demilitarized zone (also referred to as the DMZ network), which can separate your network from the compromised asset and keep it safe behind a firewall.
While moving ahead with the mitigation strategy, you should conduct a risk assessment and consider the continuous damages that the infection is going to make on the compromised assets before you eradicate it. On the other hand, with sandboxing, you can redirect the attacker's activities to a workstation, which can be used to collect evidence. Ensure that you are not breaking any laws as they vary from place to place.
Consider collecting evidence of the incident that answers to what, why, where, when, and how. It's also advisable to maintain a proper chain of custody, which tells who collected, controlled, and secured the evidence. This would be helpful if law enforcement is going to be involved.
Disclaimer: These guidelines do not constitute legal advice. If you have legal questions, consult a licensed attorney.
Next, you can move toward eradication and recovery. The strategy of eradication will depend on the source of the incident. Make sure you've all the specifics associated with the incidents, as they'd matter immensely. Aim for improving the security, as you wouldn't want the incident to repeat and question your security framework again.
You can conduct a root cause analysis, identify the primary cause that led to the incident and correct it before it can attract more trouble.
Root cause analysis is carried out in four steps as follows:
Define and scope the incident.
Define the events that together led to the incident.
Identify a solution.
Ensure the solution has been implemented and the incident was solved.
4. Post-incident activity
After the incident response team has eradicated the incident and is working with the system admins to recover, they enter the final phase. It's the post-incident activity that initiates with lessons learned. The lesson learned is a formal method of documenting the experience of handling the incident, what you could have done differently, and the process you need to improve internally to avoid a subsequent incident.
The post incident activity will also involve keeping track of metrics such as the indicators causing the maximum number of security events. For example, suppose there are a series of incidents caused due to the abuse of authorized access. In that case, this is a sign of insider threat and the eminent need to introduce an intrusion detection and protection system (IDPS).
You should also keep track of the time to recover from an incident, initiate the response plan, and time taken to inform the upper management and manage escalations so that you can optimize your process better. Measure the costs associated with the incident, such as per hour compensation paid to security professionals handling the incident, loss of revenue in the downtime, cost of additional software installed during the incident and also the total cost encompassing every spend associated with the incident.
You can measure these metrics objectively, and in addition to these, you can also evaluate subjective aspects of the incident, like the effectiveness of your communication plan. The metrics will help you detect the problem areas in your incident response plan and improve the processes to deliver better responses. Post-incident activity also includes retaining the evidence of an incident. You may have different evidence retention requirements based on how your organization is handling the event.
Invest in an incident response strategy
The benefits of an incident response strategy beat the costs linked to it, especially when compared with the financial losses that pile up on your organization in a cyber attack. With a proper incident response plan, you can detect, contain, eradicate, and recover from an attack without putting yourself through a world of confusion.
Learn more about cyber attacks and how you can handle them to protect your reputation, and save yourself from sustaining other damages.
Sagar Joshi is a content marketing specialist at G2 in India. He is a firm believer in the potential of content and its role in helping people. Topics related to security and technology pique his interest and motivates him to write about them. In his free time, you can find him reading books, learning a new language, or playing pool.
Make incidents less hectic
Discover the software you need to automate processes and provide the necessary tools to your team during an incident.