Incident response là gì

Importance of incident response

Any incident activity that is not properly contained and handled can, and usually will, escalate into a bigger problem that can ultimately lead to a damaging data breach, large expense or system collapse. Responding to an incident quickly will help an organization minimize losses, mitigate exploited vulnerabilities, restore services and processes and reduce the risks that future incidents pose.

Incident response enables an organization to be prepared for both the known and unknown and is a reliable method for identifying a security incident immediately when it occurs. Incident response also allows an organization to establish a series of best practices to stop an intrusion before it causes damage.

Incident response is a crucial component of running a business, as most organizations rely on sensitive information that would be detrimental if comprised. Incidents could range from simple malware infections to unencrypted employee laptops that could have compromised login credentials and database leaks. Any of these incidents can have both short- and long-term effects that can impact the success of the entire organization.

Additionally, security incidents can be expensive as businesses could face regulatory fines, legal fees and data recovery costs. It could also affect future profits as untreated incidents are correlated with lower brand reputation, customer loyalty and customer satisfaction.

While organizations cannot eradicate incidents completely, incident response processes do help to minimize them. Emphasis should be placed on what can be done in advance to brace for the impact of a security incident. While hackers will always continue to exist, a team can be prepared to prevent and respond to their attacks. That is why having a functional, effective incident response approach is important for all types of organizations.

Types of security incidents

There are various types of security incidents and ways to classify them. What may be considered an incident for one organization might not be as critical for another. The following are a few examples of common incidents that can have a negative impact:

• A distributed denial of service (DDoS) attack against critical cloud services.
• A malware or ransomware infection that has encrypted critical business files across the corporate network.
• A successful phishing attempt that has led to the exposure of personally identifiable information (PII) of customers.
• An unencrypted laptop known to have sensitive customer records that has gone missing.

Security incidents that would typically warrant the execution of formal incident response procedures are considered both urgent and important. That is, they are urgent in nature and must be dealt with immediately and they have an impact on important systems, information or areas of the business.

Another important aspect of understanding incident response is defining the difference between threats and vulnerabilities. A threat is an indication or stimulus, such as a hacker or dishonest employee that is looking to exploit a vulnerability for a malicious or financial gain. A vulnerability is a weakness in a computer system, business process or user that can be easily exploited. Threats exploit vulnerabilities which, in turn, create business risk. The potential consequences include unauthorized access to sensitive information assets, identity theft, systems taken offline and legal and compliance violations.

6-step incident response plan

An incident response plan is the set of instructions an incident response team follows when an event occurs. If developed correctly, it should include procedures to detect, respond to and limit the effects of a security incident.

Incident response plans usually include directions on how to respond to potential attack scenarios, including data breaches, denial of service/DDoS attacks, network intrusions, malware outbreaks or insider threats.

Without an IRP in place, an organization may not detect the attack, or it may not follow proper protocol to contain the threat and recover from it when a breach is detected. A formally documented IR plan helps businesses respond rather than react. When incident response procedures are not developed in advance, the resulting efforts end up making the situation worse, including looking unprofessional and ultimately being indefensible if lawyers become involved.

According to the SANS Institute, there are six key phases of an incident response plan:

1. Preparation. Preparing users and IT staff to handle potential incidents, should they arise.
2. Identification. Determining whether an event qualifies as a security incident.
3. Containment. Limiting the damage of the incident and isolating affected systems to prevent further damage.
4. Eradication. Finding the root cause of the incident and removing affected systems from the production environment.
5. Recovery. Ensuring no threat remains and permitting affected systems back into the production environment.
6. Lessons learned. Completing incident documentation, performing analysis to learn from the incident and potentially improving future response efforts.

Additionally, best practices indicate that IRPs follow a common framework, which includes:

• An overview of the plan.
• A list of roles and responsibilities.
• A list of incidents requiring action.
• The current state of the network infrastructure and security safeguards.
• Detection, investigation and containment procedures.
• Steps toward eradication.
• Steps toward recovery.
• The breach notification process.
• A list of follow-up tasks.
• A call list.
• Incident response plan testing.
• Any revisions.

An incident response plan can benefit an enterprise by outlining how to minimize the duration of and damage from a security incident, identifying participating stakeholders, streamlining forensic analysis, hastening recovery time, reducing negative publicity and ultimately increasing the confidence of corporate executives, owners and shareholders.

The plan should identify and describe the roles and responsibilities of the incident response team members who are responsible for testing the plan and putting it into action. The plan should also specify the tools, technologies and physical resources that must be in place to recover breached information.

Every organization's IRP can be tailored to specific business risks and needs that have been identified in risk assessments. However, all incident response plans should outline factors involving who, what, when, why and how as they relate to security incidents and confirmed breaches.

What does an incident response team do?

A good incident response program requires putting together a cross-functional team from diverse parts of the business. Without the right people in place, any attempted incident response efforts will likely be ineffective. The team not only helps to execute the IRP but also aids with ongoing oversight and maintenance, including the day-to-day administration of technical controls. Each team member should have clearly defined duties and goals. These are actions that not only take place during an incident, but also before and after an incident occurs. The incident response team may involve members of the organization's overall security committee.

Who is responsible for incident response?

To properly prepare for and address incidents across the business, an organization should form an incident response team. This type of security team is responsible for analyzing security events and responding appropriately. An incident response team may include:

• An incident response manager, usually the director of IT, who oversees and prioritizes actions during the detection, analysis and containment of an incident. The incident response manager also conveys the special requirements of high-severity incidents to the rest of the organization.
• Security analysts who support the manager and work directly with the affected network to research the time, location and details of an incident. Triage analysts filter out false positives and keep an eye out for potential intrusions. Forensic analysts recover key artifacts (residue left behind that can provide clues about an intruder), and maintain the integrity of the evidence and the investigation.
• Threat researchers that provide threat intelligence and context for an incident. They scour the internet and identify information that may have been reported externally. Threat researchers combine this data with an organization's records of previous incidents to build and maintain a database of internal intelligence. If this level of expertise does not exist in-house, it can be outsourced.

Management support is key to securing the necessary resources, funding, staff and time commitment for incident response planning and execution. Many incident response teams include the chief information security officer (CISO), the chief information officer (CIO) or another C-suite executive who acts as a leader and evangelist for the group. An outside consultant who specializes in incident response can be a good addition to the team when needed.

The incident response team may also include a human resources representative, especially if the investigation reveals that an employee is involved with an incident. Audit and risk management specialists can develop vulnerability assessments and threat metrics. They also encourage best practices across the organization.

The organization's general counsel can ensure that the collected evidence maintains its forensic value in case the organization decides to take legal action. Attorneys also provide advice about liability issues when an incident affects vendors, customers and/or the general public. Finally, a public relations specialist is essential to keep in touch with team leaders and to ensure accurate and consistent information is disseminated to the media, customers, stockholders and other interested parties.

Incident response plan management

Incident response is not unlike any other aspect of information security. It requires thoughtful planning, ongoing oversight and clear metrics so that efforts can be properly measured. Ongoing management initiatives include setting and overseeing incident response goals, periodically testing the IRP to ensure its effectiveness and training all the necessary parties on applicable incident response procedures. Specific metrics used to measure the effectiveness of incident response initiatives might include:

• Number of incidents detected.
• Number of incidents missed.
• Number of incidents requiring action.
• Number of repeat incidents.
• The remediation timeframe.
• Number of incidents that led to breaches.

Additionally, incident response goals might include areas involving:

• Reviews and updates to the routine incident response plan.
• The planning and execution of incident response test scenarios.
• Integration issues with related security initiatives, such as security awareness, technical detection systems, employee training and vulnerability and penetration testing.
• The reporting of security events to executive leadership or outside parties.
• The procurement of additional technologies that can provide enhanced network visibility and control.

Incident response plans vs. business continuity plans

With the goals of maintaining normal operations and minimizing the impact of unforeseen events, incident response could be considered part of the business continuity process. Given what is at stake and the different variables involved, such as people, technologies and business processes, incident response should have the highest levels of visibility within the organization. An IRP is dedicated to incidents and breaches impacting networks and computers, applications and databases and related information assets. Therefore, most organizations are best served by keeping the incident response plan in a standalone document -- separate from, yet referenced in, the business continuity plan. The most important thing is to ensure the incident response plan is easily accessible by all team members when it is needed.

Tools for incident response

There are numerous tools and methodologies that can be used to assist with incident response and are typically categorized by prevention, detection or response functionalities. Certain organizations follow the military-derived OODA loop for incident response. The OODA loop is a methodology that encourages a business to observe, orient, decide and act when an incident occurs, all of which IR tools can assist with.

For example, an organization can gain the necessary visibility into an incident with packet analysis, system resource monitoring and file integrity examination technologies. Insight can be gained into threats by using real-time threat indicators and threat intelligence services. Even further, there are tools that can provide forensics details such as source location, incident technical information and event replays. There are also tools that allow an organization to act against a threat by stopping it from spreading or minimizing the impact it has on the computing environment.

While incident response is a process, technology can be used to automate and streamline specific incident response functions to help minimize detection times and system errors. Service providers focused on developing incident response technology typically offer products in the following categories:

• employee awareness and training;
• endpoint security management;
• firewall, intrusion prevention and DoS mitigation;
• forensics analysis;
• net flow and traffic analysis;
• security incident and event management (SIEM); and
• vulnerability management.

Incident response tools provide organizations with both visibility and control. They also provide professionals with the necessary information they need to know to handle the anomalous behavior. Finally, incident response tools help with direct response efforts -- allowing organizations to minimize the risks involved.

Most technology products in the incident response sector are commercial and require proper budgeting for capital and operating expenditures. Alternatively, there are numerous open source software offerings that could be tailored to meet a specific organization's requirements. When choosing the open source approach, it is important to weigh how much effort will be involved, how efficiently it will be able to scale and how effective it will be long term.

Once incident response tools are put into place, it is important to ensure that there is enough staff and expertise to keep it maintained and updated. Having the necessary resources is critical for the initial design and implementation of the technology, as well as ongoing administration and troubleshooting.

Finally, executives must remember that incident response tools cannot comprise the entire incident response program. While tools and automation may play a large role, they should still only be one component of the overall incident response requirements.