This is Part of the Article series, to read Part 1, click here
Having a solid Incident Response (IR) process will enhance the foundation of your security posture. Your incident handling process should dictate how to handle security incidents and respond to them rapidly.
The next step will involve learning how to put all the available tools and talent together to handle an incident. This chapter will go beyond the tools, and you will also learn how to approach an incident, ask the right questions to find the root cause, and narrow down the scope to be able to go from incident red status to green. In the second part of the chapter, we will learn about phishing incident handling as an example. Phishing is still one of the biggest attack vectors for any organization, and it will be useful to cover incidents of this type separately.
In this chapter, we’re going to be covering the following topics:
- The NIST definition of a security incident
- The incident response process
- Handling an incident
- Handling an incident in a phishing scenario
- Hands-on phishing incident response
We will begin this article with a definition of what a security incident is, and the best way to do this is usually by looking at the NIST framework and seeing how it is described there.
Incident handling is the response that an organization gives to an attack. When an incident is handled well, a much more damaging future disaster can be averted. If an incident is handled poorly, there could be a total disaster that follows. This section will focus on how organizations should handle incidents in the right way. The following are the steps that should be followed:
The NIST definition of a security incident
As a foundation for this article, let’s once again define what we mean by various terms that we’ll be using to describe the incident lifecycle.
NIST describes a Security Incident as events with a negative consequence, such as system crashes, packet floods, the unauthorized use of system privileges, unauthorized access to sensitive data, and the execution of destructive malware. Malicious insiders, availability issues, and the loss of intellectual property all come under this scope as well. Incident Response is defined as the summary of technical activities performed to analyze, detect, defend against, and respond to, an incident. Incident Handling is defined as the summary of processes and predefined procedural actions to effectively and actionably handle/manage an incident. An Event is described as an observable occurrence in a system or network while, somewhat obviously, an Adverse Event is described as an event resulting in negative consequences.
As you may have noticed, Incident Handling and Incident Response are synonymous. Choosing to differentiate between the two functions can result in incident miscommunication and mishandling—please bear this in mind during this chapter and your own forays into IR documentation!
Regardless of what you select to use as a reference, make sure to adapt it to your own business requirements.
Most of the time in security, the concept of “one size fits all” doesn’t apply; the intent is always to leverage well-known standards and best practices and apply them to your own context. It is important to retain the flexibility to accommodate your business needs in order to provide a better experience when operationalizing it.
Creating an incident response process
To begin creating an IR process, let’s consider the following diagram, which defines some of the foundational areas of incident handling. We will consider each area in detail in this section:
We can use all the available industry standards, recommendations, and best practices to create your own IR process. The guide that we are going to use as a reference in this chapter is the Computer Security Incident Response (CSIR) publication, SP 800-61R2, from NIST.
While creating an IR process, the first step is usually to establish the Objective—in other words, to answer the question: What is the purpose of this IR process? While this might look obvious, it is important that you are very clear as to the purpose of the process so that everyone can understand it and can be aware of what this IR process is trying to accomplish.
Right after defining the objective, you need to work on the Scope. To make it simple, you can start this by answering a question: To whom does this process apply? In most cases, the IR process usually has a company-wide scope, but this does not mean that departmental scope cannot be created, based on priorities. It is important to define the scope and describe its use.
As the Definition of security incidents can differ from one organization to the next, it is imperative that you have a defined definition of what constitutes a security incident, with examples as reference. Having a glossary with definitions of the Terminology used can be extra valuable, as different industries might use different sets of terminologies, and if these terminologies are relevant to a security incident, they must be documented.
As we explained in earlier chapters, in an IR process, the Roles and responsibilities are critical. Therefore, ensure that the process is approved by senior management, and that your IR team has the authority, since the entire process can be at risk as a result of not having the proper level of authority approvals.
Asking the question Who has the authority to confiscate a computer in order to perform further investigation? can easily highlight the importance of the level of authority in an IR. By defining the users or groups that have this level of authority to investigate, and by communicating this with the organization, making employees aware of the process can save time and effort if an incident occurs. For example, the Chief Financial Officer of the organization will not question the group that is enforcing the policy.
Another important question to answer concerns the Severity Level of an incident. What defines a critical incident? The criticality will lead to resource distribution, which brings another question: How are you going to distribute the IR teams when more than one incident occurs? Will you allocate more resources to incident “A” or to incident “B”? If so, why? These are just some examples of questions that should be answered in order to define the priorities and severity level.
You might ask, how can you determine the priority and severity level of an incident? Before you take any steps, you will need to consider the following aspects of the business:
- Type of information affected by the incident: Every time you deal with Personal Identifiable Information (PII), your incident will have a high priority. Therefore, this is one of the first elements to verify during an incident.
- Functional impact of the incident in the business: The importance of the affected system for the business will have a direct effect on the incident’s priority. All stakeholders regarding the affected system should be aware of the issue and will have their input in the determination of priorities.
- Recoverability: Following the initial assessment, it is possible to give an estimate of how long it will take to recover from an incident. Depending on the amount of time to recover, combined with the criticality of the system, this could drive the priority of the incident to high severity.
Your IR process should have a media communication and reporting plan that should be prepared with the assistance of the legal team and management approval based on the company’s security policy for data disclosure. If your organization has a legal department, they should also be involved prior to the press release to ensure that there is no legal issue with the statement. The procedures on how to engage law enforcement must also be documented in the IR process. We will go into more detail regarding reporting procedures in Chapter 8, Incident Reporting.
The documentation should also consider the physical location—where the incident took place, where the server is located (if appropriate), and other locations of interest; by collecting this information, it will be easier to identify the jurisdiction and avoid conflicts. The documentation should include specifications relevant to the organization’s use of the cloud.
The steps detailed in this section so far also require the adoption of a particular mentality: what is often called an assume breach mentality. Based on the current cyber landscape, there are two types of organizations: the ones that know they have been hacked and the ones they don’t. Our traditional defenses today are still not as effective against attacks as they should be, and they will only deteriorate over time as new attacks and technologies are invented. With the Assume Breach mindset, your security focus should change to identifying and addressing gaps in detection of the attack, a response to the attack, recovering from data leakage, tampering, or compromise, and finally prevention of future attacks and penetration. In other words, you should be fully aware that there is no way to stop attackers; all we can do is make their lives harder by making your organization difficult to attack. The “assume” breach mentality is characterized by being ready and always watching for possible attacks within or from outside your organization, while being ready to respond calmly and totally at a moment’s notice.
Preparation
This is the first step in incident handling. Organizations need to be prepared to deal with security incidents even before they happen and thus preparation is key. Effective preparation will not only reduce the potential of an incident harming the organization but will also aid in quick recovery. Preparation is done in a variety of ways. It can start with a documented policy statement on how the organization will respond to security incidents and who will be responsible for that. Preparation can also entail the implementation of backup solutions, keeping tabs on software patches and also keeping tabs on the updating process of antivirus programs. These and many other processes keep the organization in an always-ready state to deal with security incidents.
Identification
Once the organization is prepared to face incidents, the next step is to identify when and where incidents have happened. Identification tends to be a bit difficult especially with the level of stealth that attackers are employing in their attacks. Therefore, some security solutions are needed to help alert system and network admins when there are security incidents. The speed at which an incident is detected might be the determinant of its successful handing or a total disaster.
Containment
Once an incident has been identified and confirmed to be happening, all gears shift to containment. Containment allows for the damage that an incident can cause to be limited. Here, preventive security solutions and techniques are mostly used to stop the attack. If it is a virus attack, for instance, antivirus systems are used to scan and remove the viruses from the targeted computer. If the incident involves malicious traffic, firewalls are used to prevent traffic from the malicious sources from getting into the network. Therefore, the actions taken at this point are aimed at neutralizing the attack before it gets serious or severe.
Recovery and analysis
Once the incident has been contained, attention shifts to recovering the affected systems and then analyzing the incident. Depending on organization-specific priorities or the nature of the incident, either recovery or analysis can take place before the other. Recovery ensures that the targeted system is restored to the status it was at before the attack. Analysis is a more comprehensive exercise aimed at determining why the incident happened, whether it was correctly handled and whether it can still reoccur.
This chapter has looked at three important processes in any organization; auditing, risk management and incident handling. The chapter begins by taking a look at the IT auditing process. To bring a better understanding of what it is, there is an in-depth explanation of what it is which also summarizes the advantages of having one carried out in an organization. A disclaimer is however given concerning the perception of auditing. Since it is held with high regard, it is important to note that it still has some limitations and cannot cover all potential vulnerabilities in the organization. The chapter then looks at risk management. Here, the 5-step process of risk management is discussed. This includes identification, analysis, assessment, mitigation and monitoring. In addition to this, there is a brief overview on the approaches that an organization can take when handling IT risks. Lastly, the chapter looks at incident handling. The steps of incident handling are discussed and these are preparation, identification, containment and recovery and analysis.
You can read Part 1 of the article here
You can read Part 2 of the article
Incident Response Evolution and Current Challenges – Incident Response Evolution 2
About Author
