INCIDENT RESPONSE NOTES

An IRP is mainly responsible for outlining the procedure to be followed, after the occurrence of
a security breach, apart from other cyber threats. Without an IRP, the process of managing the
damage of a security breach becomes cumbersome and confusing. This leads to an unnecessary
waste of time and money. With the presence of rapidly spreading malware, as we witnessed in
the case of WannaCry, the infection can easily cross international borders in no time.

Drafting a response plan after the occurrence of a security breach might appear to be a time-
consuming approach. However, an efficient IRP will lead you through the whole incident and
will help you approach the concerned person with an appropriate operation to resume the
victimized entity as quickly as possible. An IRP is crafted as per each company’s specific
requirements, keeping its circumstances in mind. In short, one company’s IRP differs from the
other.

What’s an Incident Response Plan in Actual Terms?

An IRP can be defined as a set of instructions to offer a structured approach to detect, resolve,
and restore the damage occurred after a cybersecurity breach (usually, referred as a security
incident). An IR plan identifies and specifies the roles and responsibilities of the IR team at the
time of the cyberattack. An IR team is more commonly known as the Computer Security Incident

1
Response Team. The team ensures that the breach can be counteracted as per the plan in the least
possible time and with more efficiency to keep the damage and cost of recovery minimal.

These types of plans are highly useful in dealing with daily work threats which include
cybercrimes, data loss, and denial of services.

Phases to Build a Robust Incident Response Plan

Even though each business follows a different IRP, all IRPs possess the same fundamental
components as they go through the same six-phase process. Each of these phases deals with a
few specific areas of requirements, which must be fulfilled to create an effective IR plan for your
organization.

Phase I—Preparation
Comprehensive preparation is the key to the very first response of the IR team toward any
cyberattack. This phase is all about setting up appropriate procedures with the right tools before
the occurrence of an incident. The major steps of this phase are as follows:

 identification of the most important assets and protecting them with all your efforts, and
 analysis of data collected from earlier incidents
To handle incidents, it would be convenient for you to keep a few major tools and resources in
your arsenal. It is important that you have a wide range of weaponry available. For an instance,
your organization should have multiple distinct communication and coordination mechanisms
available if one of your mechanisms fails.

Major tools, software, and resources needed to stay prepared for an incident
Use of the mentioned tool
S. no. Type of tools or resources Example of tool or resource or resource

The contact information of

all the professionals involved
(from law enforcement team
to concerned in-house
personnel). This resource
must include phone
numbers, email addresses,
individual encryption key,
and instructions to verify an
Contact information system individual’s identity

Incident handler communications For tracking the progress and

1 and facilities Issue tracking system status of the incident

2
 It will be responsible for
secure line communication
amongst the members of the
Encryption software IR team

For securing evidence and

Secure storage facility other sensitive data

It consists of removable hard

drives to store evidence and
assists incident handlers to
Digital forensic workstations acquire and analyze data

Blank removable media and It will be used for different

spare workstations, servers, purposes, from restoring a
networking equipment, and backup (spare workstations)
laptops to analyzing data (laptops)

It will be responsible for the

Digital forensic software analysis of disk images

This will include digital

cameras, audio recorders,
and anything which can be
Incident analysis hardware and Accessories for gathering used to preserve evidence
2 software evidence for the longest period

Document every technical

detail including operating
systems, applications,
protocols, and intrusion
detection and antivirus
products. The baseline will
consist of an expected
Documentation with current network, system, and
baselines application activity

Maintaining records of
critical hashes helps in
expediting the incident
analysis, verification, and
Cryptographic hashes eradication

This resource will have all

the commonly used ports
3 Incident analysis resources Port lists and Trojan horse ports

3
 This will clearly cover clean
OS and application
installations, which are
meant for restoration and
4 Incident mitigation software Image access recovery purposes

After this, start with the creation of security policies for required domains. These domains can
range from general information security, network security, server security, application security,
to several others. Once all your policy standards are defined, build a strategy to handle incidents.
While strategizing, prioritize incidents, define roles and responsibilities, remediate incidents, and
specify tools to be used for managing different incident responses, documentation of incidents,
and both internal and external communications.

The last step of this phase will be to fine-tune your IR team with simulation exercises. Regular
but different simulation exercises help the team to stay aware of the vastness of their roles and
responsibilities.

Note: Manage active audit logs for all server network aspects and components to keep your
predeployed incident handling assets in check.
A secondary aspect of this phase is prevention from incidents by ensuring the security of your
systems, networks, and applications. An IR plan should have the capability to keep the number
of incidents significantly low. This is what makes an IRP successful. Though these
responsibilities don’t fall under an incident response team, this step will definitely fill in the
required gaps of security. The most recommendable practices for preventing incidents include
network security, host security, malware prevention, and risk assessment. Even training and
making users aware of the policies and procedures for the appropriate use of networks and
systems fall under incident prevention.

Phase II—Identification
The second phase starts with the identification of the actual incident. You can start by
answering, Is this an unusual behavior? Once you figure out the type of the incident, take a look
at the affected areas of the network or the system. You will be looking for suspicious activities,
unexpected new files, unusual login attempts, unanticipated user logins or user accounts, and so
on. Thoroughly assess the situation as it simplifies the later stages. You can assess the situation
by keeping a few basic questions in mind.
 When did the attack happen?
 Which ones are the affected areas?
 What is the scope of the event?
 What is its effect on the usual functionalities?
 What is the source of the incident?
Elaborated documentation of your assessment not only helps in resolving the current situation,
but it can also be kept for future references. After the assessment of the situation, it’s time to
assess the type of incident you are facing. Usually, an incident falls under six classifications:

1. Unauthorized access

4
2. Denial of services
3. Malicious code
4. Improper usage
5. Scans/Probes/Attempted access
6. Investigation incident
Incident identification makes the whole process easier. For many organizations, this turns out to
be a challenging part for three major reasons:

 Detection of incidents through different means with different levels of detail. This could fall under
automated or manual detection. Automated detection possesses capabilities like network- and host-
based IDPSs, antivirus software, and log analyzers. But in case of manual detection (mainly reported
by users as problems), it can or can’t be detected.
 A high volume of potential signs of incidents. For example, a large-scale organization receives
thousands or even millions of intrusion detection sensor alerts on an everyday basis.
 Need for specialized technical knowledge and extensive experience for the accurate and efficient
analysis of incident-related data.
The signs of an incident can either belong to precursors or indicators. Precursor sign indicates
that the incident has the possibility to occur in the future, while an indicatorshows that an
incident may have occurred or may be occurring now.
A few of the common sources of precursors and indicators are IDPS, antivirus and antispam
software, file integrity checking software, third-party monitoring devices, operating system and
service/application logs, network device logs, information on new vulnerabilities and exploits,
and people from within and outside the organization.

Phase III—Containment
Having gathered all the necessary information about the incident, the IR team should now be
concentrating on the containment of the threat for preventing any further damage. The first step
of this phase should be to isolate the infected machine from the network and to back up all the
sensitive data of the infected system.

After this, you can go for a temporary fix to ensure that the incident won’t escalate its damage,
anymore. The primary goal of this phase is to minimize the scope and magnitude of the incident.
Make sure you gage the functional status of your infected system or network. To determine this,
you can opt for any of the listed options:

Option 1—Disconnect the infected entity and let it continue with its standalone operations

Option 2—Shut down the whole system immediately

Option 3—Let the system operate as usual and keep monitoring its activities

All these are the feasible solutions that you can opt for to contain the issue at hand.

After establishing an effective containment strategy, it’s time to pay attention to evidence
gathering and handling which doesn’t come into the picture very often. For an instance, in many
organizations, most of the malware incidents don’t qualify for evidence gathering and handling.
5
The benefits of evidence gathering are not limited to resolving an incident, but it also helps in
case of legal proceedings. Maintain an elaborate document containing the procedures for
preservation of all the shreds of evidence including infected systems. The transfer of evidence
from one party to another should always be accounted for future use. The detailed log for
evidence should contain:

 Evidence identifying information—serial number, model number, hostname, MAC and IP

addresses, and location
 Evidence holder’s Information—name, title, and phone number
 Location, time, and date with time zone for each occurrence of evidence handling
Phase IV—Eradication
In this fourth phase, the IR team should be working toward a permanent solution with the
inclusion of a process responsible for restoring all the affected entities.

Eradication is a simple process of eliminating the threat out of your infected network or system.
This phase should only start when all the other internal and external actions are completed. The
two important aspects of this phase are as follows:

1. Cleanup—The process of cleanup should include running a powerful antimalware and antivirus
software, uninstalling of the infected software, rebooting or replacing the entire operating system
and hardware (based on the scope of the incident), and rebuilding the network.
2. Notification—Notify all the personnel involved, according to the reporting chain.
It is advisable to create multiple common incident “play books” that can help the IR team to take
a consistent approach for the incident.

Phase V—Recovery
At this stage, the compromised system or the network will be brought back to life. From the data
recovery to any remaining restoration process, this phase covers it all. It takes place in two steps:

1. Service restoration—as per the corporate contingency plans

2. System/Network validation—testing and verifying the system/network in a functional state
This phase makes sure that the infected entity will be recertified as both secure and functional.

Phase VI—Lessons Learned

After the completion of the investigation, maintain detailed documentation of the complete
incident. This last stage will keep your organization prepared for any future attacks and help you
to gain value from incidents. It would be best for the IR team to arrange a review meeting after
the successful handling of an incident. In this “lessons learned” meeting, pay closer attention to
identification of necessary improvements for the existing security controls and practices. The
practice of such periodical meetings can actually limit incidents. Ensure that this review meeting
helps you in identifying existing security weaknesses and deficiencies in policies and procedures.
As per the conclusions of this meeting, you can change your current IR plan. With this step, your
IR team will evolve to reflect new threats and improved technology. This detailed document can

6
also be used to train new members of the team. And, as the last step of this phase, create a
follow-up report after each incident for future use.

Another advisable practice for IR team would be to create an awareness message for the top
management as well as for all staff on what had happened (in case of Incident) and what lessons
were learned by the IR team. The message can include end user if that incident impacts the end
user, too.

Other Crucial Elements to Keep in Mind

To ensure that your IRP is up to date and still effective, it’s important to follow the best
practices. The provided elements will help you to do so.

1. Consistent Testing
An effective IRP should be put to test before you practically activate it. The proactive work on
your IR plan will help you to find loopholes in it and you can always improvise as per your
findings.

For this, you can regularly arrange for real-time simulation exercises.

2. Flexibility with Minute Details

Keep your IR plan flexible so that the same plan can be applied to different types of
cyberattacks. On the other hand, its detailed nature will help you in organizing and recovering
the whole process systematically in the least time possible.

Do You Want a Detailed Understanding of the Incident

Response Plan?
EC-Council offers a Certified Incident Handler (E|CIH) program which is designed in
collaboration with the intelligent minds of the cybersecurity industry, and especially the incident
handling and response experts around the globe. It is developed after the rigorous industry-wide
job task analysis (JTA). The comprehensive JTA makes the E|CIH program capable of handling
all the possible combinations of task, knowledge, skill, and ability, which makes you the best fit
for scoring better opportunities.
The program covers all the phases in detail including the financial and reputational impact on the
organization. This program provides you with the hands-on lab experience with the availability
of 50 labs and 800 tools on 4 major platforms. With this E|CIH program, you will be exposed to
the widest range of security incidents.

7
After considering the cutthroat competition in the market, the program is mapped to NICE and
CREST frameworks, which makes your E|CIH credential in accordance with your professional
credibility.

Incident response
 Incident response is an organized approach to addressing and managing the aftermath of
a security breach or cyberattack, also known as an IT incident, computer incident, or
security incident. The goal is to handle the situation in a way that limits damage and
reduces recovery time and costs.
 Ideally, incident response activities are conducted by the organization's computer security
incident response team (CSIRT), a group that has been previously selected to include
information security and general IT staff as well as C-suite level members. The team may
also include representatives from the legal, human resources and public relations
departments. The CSIRT response should comply with the organization's incident
response plan (IRP), a set of written instructions that outline the organization's response
to a cyberattack.

Importance of incident response

 Any incident 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 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 the unknown as well as the
known 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 plan

 An IRP should include procedures for detecting, responding to and limiting the effects of
a data security breach.
 Incident response plans usually include instructions on how to respond to potential attack
scenarios, including data breaches, denial of service/distributed denial of service attacks,
network intrusions, virus, worms or malware outbreaks or insider threats.
 Without an incident response plan 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.

8
According to the SANS Institute, there are six key phases of an incident response plan:
 Preparation: Preparing users and IT staff to handle potential incidents should they
should arise
 Identification: Determining whether an event is, indeed, a security incident
 Containment: Limiting the damage of the incident and isolating affected systems to
prevent further damage
 Eradication: Finding the root cause of the incident, removing affected systems from the
production environment
 Recovery: Permitting affected systems back into the production environment, ensuring
no threat remains
 Lessons learned: Completing incident documentation, performing analysis to learn from
the incident and potentially improve future response efforts

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.

Who is responsible for incident response?

To properly prepare for and address incidents across the business, an organization should form a
CSIRT. This team is responsible for analyzing security breaches 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) as well as maintain
the integrity of 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

9
 researchers combine this data with an organization's records of previous incidents to
build and maintain a database of internal intelligence.
 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 office (CISO) or some other C-suite executive,
who acts as a champion and leader for the group.
 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
and also encourage best practices across the organization.
 Including the organization's general council 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, public relations specialists can help keep in touch with
team leaders and ensure accurate information is disseminated to stockholders and the
media.

What is the Difference between a SOC and a CSIRT?

Security Operation Centers (SOC)
 Think of the SOC as the brain of a cybersecurity organization. The SOC is the center of
all roles and responsibilities, seeking to protect information in the enterprise as it’s
primary goal. The SOC performs prevention, detection, incident management, and
anything to do with managing and protecting information within the company.
 The SOC also oversees the people, processes, and technology involved in all operational
aspects of cybersecurity. More often than not, companies will only have a SOC before
they establish a separate CSIRT. Typically, a CSIRT function will fall under a SOC for
maximum capabilities. The goal of a SOC is to implement and oversee cyber-related
activities to make an organization run more efficiently and protect against malicious
attacks.
Create a SOC
Some smaller companies do not need a full-blown SOC. Below are some points for your
consideration that will help decide if your organization needs a SOC:
1. The amount of sensitive data being handled has increased
2. The emerging threat landscape requires dedicated security resources
3. Your organization is growing and the number of end-points is increasing
4. Standard processes and ownership over security are non-existent
5. ROI on security is not going according to plan

10
 6. You need to improve monitoring and response capabilities
7. Your Manager Security Service Provider (MSSP) is outdated
Computer Security Incident Response Team (CSIRT)
 The Computer Security Incident Response Team (CSIRT), is a center of information
security, incident management and response in an organization. A SOC may be used to
guide the CSIRT or the CSIRT may act as the company’s main cybersecurity outlet.
 Having said that, what are actual differences between the CSIRT and a SOC? The CSIRT
enables an organization to have many hands working on a function, therefore minimizing
and controlling the resulting damage of an incident. You also need the team to be
transparent with what has happened; they need to communicate to customers, board
members, and possibly the public of just how the incident has affected the company. If
the incident was perpetrated by an internal actor, legal action will need to be pursued
against the individual.

CSIRT: Why Should it be Created?

 The CSIRT has the abilities to rank and escalates alerts and tasks, coordinate and execute
response strategies, and develop communication plans for all departments. The CSIRT
can be a formal or an informal team depending on your company’s needs; it will depend
on threats that your organization is facing.
 If your organization is in a high-visibility industry (government, healthcare, etc.) were
responding to threats is of higher priority and a critical part of business strategy, a full-
time CSIRT may be necessary. The CSIRT can evolve over time; it can start off
informally and later evolve into a fully developed organizational function.
 No matter what company or team you have leading your security against cyber attacks,
you must ensure the proper plan and products are in place. You need the best of the best,
CyberSponse, can help centralize and navigate your team through the cybersecurity world
by organizing tools to alerts.
 Building an effective security organization requires a mix of the right people, processes,
and technologies, and there are many different ways in which you can organize your
security team and strategy.
 Two types of teams you most often hear about are security operations centers (or SOCs)
and computer security incident response teams (or CSIRTs). Which one is best for your
organization depends on a few factors. Let's cover the differences between the structure
of each team type, and how to decide which best suits your organization.
What is a SOC?
 A security operations center, or SOC for short, centralizes the roles responsible for
protecting information security in the organization, and includes prevention; detection;
incident management and response; reporting; governance, risk, and compliance; and
anything to do with managing and defending information security within the
organization.

11
  SOCs often have regulatory requirements—such as PCI DSS or CESG GPG53—
and oversee the people, process, and technology involved in all these
operational aspects. More often than not, a company will have a SOC before they have a
separate CSIRT, or the CSIRT function will initially roll under the SOC. Sometimes, a
CSIRT will exist before a formal SOC is created.
 The goal of a SOC is to implement and oversee network, application, cloud, and user
security, among other operational functions.
SOC Team Responsibilities
 Executing against the overall company security strategy under the head of security
 Overseeing the security of systems, applications, and users
 Integrating security systems with other operational tools
 Preventing, detecting, and responding to ongoing security threats
 Governance, risk, and compliance
 Policy and procedure creation and management
If there is no formal CSIRT, the SOC will also be responsible for incident response. If there is a
CSIRT in place, the SOC will aid the CSIRT in gathering all the necessary information to
respond effectively to a threat.
When to Create a SOC
While smaller organizations may not require a full-blown SOC, there are several factors that
indicate it’s time to create one. In this post, we explain the seven key indicators in detail:
1. Your organization is handling increasing amounts of sensitive data
2. Your emerging threat landscape requires dedicated security resources
3. Your organization is growing
4. There are no standard processes, procedures, or ownership over security
5. It’s difficult to measure the ROI on security spend because security is a part of another
function (e.g. IT)
6. You need improved monitoring and response capabilities
7. You’ve outgrown your managed security service provider (MSSP)
When a company feels strained by one or more of the above indicators, it’s likely time to
implement a SOC. When your organization is ready, here’s our step-by-step guide to structuring
a SOC team.
SOC Roles

12
A SOC centralizes everyone with a role in security under one umbrella. Depending on the mix of
security employees within your org, this could include, among other titles:
 Security analysts
 Security engineers
 Security architects
 Security directors and/or managers
 Head of Security (VP or CISO)
All of these roles will likely roll up under the direction of a CISO or VP of Security who
oversees the strategy and execution of the SOC. C-level management may not be involved in the
day-to-day operation of the SOC, as they are most often collaborating with other departments
(e.g. IT, Product and Development), but they are the kingpin of the organization.
What is a CSIRT?
 A computer security incident response team—or CSIRT for short, and sometimes called a
CERT or CIRT—is a centralized function for information security incident management
and response in an organization. It may roll up under a SOC, or it may act as the main
security organization depending on your company’s structure and security needs. It may
also exist as a separate team in larger organizations.
 What makes a CSIRT distinctly different from a SOC is that it’s usually a
conglomeration of roles across the enterprise that are involved in all types of incident
response functions. While incident responders are, of course, at the helm of the incident
response process itself, other functions—including public relations (PR), marketing,
customer support, and management—often collaborate with a CSIRT, though do not
report into that department (see full list of CSIRT roles below).
 The ultimate goal of a CSIRT is to minimize and control the damage resulting from an
incident, which is why so many different functions can be involved in some capacity.
You need to not only address the threat itself, but also communicate to customers, your
board, and the public about the incident. If a malicious internal actor caused the event,
disciplinary, and perhaps legal action will need to be taken on involved employees.
CSIRT Team Responsibilities
 Preventing, detecting, and responding to ongoing security threats
 Ranking and escalating alerts and tasks
 Investigating, analyzing, and conducting deeper forensics on incidents
 Developing communication plans (for public relations, customers, board members, etc.)
 Coordinating and executing response strategies

13
  Maintaining a repository of log data related to events for future reference, as well as for
compliance or legal purposes
When to Create a CSIRT
 The CSIRT may be a formal or informal organization, depending on your company’s
unique needs. If you’re not faced with threats on a regular basis, the CSIRT may come
together only on an as-needed basis. But if you’re in a high-risk industry (e.g.
government, healthcare, finance) where responding to threats is a regular and vital part of
your business strategy, a formal and full-time CSIRT may be necessary.
 Your CSIRT may evolve over time, too. While it may start off as an informal team that
gathers on an as-needed basis, it may develop into a full-on function if incident response
needs necessitate it.
CSIRT Roles
 Security analysts
 Event and incident handlers
 Network and system administrators
 Security management
 C-level managers (e.g. CIO, CISO, CTO, CRO)
CSIRT Collaborators
 Human resources
 Public relations
 Marketing
 Customer support
 Product and engineering teams
 ...and more
Defining Your Path
Whichever type of team is required for your organization, be sure that roles are clearly defined,
processes are efficient and can be automated, and the right technologies are in place that enable
your team to do their jobs better and faster.

Computer Security Incident Response Team (CSIRT

 A computer incident response team (CIRT) is a group that handles events involving
computer security breaches. Although most organizations have measures in place to
prevent security problems, such events may still occur unexpectedly and must be handled

14
 efficiently by CIRT experts, which include team members from specified departments
and specialties.
 A Computer Security Incident Response Team (CSIRT, pronounced "see-sirt") is an
organization that receives reports of security breaches, conducts analyses of the reports
and responds to the senders. A CSIRT may be an established group or an ad hoc
assembly.
 There are various types of CSIRTS. An internal CSIRTs is assembled as part of a parent
organization, such as a government, a corporation, a university or a research network.
National CSIRTs (one type of internal CSIRT), for example, oversee incident handling
for an entire country. Typically, internal CSIRTS gather periodically throughout the year
for proactive tasks such as DR testing, and on an as-needed basis in the event of a
security breach. External CSIRTs provide paid services on either an on-going or as-
needed basis.
CERT (Computer Emergency Readiness Team) lists the following among the roles of CSIRT
members:
 Manager or team lead.
 Assistant managers, supervisors, or group leaders.
 Hotline, help desk, or triage staff.
 Incident handlers.
 Vulnerability handlers.
 Artifact analysis staff.
 Platform specialists.
 Trainers.
 Technology watch.
 The specific services provided vary from one CSIRT to another. A computer security
incident can involve a real or suspected breach or the act of willfully causing a
vulnerability or breach. Typical incidents include the introduction of viruses or worms
into a network, DoS (denial of service) attacks, unauthorized alteration of software or
hardware, and identity theft of individuals or institutions. Hacking in general can be
considered a security incident unless the perpetrators have been deliberately hired for the
specific purpose of testing a computer or network for vulnerabilities. (In that case, the
hackers can form part of the CSIRT, in a preventive role.) CSIRTs may provide proactive
services, such as end-user security training, besides responding to incidents.
 Response time constitutes a critical consideration in assembling, maintaining and
deploying an effective CSIRT. A rapid, accurately targeted, and effective response can
minimize the overall damage to finances, hardware, and software caused by a specific
incident. Another important consideration involves the ability of the CSIRT to track

15
 down the perpetrators of an incident so that the guilty parties can be shut down and
effectively prosecuted. A third consideration involves "hardening" of the software and
infrastructure to minimize the number of incidents that take place over time.
 Alternate terms for CSIRT include CIRC (Computer Incident Response Capability),
CIRT (Computer Incident Response Team), IRC (Incident Response Center or Incident
Response Capability), IRT (Incident Response Team), SERT (Security Emergency
Response Team) and SIRT (Security Incident Response Team). Internal CSIRTs often
use one of the terms along with an identifier. The national CSIRT in the United States,
for example, is US-CERT

6 Steps of Incident Response

 Data breaches and cyber-attacks are things most businesses have learned to accept as a
possibility.
 Breaches and hacks penetrate the headlines almost daily, and as technology continues to
evolve, so do the ever-present threats associated with these types of risks.
 There are two sides to every breach: prevention and recovery.
 You’re most likely already taking steps toward protecting your organization from the
possibility of a breach, but have you planned what you will do to remain operable and
minimize damages in the event that your environment is compromised? Experiencing a
breach is disruptive, but fumbling the response is disastrous. Incident response plans are
invaluable measures that should be taken by every organization, because —let’s face it—
controls can fail, implementation can fail, and consequently, incidents are bound to
happen.
 According to The SANS Institute, an incident is defined as an “assessed occurrence
having actual or potentially adverse effects on an information system.” Incident handling
is “an action plan for dealing with intrusions, cyber-theft, denial of service, fire, floods,
and other security-related events.” Your incident response plan should include
appropriate policies and procedures that dictate to your organization what the immediate
steps are following the detection of an incident. These steps may include containment,
notification of appropriate personnel, reporting, eradication, and lessons learned.
 There are six common stages of incident response that are important when developing
your own “Incident Response Plan.” Take a look at the breakdown of the “6 Steps of
Incident Response.”

Now, ask yourself, “Are we ready?”

 Preparation. Advanced preparation is important when planning for a potential incident.

Policies and procedures should be known and tested by management and all personnel to
ensure that the recovery and remediation process will quickly address any and all

16
 incidents in a timely manner, resulting in the least amount of damage. Do you have the
necessary tools and training to handle incidents before they actually occur?
 Detection & Identification. After the incident occurs, it’s important to ask yourself a
number of questions. What kind of incident has occurred? Data theft? Insider threat?
Network attacks? Once you’ve identified the type of incident that has occurred, it’s
important to determine the severity of the incident in order to choose the best course of
action according to your predetermined Incident Response Policy and Procedures. Are
there any safety concerns for personnel that need to be considered? Has there been loss or
exposure of data? Were any laws or contracts violated? What is the size of the impact
area?
 Containment. In order to limit the impact of an incident, the containment phase of
incident response is critical. Have the right people in your organization been notified?
The faster the response time, the more likely it will be that you can reduce the damage of
the particular incident. This may mean isolating the infected or compromised area to
determine the best way to handle recovery. Do you have the right tools and personnel
needed to handle the task?
 Remediation. At this stage, it’s time to resolve the issue and remove any malicious code,
threat, personnel responsible for the incident, etc. Forensic analysis should be completed
and logs kept throughout the remediation process. Will backups need to be implemented?
What information security weaknesses need to be addressed at this time?
 Recovery. At this point, it’s time to get things back up and running and be sure that all
company policies and procedures are effectively being implemented. Continuous,
ongoing monitoring is important following remediation of an incident to be certain that it
has been fully resolved and nothing threatening is lingering in your network. Continuous
monitoring will also detect any suspicious behavior going forward.
 Lessons Learned. Compiling a detailed report of what happened and what was done as
corrective measures is a good step towards ensuring the same incident will not occur
again. Why did it happen? What could have prevented it? Does your security posture
need to be updated to ensure similar incidents won’t happen in the future? Who does this
information need to be shared with in order to make any necessary change to your
security posture?

When it comes to securing and protecting your business, preparation is equally important as
prevention. Don’t be surprised by an unexpected security incident. Develop and implement an
“Incident Response Plan.” Then, train your employees on what needs to be done to protect your
business in the aftermath of an incident, and you will be able to reduce, minimize, and address
damage caused by an unfortunate event.

Deuble says the six stages of incident response that we should be familiar with are preparation,
identification, containment, eradication, recovery and lessons learned. At each of these stages
there are a few big ticket items that we want to make sure we get right.

1 - Preparation

17
  The preparation phase is about ensuring you have the appropriate (response plans,
policies, call trees and other documents in place and that you have identified the members
of your incident response team including external entities.

Read more Without information security processes, you are flying blind

2 - Identification

 In the identification phase you need to work out whether you are dealing with an event or
an incident. This is where understanding your environment is critical as it means looking
for significant deviations from "normal" traffic baselines or other methods.

3 - Containment

 Deuble says that as you head into the containment stage you will want to work with the
business to limit the damage caused to systems and prevent any further damage from
occurring. This includes short and long term containment activities.

4 - Eradication

 During the fourth stage the emphasis is on ensuring you have a clean system ready to
restore. This may be a complete reimage of a system, or a restore from a known good
backup.

5 - Recovery

 At this point, it’s time to determine when to bring the system back in to production and
how long we monitor the system for any signs of abnormal activity.

6 - Lessons Learned

 This final stage is often skipped as the business moves back into normal operations but
it’s critical to look back and heed the lessons learned. These lessons will allow you to
incorporate additional activities and knowledge back into your incident response process
to produce better future outcomes and additional defenses.

18
Introduction

 In the IT industry, incident management is the management of activities to detect,

analyze, respond to, and correct an organization’s security situation. All the operational
security measures that the CISSP establishes decrease the possibility of a security
incident from occurring. Sadly, these events are still inevitable, no matter what
precautions are taken. Because of the inevitability of security incidents, the CISSP caters
to the need to use regimented and fully organized methodologies to identify and respond
to such security events.
 Incident response and handling are mostly associated with how an organization reacts to
any security incident. Reporting on such incidents can be stressful. In these types of high-
alert situations, the documentation tends to be overlooked while focusing on the
resolution of the issue. It will become difficult to know whether this investigation will
land in court of law or not.
Methodology

Different organizations use different terms and phases associated with incident response
processes. The NIST Computer Security Incident Handling Guide divides the incident response
lifecycle into the following four steps:

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

In the CISSP, the steps are further divided. The following eight steps are further subdivisions of
NIST’s four points:

1. Preparation

19
 2. Detection
3. Response
4. Mitigation
5. Reporting
6. Recovery
7. Remediation
8. Lessons Learned

Preparation

 Preparation can also be called the pre-incident phase. It involves the steps that are taken
before an incident occurs. In other words, this is the time in which the team prepares for
any incident. This can include training, defining policies and procedures, gathering tools
and necessary software, procuring necessary hardware equipment, etc. This phase should
include everything that can aid in faster resolution of an incident. An incident handling
checklist is also prepared at this stage.
Detection

 This is the primary and the most important step in the incident response process.
Detection, sometime also called the identification phase, is the phase in which events are
analyzed to determine whether a compromise a security incident. The organization will
not be in a great position to give a timely response to a security incident without a proper
and effective detection and analyzing mechanism. This mechanism should include an
automated and regimented operation to pull systems events/logs and bring them into an
organizational context. Context while analyzing is important because it may prevent
overlooking an event that might be important but not immediately apparent. The most
important aspect of this phase is to deal with the situation quickly and decisively, whether
the incident is currently occurring actually or has occurred in the past.
Response

 The response phase also called as containment phase. As the name suggests, this phase
deals with actual interaction of the response team with the affected system. The intent is
to try to contain further damage from occurring and affecting more systems. Responses
depend upon the scenario, but general responses might include taking a system off the
network, powering off the system, isolating traffic, and other related tasks. This phase
typically starts with forensically backing up the system involved in the incident. Volatile
memory capturing and dumping is also performed in this step before the system is
powered off.
 Bringing the systems down can have a negative impact on the organization, so receiving
permission from management to take action as well as updating them on the severity of
the incident is most important in this case. Stopping an incident from spreading is more
important than curing it at the first place it is discovered.

20
Mitigation

 Eradication is another name for the mitigation phase. It involves analyzing the incident,
including understanding the root cause. This understanding can then help in cleaning the
systems reliably and can also help in the implementation of security measures against
future incidents. The system can then be returned to a stable state after the cause is
known, preferably without risk of reoccurrence. It should be noted at this stage that the
obvious malware removal is not sufficient until the cause is known and understood.
 After the cause is known, the system is returned to a functioning state. This restoration
could involve rebuilding the system from scratch or restoring to a known backup. Root-
cause analysis plays an important and significant role in locating a trustworthy known
backup image. The timeline of events generated with the help of root-cause analysis can
help determine which iteration of the backup is safest.
 The final important part of this phase is to prevent the future impact of similar incidents.
Patching and stronger firewall configurations can be effective steps taken for future
preventions.
Reporting

 Reporting is a phase that starts from the beginning of the incident and remains to the
conclusion. Reporting must begin immediately upon the detection of the incident. The
reporting phase can be divided into two categories:

 Technical
 Non-technical
 The incident response team has the responsibility to report the technical details of the
incident. It is also crucial that they update the management about serious incidents. Non-
technical stakeholders should be updated as the incident-handling process progresses.
This is an important step in reporting and shouldn’t be ignored. Formal reporting will be
started as the process reaches its recovery phase. The incident handling team will be
preparing and sending the formal reports to technical and non-technical management staff
as they recover the systems and put them back to production.
Recovery

 As the name indicates, this phase involves the processes involved in restoring the system
to its operational state. As a normal procedure, the business unit responsible for the
system will make the decision about when the system will go back online. One must also
use caution, as there is a possibility that the infection or the attack may have persisted
through the mitigation phase. Close monitoring of the system is necessary after it has
been restored to production. Non-peak production hours are the best time for restoration
of the operations. This will make the system security monitoring a lot easier.

21
Remediation

 Remediation steps are taken during the mitigation phase, where the vulnerabilities that
are found during the root-cause analysis are mitigated. Remediation starts directly after
mitigation and later its scope becomes broader. To manage a security incident, root-cause
analysis should be performed. Root-cause analysis helps in determining the
vulnerabilities that could cause such an incident to occur. Without root-cause analysis,
the recovered system could still have a particular weakness that can affect other systems
or could even cause that incident to occur again in the future. For example, if a previous
backup is chosen that is not far back enough, the restored version could also have that
vulnerability, starting the whole cycle over again.
 Incident response is often an impromptu security area — organizations don’t think about
it until an incident occurs. Your response to an incident will be the deciding factor as to
whether or not your network will continue to operate as a part of your business. As I am
sure you are aware, security breaches never occur when a company is ready for them;
they happen at the most inopportune times. To make sure that your company is prepared
when a security breach does happen, here are some dos and don’ts of incident response.
Five Things You Need to Do When Responding to a Security Incident
1. Discreet Communication
When handling an incident, communication is important; however, it needs to be done discreetly.
It is important to remember the attacker might still have access to your systems. Therefore, you
should avoid communicating over:
 Instant messenger
 Email
 Speaker phones
Where possible, all communication should take place face to face.
2. Reset Credentials
Make sure that all passwords that have been compromised during the incident are reset.
Remember that it is most likely that an attacker will strike more than once.
3. Coordinate System Shutdown
If a compromised server is not shut down, it alerts the attacker that something is taking place
within the environment they are attempting to infiltrate. This will lead them to install another set
of tools and malware which then creates additional problems.
4. Stay Calm
It is important that you remain calm during incident response so you can follow protocol, and
handle it effectively.

22
5. Report the Attack
This should be common sense, but many cyberattacks go unreported. Regardless of whether your
organization has their own incident response team or not, it is essential that law enforcement is
contacted so that they can attempt to catch the perpetrator.
Five Things You Need to Avoid When Responding to a Security Incident
1. Communicating Too Quickly or Too Slowly
If the security incident has an effect on your customers or partners, it’s essential to have a full
understanding about the breach. This will help you come up with an effective strategy.
Understandably, upper management wants to put their partners and customers at ease. However,
putting out a message and then having to retract it with conflicting information won’t look good
and will cause additional worry.
Companies are often so overwhelmed after a breach has taken place that they fail to
communicate effectively with relevant stakeholders. When communication is too slow, you are
in danger of losing stakeholder trust in your ability to handle security incidents in a timely
manner.
The same threats are also present when information is provided too quickly. If a company
communicates too early, they run the risk of providing inaccurate, inconsistent or incomplete
information, which can cause confusion and lead people to lose trust in the company.
2. Not Apologizing
There is no such thing as a company that is completely safe from security breaches. Although
companies and customers are aware that cyber attacks are always going to be an issue,
companies are still not customer focused enough when it comes to making a formal apology to
their customers for putting them at risk. A data breach is unexpected, worrisome and traumatic
for customers, and not acknowledging this and avoiding an apology can have terrible
consequences.
3. Failure to Have a Breach Response Plan
A breach response plan is a strategy to limit the risk of unauthorized access to systems and data.
A properly outlined breach response plan plays a critical role in reducing the negative impact
that a security breach can have. It also enhances the organization’s ability to navigate through a
crisis with relative ease.
4. Not Getting Timely Legal Advice
There are severe legal implications associated with data breaches — you want to avoid these as
much as possible. It is critical that you get the right legal advice early so that you can quickly
recover from a security incident. What you don’t want is to have to deal with a class action
lawsuit because of a data breach.
5. Making the Same Mistakes Twice

23
Even the most sophisticated companies will have to deal with a data breach. However, one of the
most important aspects of dealing with a data breach is learning from your mistakes. The
incident handling process consists of six phases:
1. Preparation
2. Identification
3. Containment
4. Eradication
5. Recovery
6. Review (lessons learned)
It is recommended that after a major security incident has taken place, an organization should
hold a meeting to discuss the lessons learned. During the meeting, you will need to identify your
mistakes and evaluate them. Take inventory of what exactly happened and analyze how your
team has dealt with reducing the impact of a data breach. The lessons learned phase should be
the most important part of your post-breach activities. By implementing this strategy, not only
will you improve the performance of your team and create benchmarks for potential future
breaches, but you will also provide helpful reference and training materials.
It is important to mention that during the lessons learned phase you will uncover a number of
issues that need improving or changing. You might also find there are some things you will need
to get rid of entirely and others that you need to implement in order to improve your level of
security.
Whatever you gain from your evaluation, make sure they are taken seriously and that you hire
help from capable experts to assist in better protecting your business against data breaches.
Conclusion
It is virtually inevitable that your organization will become a victim of some type of security
breach. As companies and businesses are enhancing their levels of security, cybercriminals
continue to find ways to manipulate the system. The most important thing is that you take the
necessary precautions to protect yourself against a security breach and that you are fully prepared
for a breach when it happens. After the breach, make sure that you conduct a lesson learned
meeting and that you implement any new ideas, suggestions and recommendations to protect
your company against future attacks.

Top incident response steps: Incident response team responsibilities

Formalizing how to deal with a data security breach not only prepares the organization for the
worst, but can actually decrease the likelihood of the company becoming yet another attack
statistic in the first place.

24
This two-part guide to incident response looks at the top incident response steps organizations
should take if and when security breaks down and a breach occurs, starting with risk analysis,
incident response plan creation and testing, breach detection and threat neutralization.

1. Know your data and identify what is at risk.

 The first step toward dealing with a data breach should be to ensure the company actually
knows what data it has, and what data is most at risk of compromise. Use existing
business impact analysis and disaster recovery reports as a baseline for data classification
and location efforts.
 However, there is more to risk analysis than just knowing what data needs to be protected
and where it is located; there are also people and processes to consider. Think of risk
analysis in a holistic fashion, and perform a high-level risk assessment to identify where
any weakness in security may be found. This kind of threat assessment is best handled by
an external third-party consultancy so internal politics do not cloud the real issues.

2. Create an incident response plan.

 Once you know what data needs to be protected, create an incident response plan that will
enable your organization to best deal with any breach that should occur.
 Having a structured methodology to respond to an attack not only ensures less panic and
a better application of available resources during a time of great organizational stress, but
can also help reduce reputational damage. The plan should be updated annually and
should enable the business to identify, investigate, neutralize and notify in a managed
way, be it concerning a denial-of-service attack, website defacement or a full-on, large-
scale data theft incident. Every incident response plan will be different, dependent upon
the data the company handles and the business sector it operates in, however, some basics
are common to all:
o Create a multi-faceted response team, comprising named individuals with the
power both to make immediate managerial decisions and the technological skill to
deal with the threat on the front line. The plan should include emergency contact
details for all team members, as the bad guys do not necessarily work office
hours.
o Define how to handle emerging threats: Who should be notified and in what order
for different levels of a potential breach?
o Develop a protocol for forensic collection and preservation of evidence during
and after a breach, otherwise prosecution of perpetrators will be impossible. Also,
consult the legal department in order to ensure evidence is collected properly, so
as to be admissible in court; more on this to come later.
o Develop a protocol for disclosure to customers and media, and prepare
notification templates.
o Prepare a disclosure timetable for other interested parties, such as law
enforcement, business partners and banks.

25
3. Put your incident response plan to the test.

 Having an incident response plan is pointless unless you know it is going to work. Using
it for the first time during an actual breach is not a good idea; without testing it
beforehand, it is impossible to know if the plan is practical or whether key steps are
missing. Thus, make sure the organization implements a testing schedule that will allow
it to identify problem areas and remedy them quickly.

 The plan should clearly indicate incident response team responsibilities, and
members should not only practice plan implementation across various
scenarios, but also these should always be time-limited to simulate the stress
conditions they will face during a real incident. Ensure contact details for team
members go beyond office and home numbers: Think in terms of email,
conference call details, bridge lines, mobile numbers and so on. If your
response team cannot be contacted, your plan cannot be implemented.
 In addition, do not forget about documenting the need to document! Spell out
what will need to be documented -- such as how the incident was discovered,
by whom, the type of incident, attacker information, how the response plan
was implemented, whether it was effective and, if not, what was done post-
breach to correct those failings.
 As well as instilling the confidence that comes with knowing the plan will
work, such testing helps satisfy regulators that the organization has met any
data security compliance requirements by having an incident response policy
that is properly implemented and properly written.

4. Be properly prepared for breach detection.

 The biggest problems occur when a data security breach goes unnoticed for days or even
weeks, providing the hackers with multiple opportunities to return and wreak even more
havoc.
 Do not rely solely upon technologies to detect a breach. Ensure the staff is trained to spot
a potential breach, which could be as simple as reports of files that cannot be accessed or
servers running more slowly than usual. A procedure to report these symptoms to the
systems security team should be put in place, as well as further protocol regarding when
to contact the incident response team if the symptoms warrant it.

Neutralize the threat quickly.

 At the risk of stating the obvious, it is key to neutralize the breach threat as quickly as
possible. Unfortunately, unless the incident response team has been authorized to do so,
it's likely this will not happen.
 All too often, the best-laid incident response plans fall apart while waiting for managerial
approval regarding what action should be taken. The company has selected a response

26
 team for a reason: to respond to and deal with a breach. So ensure it has the authority to
quickly implement the actions it deems necessary. Getting management to relinquish any
responsibility will always be difficult, but it's often effective to speak in terms of the
business, and money, that could be lost by delaying response to an incident in order to get
approval from every possible stakeholder. Perhaps the easiest option, though, is to create
a truly multi-departmental team consisting of at least one senior manager or director as
well as technical experts.
 Your plan of action, commonly referred to as Incident Response (IR) is your all-too-
important “go-to” guide for necessary measures when a breach takes place. While nearly
every department, job function, and employee will be notified of an initiated IR, your
incident response team maintains its strategy, implementation, and initiation.

Tips for Constructing your Incident Response Strategy:

Safeguard

 Safeguard systems and other media so that forensic analysis can take place. If the
extraction of data appears to be ongoing, take the affected systems offline. If data
extraction is not evident, leaving systems online is advisable, as you could lose
valuable evidentiary data by taking them down.

Collect Data

 Collecting data through your researchers and analysts will be crucial during and after
an intrusion attempt or breach. This will tell you valuable information such as, how,
where, when, and why the intrusion occurred.
 Start with the time of the intrusion and work backwards in time to find relative data.
Look for recent abnormalities such as changes/modifications, system failures, errors,
status changes, administrative events, etc. Highlight all unusual activity and
abnormalities within your network traffic, as well as the time they occurred.
 Forensic tools must be used in collecting this data. Using non-forensic software on
infected systems can overwrite timelines and other crucial data. Highlight abnormalities
to help identify indicators of compromise.

Collect External Intelligence

 This information gathered by your researcher’s works in unison with data collected by
your analysts to further highlight indicators of compromise. Search for abnormalities in
MD5s, IP addresses, and domains that you discover as you’re collecting data. This step
can be completed after the intrusion is contained.

Collect Logs

 Identify all log sources within your organization, this can include Windows events,
firewalls, server and workstation operating systems, applications, security tools (anti-

27
 virus, anti-spyware, IDS, IPS, VPN, etc.), outbound proxy and end user applications, etc.
Extract and combine all information associated with the intrusion attempt or breach to a
single location for later review.

Notify

 Your response manager should notify internal departments on a need to know

basis sooner rather than later. Senior management, human resources, organization
attorneys, and Marketing/PR departments are examples of who the manager should
consider contacting. The key is to determine who needs to know and how
quickly… then begin notifying. If your internal (or possibly third-party) is not able to
identify the source or cause of the intrusion attempt or breach, audit and risk management
specialists should be contacted and brought in to assess the incident.
 External communication of the breach is just as important as internally notifying
personnel. In fact, timing of external communications is arguably more delicate than that
of internal notifications.

Your IR team should strictly adhere to your specific protocol. Deviations can increase
vulnerability for subsequent attacks or improper analyses, leaving your door open for future
attacks.

5 Steps to a Better Incident Response Plan

To create, assess and improve your incident response plan, follow these five steps:

Determine if There Really Is an Incident

 An effective incident response plan should include clear guidelines for when and how a
security incident is declared. Often, security incidents emerge as merely a set of disparate
indicators.

 Define the criteria for a major and minor incident type, and outline the required
procedures to follow after each type of incident. Standardize severity level assessments
across your entire organization, and include definitions of appropriate response times. By
establishing a dispute resolution process, harmful communication conflicts can be
avoided during security incidents.

Establish Incident Response Roles and Responsibilities

 If you've concluded that an incident has occurred and follow-up is required, knowing
who is responsible for each step of an incident response plan is critical.
 Roles, responsibilities and authority levels for all response team members should be
determined well in advance of an incident. The team should also continually have access
to any supporting resources or materials they may need. Some incidents may require
support from other departments, like legal, HR, communications or executive leadership.
Make sure you've identified these departments and discussed your IR plan with them
ahead of time.

28
Test and Improve the Incident Response Plan
 One of the most important steps in maintaining an effective IR plan is taking a step back
and evaluating how a security incident unfolded.
 Could the response team have done anything better?
 Was detection and analysis of the incident effective?
 Was the threat contained and eradicated in a timely manner?
 Was information successfully shared across the organization during the incident?

 After considering these questions, you'll be able to better assess your response team's
decision-making skills. You can also better evaluate if and how roles and responsibilities
need to be adjusted to strengthen security. Make sure all departments -- not just the
response team -- are involved in this post-incident evaluation process. Better coordination
and understanding of incident management skills requires consensus across multiple
departments.

Plan and Practice Internal Communications

 It's critical to review and test your internal communication plan before a security incident
occurs. Practicing the communication chain saves precious time when an event escalates.
Time is of the essence, and communication networks tend to be the first resource to break
down during security incidents.

 Make sure every response team member has identified and contacted their alternate, as
well as their counterpart in the business and information technology teams. Remember to
keep communication records for any third-party vendors your organization works with, as
well as their emergency contact procedures. Lastly, establish a protocol for identifying a
crisis command center, if needed.
 It's also important to consider the communication with the correct people outside your
immediate organization in the event of a security incident. When should an event involve
other departments? Then identify who those contacts are across the organization and how
you will engage with them.

 Also, assign someone within your organization to handle all media communications, and
make sure your support team or help desk prepares an automated message to prevent its
staff from becoming overwhelmed during an incident.

Understand Impact of Security Incidents

 Given the number of high-profile data breaches and the growing threat of identity theft,
consumers are especially sensitive about their personal data being put in danger.
Organizations need to understand exactly what is at risk in any and all security incidents,
and how that can have a negative impact on their business and reputation.
 Even minor security incidents can cripple organizations when you consider the costs
associated with data loss: tarnished brand reputation, customer abandonment, legal fees
and cyber security repair. Estimate the costs of extended loss of business, and determine
where the greatest impacts would be.

29
  Cyberattacks are an unfortunate reality. As long as organizations have something
valuable to protect, security incidents will be a part of doing business.
 But cyber security incidents don't have to be disastrous; organizations can manage them,
quickly return to normal operations and continue to thrive in the face of growing cyber
threats. The key: Prepare and provision your incident response plan today, before an
incident occurs.

A Definition of Security Incident Management

 Security incident management is the process of identifying, managing, recording and
analyzing security threats or incidents in real-time. It seeks to give a robust and
comprehensive view of any security issues within an IT infrastructure. A security
incident can be anything from an active threat to an attempted intrusion to a successful
compromise or data breach. Policy violations and unauthorized access to data such as
health, financial, social security numbers, and personally identifiable records are all
examples of security incidents.
The Cybersecurity Incident Management Process
 As cybersecurity threats continue to grow in volume and sophistication, organizations are
adopting practices that allow them to rapidly identify, respond to, and mitigate these
types of incidents while becoming more resilient and protecting against future incidents.
 Security incident management utilizes a combination of appliances, software systems,
and human-driven investigation and analysis. The security incident management process
typically starts with an alert that an incident has occurred and engagement of the incident
response team. From there, incident responders will investigate and analyze the incident
to determine its scope, assess damages, and develop a plan for mitigation.
This means that a multi-faceted strategy for security incident management must be implemented
to ensure the IT environment is truly secure. The ISO/IEC Standard 27035 outlines a five-step
process for security incident management, including:
1. Prepare for handling incidents.
2. Identify potential security incidents through monitoring and report all incidents.
3. Assess identified incidents to determine the appropriate next steps for mitigating the risk.
4. Respond to the incident by containing, investigating, and resolving it (based on outcome
of step 3).
5. Learn and document key takeaways from every incident.
How Security Incident Management Works
 While incident response measures can vary depending on the organization and related
business functions, there are general steps that are often taken to manage threats. The first

30
 step may start with a full investigation of an anomalous system or irregularity within
system, data, or user behavior.
 For example, a security incident management team may identify a server that is operating
more slowly than normal. From there the team will assess the issue to determine whether
the behavior is the result of a security incident. If that proves to be the case, then the
incident will be analyzed further; information is collected and documented to figure out
the scope of the incident and steps required for resolution, and a detailed report is written
of the security incident.
 If needed, law enforcement may be involved. If the incident involves exposure or theft of
sensitive customer records, then a public announcement may be made with the
involvement of executive management and a public relations team.
Best Practices for Security Incident Management
Organizations of all sizes and types need to plan for the security incident management process.
Implement these best practices to develop a comprehensive security incident management plan:
 Develop a security incident management plan and supporting policies that include
guidance on how incidents are detected, reported, assessed, and responded to. Have a
checklist ready for a set of actions based on the threat. Continuously update security
incident management procedures as necessary, particularly with lessons learned from
prior incidents.
 Establish an incident response team (sometimes called a CSIRT) including clearly
defined roles and responsibilities. Your incident response team should include functional
roles within the IT/security department as well as representation for other departments
such as legal, communications, finance, and business management or operations.
 Develop a comprehensive training program for every activity necessary within the set of
security incident management procedures. Practice your security incident management
plan with test scenarios on a consistent basis and make refinements as need be.
 After any security incident, perform a post-incident analysis to learn from your successes
and failures and make adjustments to your security program and incident management
process where needed.
In some situations, collecting evidence and analyzing forensics is a necessary component of
incident response. For these circumstances, you’ll want the following in place:
 A policy for evidence collection to ensure it is correct and sufficient – or, when
applicable, will be accepted in the court of law.
 The ability to employ forensics as needed for analysis, reporting, and investigation.
 Team members who have experience and training in forensics and functional techniques.
A strong security incident management process is imperative for reducing recovery costs,
potential liabilities, and damage to the victim organization. Organizations should evaluate and

31
select a suite of tools to improve visibility, alerting, and actionability with regard to security
incidents.

Cyber Incident Response - The 5 Important Steps

Step 1 - Is there really an incident?
 Incidents rarely emerge fully formed. Rather they start as a set of indicators, often
described as an event, that through investigation may turn into an incident that requires
follow up, or not. The response plan should include a policy that sets the parameters,
severity, and standards for when and how an incident is declared. This will define the
criteria for a major and minor incident type and set the required procedures to be
followed after each type of incident. Be sure to include any third party or vendor incident
response procedures if they are likely to be involved.
Step 2 - Who's in charge?
 When an event is escalated to an incident it is important to understand who is in charge;
roles, responsibilities, and authority are for all members of the response team should be
defined in advance. Policy-granting authority needed to fulfill the roles of team members
must be clearly communicated across the organization.
Despite all the time and effort we put in to protecting our environment, in the face of attack we
are judged purely on how efficiently and effectively we respond to it
Step 3 - Plan of Action
 The response team needs to go over what happened in order to understand what should
have been done better by means of simulations such as: • Drills • Desktop exercises •
Functional exercises • Full-scale exercises
 All of these exercise scenarios are designed to stimulate technical, operational,
communication, and/or strategic responses to cyber incidents with a view to reviewing
and refining current capabilities.
 Each exercise consists of determining what improvements could be made in: 1.
Preparation 2. Detection and analysis 3. Containment and eradication of threats 4. Post-
incident activity 5. Recovery process and getting back to business
Article 31 of the incoming General Data Protection Regulations requires us to notify the
appropriate authority of a data breach within 72 hours on learning about the exposure
Step 4 - Communication!
 In some ways, an incident response plan is only as good as its communication network.
During critical incidences, time is of the essence and communication networks tend to be
the first resource to break down for a number of reasons.
Step 5 - How does this Impact business?

32
  There have been a number of high profile data breaches in the past few years, which have
impacted millions of people. The growing threat of identity theft makes customers
especially sensitive to any of their data being at risk. As a result, companies need to
understand exactly what is at risk in each type of incident and how that could have a
negative impact on the business.

The 7 Stages of an Incident Response Plan

Today the organization you work for has their network compromised. Consequently, there is a
decent amount of valuable information lost. Your IT department has found what has been taken,
but doesn’t know what to do next. So what’s your next move?

The Seven Stages of Incident Response

1. Preparation
It is essential that every organization is prepared for the worst. So how will you handle the
situation? Preparation is key and it involves identifying the start of an incident, how to recover,
how to get everything back to normal, and creating established security policies including, but
not limited to:
 warning banners
 user privacy expectations
 established incident notification processes
 the development of an incident containment policy
 creation of incident handling checklists
 ensuring the corporate disaster recovery plan is up to date
 making sure the security risk assessment process is functioning and active
Other aspects that should be considered when prepping are training and pre-deployed incident
handling assets. When training for an incident you should contemplate different types of training
your team needs such as OS support, specialized investigative techniques, incident response tool
usage, and corporate environmental procedure requirements.

When looking at your pre-deployed incident handling assets, you want to make sure you have
certain tools in place in case of a system breach. This includes monitoring your own sensors,
probes, and monitors on critical systems, tracking databases in core systems and completing
active audit logs for all server network aspects and components.
2. Identification

33
The next stage of incident response is identifying the actual incident. The first question you want
your team to answer is; is the event an unusual activity or more? Once that answer has been
established you are going to want to check out some areas of the affected system. This includes
suspicious entries in system or network accounting, excessive login attempts, unexplained new
user accounts, unexpected new files, etc.
After you have assessed the situation there are six levels of classification when it comes to
incidents. You are going to want to evaluate which one the incident falls under.
 Level 1 – Unauthorized Access
 Level 2 – Denial of Services
 Level 3 – Malicious Code
 Level 4 – Improper Usage
 Level 5 – Scans/Probes/Attempted Access
 Level 6 – Investigation Incident
3. Containment
Once your team knows what incident level they are dealing with, the next move is to contain the
issue. The key here is to limit the scope and magnitude of the issue at hand. There are two
primary areas of coverage when doing this. These essential areas of coverage are;
1. Protecting and keeping available critical computing resources where possible
2. Determining the operational status of the infected computer, system or network.
In order to determine the operational status of your infected system and or network, you have
three options:
1. Disconnect system from the network and allow it to continue stand-alone operations
2. Shut down everything immediately
3. Continue to allow the system to run on the network and monitor the activities
All of these options are viable solutions to contain the issue at the beginning of the incident
response and should be determined a.s.a.p. to allow movement to the next stage.
4. Investigation
This is the first step in determining what actually happened to your system, computer or network.
A systematic review needs to take place on all the:
 bit-stream copies of the drives
 external storage
 real-time memory

34
  network devices logs
 system logs
 application logs
 and other supporting data.
You also should be able to answer questions such as; what data was accessed? who did it? and
what do the log reviews reveal?
It is very important to keep well-written documentation of everything you do during the
investigation, especially since external threats may require law enforcement involvement.
5. Eradication
Eradication is the process of actually getting rid of the issue on your computer, system or
network. This step should only take place after all external and internal actions are completed.
There are two important aspects of eradication which you should keep in mind. The first is
cleanup. Cleanup usually consists of running your antivirus software, uninstalling the infected
software, rebuilding the OS or replacing the entire hard drive and reconstructing the network.
The second step is notification. Notification always includes relevant personnel, both above and
below the incident response team manager in the reporting chain.
6. Recovery
This is when your company or organization returns to normalcy. There are two steps to recovery.
1. Service restoration, which is based on implementing corporate contingency plans
2. System and/or network validation, testing, and certifying the system as operational
Any component that was compromised must become re-certified as both operational and secure.
7. Follow-Up
After everything has been returned to normal there are a few follow-up questions that should be
answered to ensure the process is sufficient and effective.
 Was there sufficient prep?
 Did detection occur in a timely manner?
 Were communications conducted clearly?
 What was the cost of the incident? Did you have a Business Continuity Plan in place?
 How can we prevent it from happening again?
Once these questions are answered and improvements are made where necessary, your company
and incident response team should be ready to repeat the process.

35
This process can help your organization keep its valuable, personal information secure

36