Introduction to incident responseThis chapter covers the following topics:
Introduction to incident response
Information sharing and coordination
Incident response team structure
This chapter starts with an introduction to incident response and the different guidelines provided by the National Institute of Standards and Technology (NIST). In this chapter, you will learn the details about how to create an incident response plan and a good incident response process. You will also learn details about information sharing and coordination and the different incident response team structures.
The “Do I Know This Already?” quiz helps you identify your strengths and deficiencies in this chapter’s topics. The 10-question quiz, derived from the major sections in the “Foundation Topics” portion of the chapter, helps you determine how to spend your limited study time. Table 5-1 outlines the major topics discussed in this chapter and the “Do I Know This Already?” quiz questions that correspond to those topics.
Table 5-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping
|
Foundation Topics Section |
Questions Covered in This Section |
|
Introduction to Incident Response |
1 |
|
The Incident Response Plan |
2–3 |
|
The Incident Response Process |
4–6 |
|
Information Sharing and Coordination |
7–8 |
|
Incident Response Team Structure |
9–10 |
1. What NIST special publication covers the incident response process?
a. Special Publication 800-61
b. Judiciary, private, and individual investigations
c. Public, private, and corporate investigations
d. Government, corporate, and private investigations
2. Which of the following is not part of the policy elements described in NIST’s Special Publication 800-61?
a. Statement of management commitment
b. Purpose and objectives of the incident response policy
c. The scope of the incident response policy
d. Definition of QoS policies in network infrastructure devices
3. Which of the following is NIST’s definition of standard operating procedures (SOPs)?
a. A delineation of the specific IPS signatures to be deployed in the network
b. A delineation of the specific technical processes, techniques, checklists, and forms used by the incident response team
c. A delineation of the specific firewall rules to be deployed in the network
d. A suspect-led approach that’s mostly used in private investigations
4. Which of the following is not a phase of the incident response process?
a. Preparation
b. Containment, eradication, and recovery
c. Post-incident activity
d. Network monitoring phase
5. Incident prioritization is part of which phase of the incident response process?
a. Preparation
b. Containment, eradication, and recovery
c. Post-incident activity
d. Detection and analysis
6. Which of the following is not part of the post-incident activity phase?
a. Lessons learned
b. Identifying the attacking hosts
c. Using collected incident data
d. Evidence retention
7. Which of the following is a good example of an information-sharing community?
a. The National Institute of Security and Technology (NIST)
b. The National Institute of Standards and Technology (NIST)
c. The Cyber Services Information Sharing and Analysis Center (CS-ISAC)
d. The Financial Services Information Sharing and Analysis Center (FS-ISAC)
8. During the investigation and resolution of a security incident, you may also need to communicate with outside parties regarding the incident. Which of the following are examples of those external entities?
a. Law enforcement
b. Internet service providers (ISPs)
c. The vendor of your hardware and software products
d. Coordination centers
9. Which of the following is not an example of a type of incident response team?
a. Product Security Incident Response Team (PSIRT)
b. National CSIRT and Computer Emergency Response Team (CERT)
c. Incident response team of a security vendor and managed security service provider (MSSP)
d. Penetration testing team
10. Which of the following is not an example of the most common incident response team structures?
a. Product Security Incident Response Team (PSIRT)
b. Centralized incident response team
c. Distributed incident response team
d. Coordinating team
This chapter starts with an introduction to incident response. Then it describes, in detail, the incident response plan and incident response process, as defined in National Institute of Standards and Technology (NIST) Special Publication 800-61. This chapter also touches on how to share information and coordinate with external parties during the investigation of security incidents. You will also learn the different incident response team structures.
Computer security incident response is a critical component of information technology (IT) programs. The incident response process and incident handling activities can be very complex. In order for you to establish a successful incident response program, you must dedicate substantial planning and resources. Several industry resources were created to help organizations establish a computer security incident response program and learn how to handle cybersecurity incidents efficiently and effectively. One of the best resources available is NIST Special Publication 800-61, which can be obtained from the following URL:
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf
NIST developed Special Publication 800-61 due to statutory responsibilities under the Federal Information Security Management Act (FISMA) of 2002, Public Law 107-347.
You will learn the basics of the guidelines provided in NIST Special Publication 800-61 in this chapter, as required for the CCNA Cyber Ops SECOPS exam, but you should also read it and become familiar with all the topics discussed in that publication.
Before you learn the details about how to create a good incident response program within your organization, you must understand the difference between security “events” and security “incidents.” The following is from NIST Special Publication 800-61:
“An event is any observable occurrence in a system or network. Events include a user connecting to a file share, a server receiving a request for a web page, a user sending email, and a firewall blocking a connection attempt. Adverse events are events with a negative consequence, such as system crashes, packet floods, unauthorized use of system privileges, unauthorized access to sensitive data, and execution of malware that destroys data.”
According to the same document, “a computer security incident is a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices.”
Note
In Chapter 3, “Fundamentals of Intrusion Analysis,” you learned that some security events can also be false positives or true positives.
Figure 5-1 lists a few examples of security incidents.
Having a good incident response plan and incident response process will help you minimize loss or theft of information and disruption of services caused by incidents. It will also help you enhance your incident response program by using lessons learned and information obtained during the security incident.
Section 2.3 of NIST Special Publication 800-61 goes over the incident response policies, plans, and procedures, including information on how to coordinate incidents and interact with outside parties. The policy elements described in NIST Special Publication 800-61 include the following:
Statement of management commitment
Purpose and objectives of the incident response policy
The scope of the incident response policy
Definition of computer security incidents and related terms
Organizational structure and definition of roles, responsibilities, and levels of authority
Prioritization or severity ratings of incidents
Performance measures
Reporting and contact forms
NIST’s incident response plan elements include the following:
Incident response plan’s mission
Strategies and goals of the incident response plan
Senior management approval of the incident response plan
Organizational approach to incident response
How the incident response team will communicate with the rest of the organization and with other organizations
Metrics for measuring the incident response capability and its effectiveness
Roadmap for maturing the incident response capability
How the program fits into the overall organization
NIST also defines standard operating procedures (SOPs) as “a delineation of the specific technical processes, techniques, checklists, and forms used by the incident response team. SOPs should be reasonably comprehensive and detailed to ensure that the priorities of the organization are reflected in response operations.”
NIST Special Publication 800-61 goes over the major phases of the incident response process in detail. You should become familiar with that publication, as it provides additional information that will help you succeed in your security operations center (SOC). The important key points are summarized here.
NIST defines the major phases of the incident response process as illustrated in Figure 5-2.
The preparation phase includes creating and training the incident response team, as well as deploying the necessary tools and resources to successfully investigate and resolve cybersecurity incidents. In this phase, the incident response team creates a set of controls based on the results of risk assessments. The preparation phase also includes the following tasks:
Creating processes for incident handler communications and the facilities that will host the security operation center (SOC) and incident response team
Making sure that the organization has appropriate incident analysis hardware and software as well as incident mitigation software
Creating risk assessment capabilities within the organization
Making sure the organization has appropriately deployed host security, network security, and malware prevention solutions
Developing user awareness training
The detection and analysis phase is one of the most challenging phases. While some incidents are easy to detect (for example, a denial-of-service attack), many breaches and attacks are left undetected for weeks or even months. This is why detection may be the most difficult task in incident response. The typical network is full of “blind spots” where anomalous traffic goes undetected. Implementing analytics and correlation tools is critical to eliminating these network blind spots. As a result, the incident response team must react quickly to analyze and validate each incident. This is done by following a predefined process while documenting each step the analyst takes. NIST provides several recommendations for making incident analysis easier and more effective:
Profile networks and systems
Understand normal behaviors
Create a log retention policy
Perform event correlation
Maintain and use a knowledge base of information
Use Internet search engines for research
Run packet sniffers to collect additional data
Filter the data
Seek assistance from others
Keep all host clocks synchronized
Know the different types of attacks and attack vectors
Develop processes and procedures to recognize the signs of an incident
Understand the sources of precursors and indicators
Create appropriate incident documentation capabilities and processes
Create processes to effectively prioritize security incidents
Create processes to effectively communicate incident information (internal and external communications)
The containment, eradication, and recovery phase includes the following activities:
Evidence gathering and handling
Identifying the attacking hosts
Choosing a containment strategy to effectively contain and eradicate the attack, as well as to successfully recover from it
NIST Special Publication 800-61 also defines the following criteria for determining the appropriate containment, eradication, and recovery strategy:
The potential damage to and theft of resources
The need for evidence preservation
Service availability (for example, network connectivity as well as services provided to external parties)
Time and resources needed to implement the strategy
Effectiveness of the strategy (for example, partial containment or full containment)
Duration of the solution (for example, emergency workaround to be removed in four hours, temporary workaround to be removed in two weeks, or permanent solution)
The post-incident activity phase includes lessons learned, how to use collected incident data, and evidence retention. NIST Special Publication 800-61 includes several questions that can be used as guidelines during the lessons learned meeting(s):
Exactly what happened, and at what times?
How well did the staff and management perform while dealing with the incident?
Were the documented procedures followed? Were they adequate?
What information was needed sooner?
Were any steps or actions taken that might have inhibited the recovery?
What would the staff and management do differently the next time a similar incident occurs?
How could information sharing with other organizations be improved?
What corrective actions can prevent similar incidents in the future?
What precursors or indicators should be watched for in the future to detect similar incidents?
What additional tools or resources are needed to detect, analyze, and mitigate future incidents?
During the investigation and resolution of a security incident, you may also need to communicate with outside parties regarding the incident. Examples include, but are not limited to, contacting law enforcement, fielding media inquiries, seeking external expertise, and working with Internet service providers (ISPs), the vendor of your hardware and software products, threat intelligence vendor feeds, coordination centers, and members of other incident response teams. You can also share relevant incident indicator of compromise (IoC) information and other observables with industry peers. A good example of information-sharing communities includes the Financial Services Information Sharing and Analysis Center (FS-ISAC).
Your incident response plan should account for these types of interactions with outside entities. It should also include information about how to interact with your organization’s public relations (PR) department, legal department, and upper management. You should also get their buy-in when sharing information with outside parties to minimize the risk of information leakage. In other words, avoid leaking sensitive information regarding security incidents with unauthorized parties. These actions could potentially lead to additional disruption and financial loss. You should also maintain a list of all the contacts at those external entities, including a detailed list of all external communications for liability and evidentiary purposes.
In Chapter 6, “Incident Response Teams,” you will learn all the details about incident response teams. There are different incident response teams. The most popular is the Computer Incident Response Team (CSIRT) within your organization. Others include the following:
Product Security Incident Response Team (PSIRT)
National CSIRTs and Computer Emergency Response Team (CERT)
Coordination center
Incident response teams of security vendors and managed security service providers (MSSP)
The following are the most common incident response team structures:
Centralized incident response team
Distributed incident response team
Coordinating team
The following are the most common incident response team staffing models:
Employees
Partially outsourced
Fully outsourced
The Vocabulary for Event Recording and Incident Sharing (VERIS) is a collection of schemas and a common language for describing security incidents in a standard way. VERIS was first created by a team of cybersecurity professionals from Verizon and other industry peers. It has now been adopted by many security teams in the industry.
The VERIS documentation can be found at: http://veriscommunity.net/index.xhtml
Tip
You will learn all the elements of the VERIS schema in this chapter, but it is recommended that you review and become familiar with the VERIS documentation at the VERIS website (http://veriscommunity.net). You can also access several tools that the community has created at their GitHub repository at: https://github.com/vz-risk.
The VERIS schema and examples can be accessed at the VERIS GitHub repository at: https://github.com/vz-risk/veris.
The VERIS schema is divided into the following five main sections:
Incident Tracking
Victim Demographics
Incident Description
Discovery & Response
Impact Assessment
Figure 5-3 includes a mind-map that illustrates these five sections and their related elements.
As you can see in Figure 5-3, the Incident Tracking section contains the following elements:
Incident ID—an identifier for the incident.
Source ID—the source or handler ID of the incident.
Incident Confirmation—whether the security incident has been confirmed or not confirmed.
Incident Summary—the summary of the incident.
Related Incidents—any other related incidents.
Confidence Rating—an enumerated list that describes how certain you are that the information pertaining to this incident is complete.
Incident Notes—any additional notes that may be relevant to the incident description.
The Victim Demographics section contains the following elements:
Victim ID—an identifier of the victim.
Primary Industry—the victim’s primary industry (for example, healthcare, manufacturing, banking, IT, and so on).
Country of Operation—the country the victim operates in
State—the state or region of operation.
Number of Employees—the number of employees of the victim organization.
Annual Revenue—the annual revenue of the victim organization.
Locations Affected—the locations affected by the incident.
Notes—any additional notes about the victim.
Additional Guidance—any additional guidance you may want to provide about the victim and incident.
The Incident Description section contains the following elements:
Actors—the known threat actors.
Actions—the actions taken by the threat actor(s).
Assets—the assets that were compromised.
Attributes—any additional attributes related to the CIA triad.
The Discovery & Response section contains the following elements:
Incident Timeline—the incident timeline.
Discovery Method—the methodology used to discover the incident.
Root Causes—the incident root cause(s).
Corrective Actions—any corrective actions to mitigate and remediate the incident.
Targeted vs. Opportunistic—to describe if the incident was targeted or opportunistic.
Additional Guidance—any additional guidance about the incident.
The Impact Assessment section contains the following elements:
Loss Categorization—describes the different types of losses experienced as a result of the incident (direct or indirect losses).
Loss Estimation—an estimate of all the losses experienced because of the incident.
Estimation Currency—the currency used in the loss estimation (for example, US dollar, EURO, and so on)
Impact Rating—a rating used to describe the overall impact of the incident.
Notes—any additional notes about the impact and losses.
One of the main purposes of VERIS is to categorize incident data so that it can be used as lessons learned and shared among security professionals and many organizations. VERIS created an open source database of incident information called the VERIS Community Database (VCDB). This database can be accessed at the following GitHub repository: https://github.com/vz-risk/VCDB.
There is also a useful tool that can get you started adopting VERIS called the VERIS Incident Recording Tool and it can be accessed at: https://incident.veriscommunity.net/s3/example You can play with this tool to become familiar with all the different fields, the VERIS schema, and how to apply VERIS to your incident handling process.
Review the most important topics in the chapter, noted with the Key Topic icon in the outer margin of the page. Table 5-2 lists these key topics and the page numbers on which each is found.
|
Key Topic Element |
Description |
Page |
|
Paragraph |
What is incident response? |
144 |
|
Summary |
What are security events and incidents? |
144 |
|
Summary |
Understanding the incident response plan. |
145 |
|
Summary |
Understanding the incident response process. |
146 |
|
Summary |
Understanding information sharing and coordination. |
148 |
|
Summary |
Applying VERIS to the incident response and incident handling process. |
149 |
Print a copy of Appendix B, “Memory Tables,” (found on the book website), or at least the section for this chapter, and complete the tables and lists from memory. Appendix C, “Memory Tables Answer Key,” also on the website, includes completed tables and lists to check your work.
Define the following key terms from this chapter, and check your answers in the glossary:
The answers to these questions appear in Appendix A, “Answers to the ‘Do I Know This Already’ Quizzes and Q&A.” For more practice with exam format questions, use the exam engine on the website.
1. What is a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices?
a. Exploit
b. Vulnerability
c. Threat
d. Computer security incident
2. What is a delineation of the specific technical processes, techniques, checklists, and forms used by the incident response team?
a. CSIRT team plan
b. Standard operating procedure (SOP)
c. Standard incident plan (SIP)
d. Operation and incident plan (OIP)
3. What is any observable occurrence in a system or network?
a. Security event
b. Security incident
c. Security vulnerability
d. An exploit
4. Which of the following is not an example of the most common incident response team staffing models?
a. Employees
b. Partially outsourced
c. Fully outsourced
d. PSIRT
5. The containment, eradication, and recovery phase includes which of the following? (Choose two.)
a. Choosing a firewall to be able to block traffic proactively or during an attack
b. Choosing an intrusion prevention system to be able to block traffic proactively or during an attack
c. Choosing a containment strategy to effectively contain and eradicate the attack, as well as to be able to successfully recover from it
d. Evidence gathering and handling
6. Which phase in the incident response process includes lessons learned, how to use collected incident data, and evidence retention?
a. Post-incident activity (postmortem)
b. Containment, eradication, and recovery
c. The detection and analysis phase
d. The preparation phase
7. Which phase in the incident response process includes creating processes for incident handler communications and the facilities that will host the security operation center (SOC) and incident response team?
a. The preparation phase
b. The detection and analysis phase
c. Containment, eradication, and recovery
d. Post-incident activity (postmortem)
8. Which of following are examples of the most common incident response team structures? (Choose two.)
a. Centralized incident response team
b. Partially outsourced
c. Fully outsourced
d. Distributed incident response team
9. Which of following is not an example of the VERIS main schema categories?
a. Incident Tracking
b. Victim Demographics
c. Incident Description
d. Incident Forensics ID
10. Which of following is not an example of an element in the Incident Description section of the VERIS schema?
a. Actors
b. Actions
c. Victims and Losses
d. Attributes
