Incident response, also known as an IT incident, computer event, or security incident, is a systematic method of dealing with and managing the fallout from a security breach or cyberattack. The objective is to approach the situation in a way that minimizes harm, cuts down on recovery time, and lowers expenses.

You will learn in-depth information on incident response procedures, personnel, and resources on this page:

The Incident Response Lifecycle contains six phases.

  1. Systems and processes creation or preparation.

To do this, conduct a risk assessment to identify your assets’ relative importance and any present weaknesses. The prioritization of responses for different incident kinds is done using the information.

  1. Incident identification

Any evidence gathered during identification must be safeguarded and kept for later thorough study. Responders must keep detailed records of all actions done and evidence uncovered. If an attacker is found, this can help you prosecute them more successfully.

  1. Attackers’ containment and incident activities

There are 2 sub – phases for this item. First is Short – Term Containment are threats that are now present are contained. An attacker’s current location on your network, for instance, might be isolated. Another option is to shut down an infected server and direct traffic to a failover. The second one is the Long-Term Containment. This process includes unaffected systems receive extra access controls. Systems and resources are developed in the interim in clean, patched versions in preparation for the recovery stage.

  1. Removal of the assailants and possibilities for re-entry.

This keeps going through this phase until the attack’s last remnants are gone. In some circumstances, this can necessitate turning off systems so that recovered assets can be replaced with fresh copies.

  1. Recovering from accidents, including system restoration.

The recovery phase usually lasts a while because it also involves keeping an eye on systems after an incident to make sure that attackers don’t come back.

  1. Application of comments and lessons learnt to the upcoming preparation.

Your team analyzes the actions that were made during the reaction phase during the lessons learned phase. Members ought to discuss what worked and what didn’t, and offer ideas for future enhancements. During this phase, any unfinished paperwork should also be completed.

Incident Response Plan

In the event of a security breach, an incident response plan makes sure that the proper individuals and procedures are in place to deal with a danger. A systematic investigation can take place to deliver a focused response to contain and remediate the danger if there is an incident response plan in place.

It may be helpful to limit use of these terms in your plan as follows:

  1. Event – A modification to the status, communication, or system parameters. Examples include sending server queries, changing permissions, or deleting data.
  2. Alert – A notification brought on by a circumstance. Alerts can inform you of unexpected or routine situations that require your attention. Using an unused port as opposed to running out of storage space is one example.
  3. Incident – An incident is a circumstance that endangers your system. For instance, the installation of malware or the theft of credentials.

Incident Response Plan Template

You can check on the list below.

Provider # of Pages Key Content Download Link
TechTarget / Paul Kirvan 14 Plan guidelines and planning scenarios .DOC file
Suggested actions and activities
Notification, escalation and communication processes
IR checklists
IR documentation forms
International Legal Technology Association (IltaNet) 5 IR team guide with employee responsibilities .ASHX file
IR notifications
Classification procedures for incidents
Response and recovery procedures
Plans for periodic testing and remediation
Thycotic 19 Team roles and responsibilities .DOC file
Incident classification guidelines  
Legal and compliance and guidelines (requires registration)
Phases and steps to be taken  
Sysnet 11 Detection guidelines .DOC file
Roles and responsibilities  
External contact information (requires registration)
IR steps  
Specific IR types  
Auditing and improvement guidelines  
California Government Department of Technology 4 17-step IR procedure .DOC file
Type-specific guidelines
I-Sight 6 Plan purpose and scope .DOC file
Incident definitions and examples  
Team responsibilities and roles (requires registration)
IR stages and procedures  

 

Incident Response Frameworks

An incident response framework’s main goal is to help organizations create standardized response strategies. These frameworks are frequently created by big companies with a lot of security knowledge and experience.

The Incident Response Frameworks developed by the National Institute of Standards and Technology (NIST) and the SysAdmin, Audit, Network and Security Institute are two of the most well-known examples (SANS). This framework has four official steps:

  1. Preparation
  2. Detection Analysis
  3. Containment, Eradication, and Eradication
  4. Post- Incident Activity

A private organization called SysAdmin, Audit, Network, and Security (SANS) conducts collaborative research on security concerns and disseminates information to the public. Steps are the following:

  1. Preparation
  2. Identification
  3. Containment
  4. Eradication
  5. Recovery
  6. Lesson Learned

Incident Response Team

A team of IT experts known as an incident response team is in charge of preparing for, responding to, and managing any kind of system loss or downtime. The incident response team is in charge of overseeing post-incident analysis and developing plans to prevent recurrences of the occurrence. They follow a guideline from NIST.

Incident Response Team Models

  1. Centralized – the team is composed of a centralized entity that oversees IR for the entire organization.
  2. Distributed – there are various teams that work together as necessary. Each team often oversees a particular area of the IT infrastructure, physical location, or division.
  3. Coordinated – for remote teams, a central team acts as a command center or knowledge base. System monitoring is frequently handled by central teams, who can also notify and support remote teams when necessary.

How to Select Your Team Model

  1. How much availability do you require? —you must choose your level of availability as well as whether you want a 24/7 response time. For instance, is it sufficient for teams to reply remotely or do they also need to be present? Your team should ideally be accessible in person and in real time.
  2. What kind of personnel are you looking for?—you should choose whether you need shifts of part-time employees or full-time employees dedicated to your team. The best employees to improve the team’s response to an emergency are part-timers. The greatest way to guarantee that your reaction is planned, regular, and prompt is to have full-time workers.
  3. How much knowledge is required? —your team will be more productive the more experts you have on it. However, a lot of businesses lack highly qualified security personnel on staff. If so, you might wish to have outside expertise on hand to support your internal team during reaction operations.
  4. How much can you spend? —your IR budget significantly limits the aforementioned features. Being realistic about the budget required and the best ways to spend it is important when assembling your team.

Incident Response Services

Managed services called incident response (IR) services can be used in place of or in addition to internal teams. These services often have a set range of services, a monthly fee, and work on retainer. These services have the advantage of frequently providing a better degree of expertise than is accessible internally and of being able to provide 24/7 monitoring and reaction.

Some additional benefits are listed below:

  1. You can analyze IT systems and create IRPs that are tailored to your particular needs with the assistance of incident response preparation and planning services.
  2. Services that monitor for security events, identify incidents, and categorize threats can also perform incident triage and classification.
  3. Initial response—services can carry out the necessary procedures or even show up on the scene to support internal responders.
  4. Services for post-breach assessment can assist teams in performing root-cause analysis and providing assessments of the effectiveness of response initiatives.

Incident Response Automation

An automated Incident Response will prevent delays in your action. You can benefit from it this because:

  1. You can triage notifications and incidents as soon as possible
  2. Collect and organize pertinent information for incident investigations.
  3. Execute incident response procedures and duties, such as containing impacted regions and banning IP addresses.

Incident Response Playbooks

If you have an automated IR, one of the key ways to make it effective is to create a playbook. Playbooks are used for:

  1. Manual incident response procedures—playbooks specify the actions to be taken, together with the tools to be utilized, the processes to be carried out, and the people in charge of carrying them out. These playbooks, which are often incident-type-specific, can be printed or read electronically.
  2. Playbooks are programmatic scripts that connect with pertinent systems and technologies in automated incident response processes. The system or tool can start the script, carrying out the predefined tasks automatically, when alarms are triggered or occurrences are found.

The playbook you will create should have the following:

  1. The playbook’s initiating condition is the circumstance that makes it run. This could be an alert, a threshold for incident identification, or another kind of event.
  2. The actions that must be taken—the mandatory stages and procedures. These typically consist of removal, containment, analysis, and triage procedures.
  3. End state. The action that ends the playbook. Your playbook aim serves as a guide for this. For instance, resetting permissions and passwords.

Incident Response Platform

Platforms can integrate with your current systems and are frequently extensive. This is an additional feature you should have in creating an effective IR.

The following are typical IR platform features:

Analyst support Intelligence and analytics Security automation
Knowledgebase of regulations, response plans, and contacts Integration with SIEMs and other monitoring tools Pre-configured IR playbooks
Automatic escalation and assignment of alerts Analysis and correlation of event timelines Support for customizable playbooks
SLA tracking Real-time analysis of attack behaviors Automatic isolation compromised systems or user accounts
Compliance and breach reporting Forensic data retention and querying Automatic remediation

 

Finally, executives need to keep in mind that an incident response program cannot only consist of incident response technologies. Even though tools and automation may be quite important, they should still only make up a small part of the overall needs for incident response.