Incident Response

1. https://www.pradeo.com/en-US/mobile-threat-protection
2. https://prod-edxapp.edx-cdn.org/assets/courseware/v1/ff408544ce4048b480fb8506af
6f84c2/asset-v1:Microsoft+INF250x+2T2019+type@asset+block/Incident-Report-Fin
al.pdf
3.
Introduction
“Global Cyber Risk Perception Survey,” a recent global survey by Marsh and Microsoft
examines cyber risk concerns and management strategies. Over 1,300 executives from
organizations of all sizes in a range of industries worldwide participated in the survey.
"Two-thirds of survey respondents ranked cybersecurity as a top five risk
management priority, but only 19% expressed high confidence in their organization’s
ability to manage and respond to a cyber event, and only 30% have developed a plan
to do so.”
Besides the above finding, the following responses were also noted.
● Most respondents cited their IT departments as the main owner for cyber risk
management.
● 75% selected “business interruption” as the most disruptive on the company’s bottom
line.
● 20% of surveyed organizations do not have cyber insurance.
● 25% are unsure of the status of their cyber insurance policy if they have one.
yberattacks often have a significant monetary impact on organizations. The level of creativity
and innovation in the tenebrous cybersecurity world is growing unabatedly. Most executives
have a deep understanding of their business and the importance of their assets; however,
many don't understand cybersecurity or how hard it is to protect those assets from a cyber
incident.
Let’s define a cybersecurity incident. A security incident is an event that affects the
confidentiality, integrity, or availability of information resources and assets in the
organization. An incident could range from minimal impact to a major incident, where
administrative access to enterprise IT systems is compromised (as happens in targeted
attacks that are frequently reported in the press).
A security incident frequently results in a breach of sensitive information, but it sometimes
results in operational or data destruction instead. A breach of personal information has
specific legal requirements in many jurisdictions.

From the 1988 “Morris worm” to ransomware cyberattacks like Petya and WannaCryp of
today, the number and sophistication of cyberattacks will continue to grow. These types of
incidents can become challenging to deal with for organizations that are not equipped or
trained to deal with managing a major crisis operation. The following are some key
takeaways from the Microsoft Enterprise Cybersecurity Group Detection and Response
team that has worked extensively to help customers respond to and recover from these
kinds of attacks.
Cyber Threat Modeling
Cyber Threat Modeling is a systematic method, or framework, to uncover and identify
possible threats. Threat modeling allows you to apply a structured approach to security and
to address the top threats that have the greatest potential impact to your organization.
“Threat modeling is needed because of the dynamic nature of security. The attack and
defense sides of security are constantly changing. As part of handling this change,
organizations should continually reassess and evolve their defenses. This includes adopting
continuous monitoring practices, security automation technologies, and threat intelligence
feeds to detect new vulnerabilities and attacks in near-real-time, allowing rapid risk
mitigation. Another key component of handling the constant change in security is having
security metrics; these can be used for more informed decision making, again often relating
to risk management in general and risk mitigation in particular” Ref: NIST SP 800-154
It is important to base the structured approach mentioned above on a standard process to
not overlook serious threat scenarios. There are several threat modeling approaches that
exist, and they typically fall into one of the following buckets: attacker point of view, systems
point of view, or a company’s assets point of view.
Some of the benefits of Cyber Threat Modeling include:
● Looking at your systems from an attacker’s viewpoint. This allows one to determine
and prioritize what needs to be protected.
● Helping you to “think like an attacker” without being the attacker. How likely is it that
this company will be attacked?
● Helping determine what mitigations should be in place. What are the consequences if
an attack is successful on an asset?
● Helping you understand your attack surface and develop a plan to reduce it.
Carnegie Mellon University (CMU) published a study of three frameworks that are
considered by them to be "exemplar approaches” –STRIDE, Security Cards, and Persona
non Grata. This blog post discusses how this evaluation will help develop a model that fuses

the best qualities of each. Reference: Cyber Threat Modeling: An Evaluation of Three
Methods. The strength and weakness of each method is reviewed in the referenced article.
Stride
The STRIDE method was developed by Microsoft and has been in use for many years.
STRIDE is an acronym consisting of the following six categories:
● Spoofing identity. An example of identity spoofing is illegally accessing and then
using another user's authentication information, such as username and password.
● Tampering with data. Data tampering involves the malicious modification of data.
Examples include unauthorized changes made to persistent data, such as that held
in a database, and the alteration of data as it flows between two computers over an
open network, such as the Internet.
● Repudiation. Repudiation threats are associated with users who deny performing an
action without other parties having any way to prove otherwise—for example, a user
performs an illegal operation in a system that lacks the ability to trace the prohibited
operations. Nonrepudiation refers to the ability of a system to counter repudiation
threats. For example, a user who purchases an item might have to sign for the item
upon receipt. The vendor can then use the signed receipt as evidence that the user
did receive the package.
● Information disclosure. Information disclosure threats involve the exposure of
information to individuals who are not supposed to have access to it—for example,
the ability of users to read a file that they were not granted access to, or the ability of
an intruder to read data in transit between two computers.
● Denial of service. Denial of service (DoS) attacks deny service to valid users—for
example, by making a Web server temporarily unavailable or unusable. You must
protect against certain types of DoS threats simply to improve system availability and
reliability.
Elevation of privilege. In this type of threat, an unprivileged user gains privileged
access and thereby has sufficient access to compromise or destroy the entire
system. Elevation of privilege threats include those situations in which an attacker
has effectively penetrated all system defenses and become part of the trusted system
itself, a dangerous situation indeed.
STRIDE uses a checklist evaluation approach made from the above listed categories.
Essentially, you look at each part of the service and determine whether any threats that fall
into any of the STRIDE categories exist for that component or process. Since this process

has been used for several years there is a good knowledge base of potential threats for each
category.
Identification and prioritization of possible attacks on each asset or possible entry point starts
the process. The goal of the process is to determine the risk associated with the identified
item and to eliminate the threats. If it is decided to skip a protection, from a risk perspective
this is valid if this decision is made on purpose, while being fully aware of all circumstances
and by applying a different countermeasure, like detection. It is a utopian idea to think all
recommendations can be fully applied; there is always a risk estimation to be made. As
taught in other courses, risks can also be transferred, accepted, and ignored. Companies
have limited investment dollars, which should be spent on protecting the highest priority
assets. But that’s the hard part about coming up with a cybersecurity strategy – it needs to
be directional and incorporate not only short-term wins but long-term investments.
The model should be used as guidance. It is important to customize by individual
organizations to best suit their risks, situations, and needs. Organizations will continue to
have unique and variable risks – different threats, different vulnerabilities, different risk
tolerances. How they implement the practices in the model to achieve positive outcomes will
vary. Any model framework should not be implemented as an un-customized checklist or a
one-size-fits-all approach for all critical infrastructure organizations.
The National Institute for Standards and Technology
(NIST) Cybersecurity Framework (CSF)
nother standards-based framework that is available is the National Institute for Standards
and Technology (NIST) Cybersecurity Framework (CSF) Subcategories. NIST’s mission is to
develop cybersecurity standards for the United States government. Though they are
originally aimed at government entities, they are used extensively across the private sector.
NIST makes the content available in the public domain. To search for content available from
NIST, go to
https://www.nist.gov/publications/search?term_node_tid_depth%5B%5D=248731
In the image, we have listed four of the five core functions defined in NIST CSF. The missing
function is Recover, which is covered in the Incident Response section in this module.

Each organization should customize the framework for implementation, by determining their
vulnerabilities, risk tolerances, and potential threats. Organizations can determine activities
that are important to critical service delivery and can prioritize investments to maximize the
impact of each dollar spent. Ultimately, the framework is aimed at reducing and better
managing cybersecurity risk.
The framework complements an organization’s risk management process and cybersecurity
program. The organization can use its current processes and leverage the Framework to
identify opportunities to strengthen and communicate to its management cybersecurity risk
while aligning with industry practices. Alternatively, an organization without an existing
cybersecurity program can use the Framework as a reference to establish one. Just as the
Framework is not industry-specific, the nomenclature of standards, guiding principles, and
practices that it provides are not country or region specific. Organizations outside the United
States may also use the Framework to strengthen their own cybersecurity efforts, and the
Framework can contribute to developing a common language for international cooperation
on critical infrastructure cybersecurity. The list below summaries the NIST documentation of
the above four functions.
Identify
● Identify: Asset Management - The data, personnel, devices, systems, and facilities
that enable the organization to achieve business purposes are identified and
managed consistent with their relative importance to business objectives and the
organization’s risk strategy.
● Identify: Business Environment - The organization’s mission, objectives,
stakeholders, and activities are understood and prioritized; this information is used to
inform cybersecurity roles, responsibilities, and risk management decisions.
● Identify: Governance - Resilience requirements to support delivery of critical
services are established.
● Identify: Risk Assessment - The organization understands the cybersecurity risk to
organizational operations (including mission, functions, image, or reputation),
organizational assets, and individuals.
● Identify: Risk Management Strategy - The organization’s priorities, constraints, risk
tolerances, and assumptions are established and used to support operational risk

decisions.
● Protect: Access Control - Access to assets and associated facilities is limited to
authorized users, processes, or devices, and to authorized activities and
transactions.
● Protect: Awareness and Training - The organization’s personnel and partners are
provided cybersecurity awareness education and are adequately trained to perform
their information security-related duties and responsibilities consistent with related
policies, procedures, and agreements.
● Protect: Data Security - Information and records (data) are managed consistent with
the organization’s risk strategy to protect the confidentiality, integrity, and availability
of information also known as C.I.A..
● Protect: Information Protection Process and Procedure - Security policies (that
address purpose, scope, roles, responsibilities, management commitment, and
coordination among organizational entities), processes, and procedures are
maintained and used to manage protection of information systems and assets.
● Protect: Maintenance - Maintenance and repairs of industrial control and
information system components is performed consistent with policies and
procedures.
● Protect: Protective Technology – It seems redundant, but the systems tasked with
ensuring the security and resilience of systems, and assets, need to be managed
and monitored to assure they conform with policies, procedures, and agreements.

● Detect: Anomalies and Events - Anomalous activity is detected in a timely manner
and the potential impact of events is understood.
● Detect: Security Continuous Monitoring - The information system and assets are
monitored at discrete intervals to identify cybersecurity events and verify the
effectiveness of protective measures.
● Detect: Detection Processes - Detection processes and procedures are maintained
and tested to ensure timely and adequate awareness of anomalous events.
● Response: Planning - Response processes and procedures are executed and
maintained, to ensure timely response to detected cybersecurity events.
● Response: Communications - Response activities are coordinated with internal and
external stakeholders, as appropriate, to include external support from law
enforcement agencies.
● Response: Analysis - Analysis is conducted to ensure adequate response and
support recovery activities.
● Response: Mitigation - Activities are performed to prevent expansion of an event,
mitigate its effects, and eradicate the incident.
● Response: Improvements - Organizational response activities are improved by
incorporating lessons learned from current and previous detection/response
activities.
After reviewing the functions listed in the previously of a security framework, it should
be clear that a company’s Framework updating is not a one-time process. Just as

your company’s assets are not stagnant, neither are the hacker’s methods. Plan to
repeat the process often. if you take an ongoing and systematic approach to securing
your organization’s information systems, it’s reasonably unlikely that “script kiddies”
will be able to compromise your systems. A diligent well-resourced defender is likely
to be protected against all but the most highly resourced and persistent attackers.
Introduction
How prepared is your information technology (IT) department or administrator to handle
security incidents? Many organizations learn how to respond to security incidents only after
suffering attacks. By this time, incidents often become much costlier than needed. Proper
incident response should be an integral part of your overall security policy and risk mitigation
strategy.
There are clearly direct benefits in responding to security incidents. Some of these benefits
include the organization having a clear picture of how the breach occurred, how long the
intruder was present within the organization’s information systems, and the steps that can be
taken to ensure that attackers will not be successful leveraging similar techniques in the
future.
To successfully respond to incidents, you must:
● Minimize the number and severity of security incidents.
● Assemble the core Computer Security Incident Response Team (CSIRT).
● Define an incident response plan.
● Contain the damage.
● Minimize risks.
Typical Attack timeline
1. First Host Compromised
2. Domain Admin Compromised (24-48 hours)
3. Data exfiltration
4. Attack Detected (Average 8 months)
https://www.microsoft.com/en-us/download/details.aspx?id=36036

Prepare for a Security Incident
Unfortunately, most organizations are likely to experience one or more major incidents in
which an attacker has administrative control over the IT systems that enable your business
processes and store your critical business data.
##Your company should:
1. Prepare for a Crisis – Reduce risk to your organization with key preparations.
Review NIST Special Publication 800-184 “Guide to Cybersecurity Event Recovery.”
2. In a Crisis – Immediately limit potential damage to your organization.
This includes tips and guidance for technical, operational, legal, and communications
aspects of a major cybersecurity incident. While the following top-level tips and practices
may be valuable in managing a crisis, each incident is unique and complex. For
comprehensive guidance and specialized advice, we recommend that you should consider
engaging professional assistance for an active major incident.
In the following videos we continue looking at the Phases of Major Response. The following
chart is discussed.
Things to Remember while in an Incident

When (not if) a security incident does happen, you will need to ensure that its impact is
minimized. To minimize the number and impact of security incidents, you should:
● Keep calm – The first reports are usually wrong. Making the right decision requires
data.
● Do no harm – It is possible to stop a hacker attack by removing your systems from
the network. You have stopped the attack, but you have essentially done a denial of
service attack on yourself. In this case you have taken the wrong steps.
● Management Support - Gain management support for security policies and incident
handling.
● Be Accurate – Confirm that anything you share publicly is correct and truthful.
● Get help when needed – Investigating and responding to attacks from sophisticated
attackers benefits significantly from deep expertise and experience.
● Initiate your incident response team – Including your communications, legal, and
HR teams, as per the plan.
● Implement your response plan – Stick to the plan.
Recovery Preparations
en an incident occurs, it is too late to develop the correct processes, log analysis, GDPR and
other legal responses, data security, management responsibility, and communications
strategy that will permit an enterprise to successfully recover from the incident.
After defining the procedures and functions listed above, the incident response team should
commence regular scenario-based training, besides Red team versus Blue team exercises
described in course INF246x: Fundamentals of Cybersecurity. The goal of these training
exercises is to validate procedures and processes, as well as refresh the team’s knowledge.
Typically, these exercises will also highlight gaps and shine a spotlight on newly found
dependencies. The following recovery processes should be part of the training exercises.
Validated backup and recovery capability for critical data
● For example, preparing for a destructive attack that deletes or encrypts data (such as
ransomware) requires that you have validated your ability to recover critical data
using an offline and/or ransomware resistant backup capability (such as Microsoft
Azure Backup).
Create technical documentation/automation

● Write and validate technical documentation (and/or automation) for procedures that
are frequently required during a security incident, including:
Compromised account recovery procedures that include consideration of:
● Levels of confidence on account compromise (active attacker use, account
credentials exposed on known compromised host, suspicious account behavior, etc.)
● How to validate whether accounts were tampered with using offline backups, change
logs, or other systems of record
● Whether to reset password or rapidly recreate account
● How to handle potential conflicts/integration with the Identity Management system
during any account recreation
Compromised host recovery procedures for both workstations and servers. This
should include:
● Host OS (and Application) rebuild procedures
● System recovery procedures and criteria for when to recover vs. rebuilding of a
system
● Performing password resets and C2 channel blocking alone is ineffective without also
detecting and removing attacker malware from hosts.
● Network segregation and isolation procedures including the ability to:
● Search and monitor internet egress point logs for attacker Command and Control
(C2) channels
● Block attacker C2 channels at internet egress points
● Isolate high value assets from other endpoints in the production environment (such
as compromised workstations and servers) if feasible.
Network segregation and isolation procedures including the ability to:
● Search and monitor internet egress point logs for attacker C2 channels.
● Block attacker C2 channels at internet egress points.

● Isolate High Value Assets (HVA) from other end points in the production environment
(such as compromised workstations and servers), if feasible.
Lesson Review - Hallmarks of a Strong Response
Program
Because of the complexity of modern organizations, the ideal response program will vary
from industry to industry and organization to organization. The general attributes of a strong
incident response and recovery program are:
Strongly integrated with:
● Business priorities and leadership
● IT Operations
● Business Continuity Management and Disaster Recovery
● Context from internal and external sources
Continuous learning culture and processes:
● Postmortems performed, and lessons learned integrated
● Regular exercises and red team validation
Documentation:
● High level of familiarity with response framework by all stakeholders
● Detailed technical recovery instructions (or automation) for IT and Security
Professionals
Technical Readiness for major incidents:
● Access to technical proficiency with security systems and business critical systems
● Access to experience on operational, communications, and legal

ritical Success Factors
Module Review
Critical Success Factors
● Clear Plan and Limited Scope – Work closely with technical teams to build a clear
plan with limited scope. While plans may change based on adversary activity or new
information, you should work diligently to limit “scope creep” of additional tasks.
● Clear Plan and Ownership – Recovery operations involve many people doing many
different tasks at once, so designate a clear project lead for the operation for crisp
decision-making and good information to flow among the crisis team.
● Stakeholder communications – Work with communication teams to provide timely
updates and active expectation management for organizational stakeholders.
● Know your capabilities and know your limits – Managing major security incidents is
very challenging, complex, and new to many professionals in the industry. You
should seriously consider bringing in expertise from external organizations or
professional services if your teams are overwhelmed or aren’t confident in what to do
next.
● Capture lessons learned – Build and continually improve role-specific handbooks for
security operations, even if it’s your first incident without any written procedures.
Additional References
1. Understanding the Role of Threat Modeling in Risk Management, INFOSEC Institute,
2/28/2018
2. A Java library for parsing and programmatically using threat models on GitHub.
Supports Microsoft Threat Modeling Tool 2016
3. Threat Risk Modeling, Open Web Application Security Project (OWASP).

4. Guide to Data-Centric System Threat Modeling, Draft NIST Special Publication
800-154
5. Incident Response Reference Guide, Microsoft, EY, Edelman
6. Azure Security Center planning and operations guide
Introduction
Maintaining Confidentiality, Integrity, and Availability, also known as the CIA Triad, of an
organization’s digital assets in today's hyper-connected, distributed, business environment is
a true challenge. Doing so becomes even more difficult as the sophistication of hackers
increases. One of the mainstays that many organizations include in their protection strategy
is the creation of a Computer Security Incident Response Team (CSIRT).
The CSIRT should be the focal point for dealing with computer security incidents in your
environment. An incident begins when someone becomes aware of a potential incident. An
incident is defined broadly in NIST SP 800-61 as “a violation or imminent threat of violation
of computer security policies, acceptable use policies, or standard security practices.”
The incident response process has several phases. The initial phase involves establishing
and training an incident response team and acquiring the necessary tools and resources.
During preparation, the organization also attempts to limit the number of incidents that will
occur by selecting and implementing a set of controls based on the results of risk
assessments. The major phases of the incident response process, as defined by NIST, are
preparation, detection and analysis, containment, eradication and recovery, and
post-incident activity. The graphic below illustrates the incident response life cycle.

Observe that the process illustrated is not a linear, step by step process. Instead return
arrows point to the need, in all but the simplest of cases, for incident responders to return to
a previous stage. Note the Containment Eradication & Recovery phase has a looping arrow
back to the Detection & Analysis phase to validate that the incident has been resolved. The
intricate “dance” shown above is a normal process in a security incident response.
Preparation Actions
Your team should consist of a group of people with responsibilities for dealing with any
security incident. Team members should have clearly defined duties to ensure that no area
of your response is left uncovered.
As detailed in the Carnegie Mellon University Software Engineering Institute’s “[Action List
for Developing a Computer Security Incident Response Team (CSIRT)]
(https://resources.sei.cmu.edu/asset_files/WhitePaper/2006_019_001_53104.pdf),” before
the implementation of the CSIRT team the following actions should be addressed:
● Determine the mission, goals, and objectives of the CSIRT.
● Determine who is supported or served by the team.
● Obtain management buy in by C-level sponsors; this includes funding.
● Create a project plan. This should include the reporting structure, authority, and
where the team fits within the company’s organizational structure. Also, it should
include when the team will become operational.
● Determine the type and amount of security incident services that can be provided. Be
realistic. The scope should be smaller when you first start up.
● Cross-train the CSIRT staff. Once the staff, and the resources needed to support the
team, have been identified, cross-train to prevent a single point of failure.
● Define a workflow that includes roles and responsibilities of the team. Authority levels
of team members is important to document. Solicit feedback on the team
implementation plan.
● Create a taxonomy of terms to produce a shared understanding across the team.
● Continue to look for ways to enhance collaboration among team members and others
in the security field.

Team Duties
Assembling a team before an incident occurs is very important to your organization and will
positively influence how incidents are handled. A successful team will:
● Monitor systems for security breaches. Confirm that you have access to tools and
skills that allow you to detect advanced attackers in your environment. These
capabilities are constantly evolving, but an advanced program currently would
include:
○ Event correlation and analysis
○ Integrated threat intelligence
○ User and Entity Behavioral Analytics
○ Ability to detect with both Indicators of Compromise for historical patterns and
Indicators of Attack for evolving techniques
○ Machine learning analytics
● Serve as a central communication point, both to receive reports of security
incidents and to disseminate vital information to appropriate entities about the
incident.
● Document and catalog security incidents.
● Promote security awareness within the company to help prevent incidents from
occurring in your organization.
● Support system and network auditing through processes such as vulnerability
assessment and penetration testing.
● Learn about new vulnerabilities and attack strategies employed by attackers.
● Research new software patches.
● Analyze and develop new technologies for minimizing security vulnerabilities and
risks.
● Develop investigation and forensic capabilities. Confirm that you have access to
advanced tools and skills to investigate targeted attacks that include malware
analysis and attack activity analysis that can produce a comprehensive attack
timeline. You can get access to these capabilities by purchasing tools and hiring

analysts or you can retain access via external entities or professional services.
● Continually improve and update current systems and procedures.
Team Preparations
When you create a CSIRT, the team must be prepared to handle incidents. To prepare the
team, you should:
● Train them on the proper use and location of critical security tools. You should also
consider providing dedicated laptops that are preconfigured with these tools to
ensure that no time is wasted installing and configuring tools, so they can respond to
an incident. These systems and the associated tools must be properly protected
when not in use.
● Assemble all relevant communication information. You should ensure that you
have contact names and phone numbers for people who need to be notified. This
often includes members of the CSIRT, those responsible for supporting all your
systems, and those in charge of media relations. You will also need details for your
Internet service provider (ISP) and local and national law enforcement agencies.
Discuss with your legal counsel about contacting local law enforcement before an
incident happens. This will help you to ensure that you understand proper procedures
for communicating incidents and collecting evidence. Legal counsel should be
informed of any contacts with law enforcement.
● Validate backup and recovery capability for critical data; for example, preparing for
a destructive attack that deletes or encrypts data, such as ransomware requires that
you have validated your ability to recover critical data using an offline and/or
ransomware resistant backup capability, such as Microsoft Azure Backup.
● Place all emergency system information in a central, offline location, such as a
physical binder or an offline computer. This emergency information includes
passwords to systems, Internet Protocol (IP) addresses, router configuration
information, firewall rule set lists, copies of certification authority keys, contact names
and phone numbers, escalation procedures, and so on. This information must both
be readily available and be kept extremely physically secure.
● Create technical documentation/automation. Write and validate technical
documentation (and/or automation) for procedures that are frequently required during
a security incident, including:
○ Compromised account recovery procedures that include consideration of:
○ Levels of confidence on account compromise (active attacker use, account
credentials exposed on known compromised host, suspicious account

behavior, etc.)
○ How to validate whether accounts were tampered with using offline backups,
change logs, or other systems of record
○ Whether to reset password or rapidly recreate account
○ How to handle potential conflicts/integration with the Identity Management
system during any account recreation.
● Compromised host recovery procedures for all computing systems. This should
include:
○ Host OS (and Application) rebuild procedures
○ Cleaning procedures and criteria for when to clean vs. rebuild (if “cleaning” a
host is deemed acceptable at your organization)
○ Network segregation and isolation procedures including the ability to Search
and monitor internet egress point logs for attacker Command and Control
(C2) channels
● Network segregation and isolation procedures, including the ability to:
○ Search and monitor internet outlet point logs for attacker Command and
Control (C2) channels
○ Block attacker C2 channels at internet egress points
○ Isolate HVAs from other end points in the production environment (such as
compromised workstations and servers), if feasible.
he ideal CSIRT membership and structure depends on the type of your organization and
your risk management strategy. However, the CSIRT should generally form part or all of your
organization's security team. Inside the core team are security professionals responsible for
coordinating a response to any incident. The number of members in the CSIRT will typically
depend on the size and complexity of your organization. However, you should ensure that
there are enough members to adequately cover all the duties of the team at any time.
Establishing Team Roles
A successful CSIRT team consists of several key members.

● CSIRT Team Leader. The CSIRT must have an individual in charge of its activities.
The CSIRT Team Leader will generally be responsible for the activities of the CSIRT
and will coordinate reviews of its actions. This might lead to changes in policies and
procedures for dealing with future incidents.
● CSIRT Incident Lead. In the event of an incident, you should designate one
individual responsible for coordinating the response. The CSIRT Incident Lead has
ownership of the incident or set of related security incidents. All communication about
the event is coordinated through the Incident Lead, and when speaking with those
outside the CSIRT, he or she represents the entire CSIRT. The Incident Lead might
vary, depending on the nature of the incident and is often a different person than the
CSIRT Team Leader.
● CSIRT Associate Members. Besides the core CSIRT team, you should have several
specific individuals who handle and respond to incidents. Associate members will
come from a variety of different departments in your organization. They should
specialize in areas that are affected by security incidents but that are not dealt with
directly by the core CSIRT. Associate members can either be directly involved in an
incident or serve as entry points to delegate responsibility to a more appropriate
individual within their departments. The following are some suggested members and
their roles.
● CSIRT Lead from Legal - Much of cybersecurity incident response preparation
involves evaluating and managing legal risk. With no overarching cybersecurity law,
counsel should draw from a patchwork of statutes (e.g., state notification statues),
regulations, government enforcement proceedings, settlements, and guidance, and
litigation trends to assess risk. The legal lead should determine whether they plan to
involve law enforcement, so you can plan investigation and recovery procedures
appropriately.
● CSIRT communications lead – See next lesson for details.
● IT Contact - This member is primarily responsible for coordinating communication
between the CSIRT Incident Lead and the rest of the IT group. The IT Contact might
not have the technical expertise to respond to the incident; however, he or she will be
primarily responsible for finding people in the IT group to handle security events.
● Management - Depending on the incident, you might involve only departmental
managers, or you might involve managers across the entire organization. The
appropriate management individual will vary according to the impact, location,
severity, and type of incident. If you have a managerial point of contact, you can
quickly identify the most appropriate individual for the specific circumstances.
Management is responsible for approving and directing security policy. Management
is also responsible for determining the total impact (both financial and otherwise) of
the incident on the organization. Management directs the Communications Officer
regarding which information should be disclosed to the media and determines the

level of interaction between the Legal Representative and law enforcement agencies.
CSIRT Communications
● CSIRT communications lead. Appoint a communications lead to be part of the core
incident response team and confirm that he or she understands the response
process and cybersecurity. In the moment of a crisis, precious time and energy is
spent identifying who is leading on communications and who will speak on behalf of
an organization. There are unique nuances with communicating cybersecurity
incidents and investigations that a strong communications lead must understand to
be effective. By having him or her as part of the core team, communications and
reputation management is more likely to be properly represented during the
decision-making process.
● Develop a communications portion of existing incident response plans,
including clear ownership and approval processes. Many companies have technical
incident response plans that outline how to investigate and remediate an issue.
What’s often missing is a communications-centric portion to manage the complexity
of deciding what to disclose to whom and when.
● Map the stakeholders that may need to receive communications regarding an
incident, including customers, media, partners, regulators, employees and vendors.
This includes confirming the company understands its contractual obligations to
inform certain partners or customers. Often incidents may not require disclosure to
regulators, but they still need to be shared with enterprise customers in a timely
matter. Understanding these obligations ahead of an incident can save valuable time
during a live incident.
● Develop draft media holding statements and other materials for the major types of
incidents that are of most concern to your company. These statements are intended
to be used with the press during the early stages of an investigation when many of
the details of the issue are still unknown. It’s also important to develop key
communications considerations for each of the incidents, which can help guide
decision-making when an incident occurs. For example, if and under what
circumstances the company would pay to remove ransomware and how would they
position this decision to key stakeholders.
Host a table top exercise with members from the entire incident response team to test how
they would react to the media, customer, and regulator attention due to an incident. These
tabletops are often best done in conjunction with outside legal counsel and are intended to
focus on the non-technical aspects of incident response.
Practice-SIR

Company Information
The report begins with basic organizational information. Notice that the incident has been
resolved.
Some SIRs also have a unique ID like a globally unique identifier (GUID) associated with the
report
Incident-Overview
In the Incident Overview section of the report, a high-level report of the incident is provided.

In the post analysis, Don Funk, is characterizing all the events and incidents that have been
identified.
The incident is being classified by A Datum standardized severity rating. Their ratings are
based on the incidents impact or the degree of damage done to the organization. NIST
recommends four categories in NIST SP 800-61: None, Low, Medium, High.
The fifth category, Very High, was added by A Datum to consider the effect on their suppliers
and the stories they supply to. Some companies will rank the severity based on the cost of
the recovery effort.
What did you first notice was a possible issue?

In the Incident Report section, we characterize the effect of the incident on the organization
and the actions taken to respond to the incident.
Pertinent logs and services were reviewed that help determine the attack vector and to
validate the incident.

The systems, functionality, and address can all help determine the target and possible
network area that is not secure.
Determine it sensitive information was stored in the database. Besides business impact,
there are now privacy concerns. Legal needs to be alerted.

Plan to communicate the impact to staff, users, business owners, partners, and executive
sponsors. Validate and Verify user accounts and permissions.

What data was accessed or exfiltrated during the security incident contributes to the severity
of the incident. In NIST SP 800-61 a data impact categories rating scale is provided. Their
categories are None, Privacy Breach, Proprietary Breach, Integrity loss. The categories and
scale should all be customized to meet the business requirements of each company.
An incident could potentially corrupt data for many months prior to discovery. It is, therefore,
very important that as part of your incident response process, you determine the duration of
the incident. (File/system integrity software and intrusion detection systems can assist you in
this.) In some cases, the latest or even several prior backups might not be long enough to
get to a clean state, so you should regularly archive data backups. Azure backup service is
an excellent off-site function.
The attacker might be an employee, contractor, temporary employee, or other insider within
your organization. Without thorough, detailed documentation, identifying an inside offender
will be very difficult. Proper documentation also gives you the best chance of prosecuting
offenders. Trying to determine who attacked is a usually a very arduous effort. NIST in their
Computer Security Incident Handling Guide states “Identifying and attacking host can be a

time-consuming and futile process that can prevent a team from achieving its primary goal –
minimizing the business impact.”
Estimate for the business impact.
Attackers often use the same exploit and vulnerabilities on multiple system. Survey your
environment to look for similar attacks.
This is part of the lessons learned, recommended changes to improves organization
security. Note additional funding is usually needed to apply recommendations.

Incident Response

More Related Content

What's hot (20)

Similar to Incident Response (20)

More from MichaelRodriguesdosS1 (12)

Recently uploaded (20)

Incident Response