Chapter 6. Incident Response Teams
This chapter covers the following topics:
Computer Security Incident Response Teams (CSIRTs)
Product Security Incident Response Teams (PSIRTs)
National CSIRTs and Computer Emergency Response Teams (CERTs)
Incident response providers and managed security service providers (MSSPs)
In this chapter, you will learn the different types of incident response teams and their responsibilities. You already learned about Computer Security Incident Response Teams (CSIRTs), and in this chapter you will learn details of Product Security Incident Response Teams (PSIRTs), National CSIRTs and Computer Emergency Response Teams (CERTs), Coordination Centers, and incident response teams of Managed Security Service Providers (MSSPs).
“Do I Know This Already?” Quiz
The “Do I Know This Already?” quiz helps you identify your strengths and deficiencies in this chapter’s topics. The seven-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 6-1 outlines the major topics discussed in this chapter and the “Do I Know This Already?” quiz questions that correspond to those topics.
1. Which of the following are examples of some of the responsibilities of a corporate CSIRT and the policies it helps create? (Select all that apply.)
a. Scanning vendor customer networks
b. Incident classification and handling
c. Information classification and protection
d. Information dissemination
e. Record retentions and destruction
2. Which of the following is one of the main goals of the CSIRT?
a. To configure the organization’s firewalls
b. To monitor the organization’s IPS devices
c. To minimize and control the damage associated with incidents, provide guidance for mitigation, and work to prevent future incidents
d. To hire security professionals who will be part of the InfoSec team of the organization.
3. Which of the following are the three metrics, or “scores,” of the Common Vulnerability Scoring System (CVSS)? (Select all that apply.)
a. Baseline score
b. Base score
c. Environmental score
d. Temporal score
4. Which of the following is typically a responsibility of a PSIRT?
a. Configure the organization’s firewall
b. Monitor security logs
c. Investigate security incidents in a security operations center (SOC)
d. Disclose vulnerabilities in the organization’s products and services
5. Which of the following are core responsibilities of a national CSIRT and CERT?
a. Provide solutions for bug bounties
b. Protect their citizens by providing security vulnerability information, security awareness training, best practices, and other information
c. Provide vulnerability brokering to vendors within a country
d. Create regulations around cybersecurity within the country
6. Which of the following is an example of a coordination center?
a. Cisco PSIRT
b. Microsoft MSRC
c. CERT division of the Software Engineering Institute (SEI)
d. FIRST
7. Which of the following is an example of a managed security offering where incident response experts monitor and respond to security alerts in a security operations center (SOC)?
a. Cisco CloudLock
b. Cisco’s Active Threat Analytics (ATA)
c. Cisco Managed Firepower Service
d. Cisco Jasper
Foundation Topics
Product Security Incident Response Team (PSIRT)
National CSIRT and Computer Emergency Response Team (CERT)
Coordination center
The incident response team of a security vendor and Managed Security Service Provider (MSSP)
In this section, you will learn about CSIRTs. The rest of the incident response team types will be covered in the subsequent sections in this chapter.
The CSIRT is typically the team that works hand-in-hand with the information security teams (often called InfoSec). In smaller organizations, InfoSec and CSIRT functions may be combined and provided by the same team. In large organizations, the CSIRT focuses on the investigation of computer security incidents while the InfoSec team is tasked with the implementation of security configurations, monitoring, and policies within the organization.
Establishing a CSIRT involves the following steps:
Step 1. Defining the CSIRT constituency.
Step 2. Ensuring management and executive support.
Step 3. Making sure that the proper budget is allocated.
Step 4. Deciding where the CSIRT will reside within the organization’s hierarchy.
Step 5. Determining whether the team will be central, distributed, or virtual.
Step 6. Developing the process and policies for the CSIRT.
It is important to recognize that every organization is different, and these steps can be accomplished in parallel or in sequence. However, defining the constituency of a CSIRT is certainly one of the first steps in the process. When defining the constituency of a CSIRT, one should answer the following questions:
Who will be the “customer” of the CSIRT?
What is the scope? Will the CSIRT cover only the organization or also entities external to the organization? For example, at Cisco, all internal infrastructure and Cisco’s websites and tools (that is, Cisco.com) are a responsibility of the Cisco CSIRT, and any incident or vulnerability concerning a Cisco product or service is the responsibility of the Cisco PSIRT.
Will the CSIRT provide support for the complete organization or only for a specific area or segment? For example, an organization may have a CSIRT for traditional infrastructure and IT capabilities and a separate one dedicated to cloud security.
Will the CSIRT be responsible for part of the organization or all of it? If external entities will be included, how will they be selected?
Determining the value of a CSIRT can be challenging. One of the main questions that executives will ask is, what is the return on investment for having a CSIRT? The main goals of the CSIRT are to minimize risk, contain cyber damage, and save money by preventing incidents from happening—and when they do occur, to mitigate them efficiently. For example, the smaller the scope of the damage, the less money you need to spend to recover from a compromise (including brand reputation). Many studies in the past have covered the cost of security incidents and the cost of breaches. Also, the Ponemon Institute periodically publishes reports covering these costs. It is a good practice to review and calculate the “value add” of the CSIRT. This calculation can be used to determine when to invest more, not only in a CSIRT, but also in operational best practices. In some cases, an organization might even outsource some of the cybersecurity functions to a managed service provider, if the organization cannot afford or retain security talent.
In Chapter 5, “Introduction to Incident Response and the Incident Handling Process,” you learned that any incident response team must have several basic policies and procedures in place to operate satisfactorily, including the following:
Incident classification and handling
Information classification and protection
Information dissemination
Record retention and destruction
Acceptable usage of encryption
Engaging and cooperating with external groups (other IRTs, law enforcement, and so on)
Also, some additional policies or procedures can be defined, such as the following:
Hiring policy
Using an outsourcing organization to handle incidents
Working across multiple legal jurisdictions
Even more policies can be defined depending on the team’s circumstances. The important thing to remember is that not all policies need to be defined on the first day.
The following are great sources of information from the International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) that you can leverage when you are conscripting your policy and procedure documents:
ISO/IEC 27001:2005: Information technology – Security techniques – Information security management systems – Requirements
ISO/IEC 27002:2005: Information technology – Security techniques – Code of practice for information security management
ISO/IEC 27005:2008: Information technology – Security techniques – Information security risk management
ISO/PAS 22399:2007: Societal Security – Guidelines for Incident Preparedness and Operational Continuity Management
ISO/IEC 27033: Information technology – Security techniques – Information security incident management
Tip
CERT provides a good overview of the goals and responsibilities of a CSIRT at the following site: https://www.cert.org/incident-management/csirt-development/csirt-faq.cfm.
Product Security Incident Response Teams (PSIRTs)
Software and hardware vendors may have separate teams that handle the investigation, resolution, and disclosure of security vulnerabilities in their products and services. Typically, these teams are called Product Security Incident Response Teams (PSIRTs). Before you can understand how a PSIRT operates, you must understand what constitutes security vulnerability.
The U.S. National Institute of Standards and Technology (NIST) defines a security vulnerability as follows:
“A flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentally triggered or intentionally exploited) and result in a security breach or a violation of the system’s security policy.”
Note
There are many more definitions, but they tend to be variations on the one from the NIST.
Security Vulnerabilities and Their Severity
Why are product security vulnerabilities a concern? Because each vulnerability represents a potential risk that threat actors can use to compromise your systems and your network. Each vulnerability carries an associated amount of risk with it. One of the most widely adopted standards to calculate the severity of a given vulnerability is the Common Vulnerability Scoring System (CVSS), which has three components: base, temporal, and environmental scores. Each component is presented as a score on a scale from 0 to 10. You learned all about CVSS in the SECFND exam, so this might be a refresher.
CVSS is an industry standard maintained by FIRST that is used by many PSIRTs to convey information about the severity of vulnerabilities they disclose to their customers.
In CVSS, a vulnerability is evaluated under three aspects and a score is assigned to each of them:
The base group represents the intrinsic characteristics of a vulnerability that are constant over time and do not depend on a user-specific environment. This is the most important information and the only one that’s mandatory to obtain a vulnerability score.
The temporal group assesses the vulnerability as it changes over time.
The environmental group represents the characteristics of a vulnerability, taking into account the organizational environment.
The score for the base group is between 0 and 10, where 0 is the least severe and 10 is assigned to highly critical vulnerabilities. For example, a highly critical vulnerability could allow an attacker to remotely compromise a system and get full control. Additionally, the score comes in the form of a vector string that identifies each of the components used to make up the score.
The formula used to obtain the score takes into account various characteristics of the vulnerability and how the attacker is able to leverage these characteristics.
CVSSv3 defines several characteristics for the base, temporal, and environmental groups.
The base group defines Exploitability metrics that measure how the vulnerability can be exploited, as well as Impact metrics that measure the impact on confidentiality, integrity, and availability. In addition to these two metrics, a metric called Scope Change (S) is used to convey impact on systems that are impacted by the vulnerability but do not contain vulnerable code.
The Exploitability metrics include the following:
Attack Vector (AV) represents the level of access an attacker needs to have to exploit a vulnerability. It can assume four values:
Network (N)
Adjacent (A)
Local (L)
Physical (P)
Attack Complexity (AC) represents the conditions beyond the attacker’s control that must exist in order to exploit the vulnerability. The values can be the following:
Low (L)
High (H)
Privileges Required (PR) represents the level of privileges an attacker must have to exploit the vulnerability. The values are as follows:
None (N)
Low (L)
High (H)
User Interaction (UI) captures whether a user interaction is needed to perform an attack. The values are as follows:
None (N)
Required (R)
Scope (S) captures the impact on systems other than the system being scored. The values are as follows:
Unchanged (U)
Changed (C)
The Impact metrics include the following:
Confidentiality (C) measures the degree of impact to the confidentiality of the system. It can assume the following values:
Low (L)
Medium (M)
High (H)
Integrity (I) measures the degree of impact to the integrity of the system. It can assume the following values:
Low (L)
Medium (M)
High (H)
Availability (A) measures the degree of impact to the availability of the system. It can assume the following values:
Low (L)
Medium (M)
High (H)
The temporal group includes three metrics:
Exploit Code Maturity (E), which measures whether or not public exploit is available
Remediation Level (RL), which indicates whether a fix or workaround is available
Report Confidence (RC), which indicates the degree of confidence in the existence of the vulnerability
The environmental group includes two main metrics:
Security Requirements (CR, IR, AR), which indicate the importance of confidentiality, integrity, and availability requirements for the system
Modified Base Metrics (MAV, MAC, MAPR, MUI, MS, MC, MI, MA), which allow the organization to tweak the base metrics based on specific characteristic of the environment
For example, a vulnerability that might allow a remote attacker to crash the system by sending crafted IP packets would have the following values for the base metrics:
Access Vector (AV) would be Network because the attacker can be anywhere and can send packets remotely.
Attack Complexity (AC) would be Low because it is trivial to generate malformed IP packets (for example, via the Scapy tool).
Privilege Required (PR) would be None because there are no privileges required by the attacker on the target system.
User Interaction (UI) would also be None because the attacker does not need to interact with any user of the system in order to carry out the attack.
Scope (S) would be Unchanged if the attack does not cause other systems to fail.
Confidentiality Impact (C) would be None because the primary impact is on the availability of the system.
Integrity Impact (I) would be None because the primary impact is on the availability of the system.
Availability Impact (A) would be High because the device could become completely unavailable while crashing and reloading.
Additional examples of CVSSv3 scoring are available at the FIRST website (https://www.first.org/cvss).
Vulnerability Chaining Role in Fixing Prioritization
In numerous instances, security vulnerabilities are not exploited in isolation. Threat actors exploit more than one vulnerability “in a chain” to carry out their attack and compromise their victims. By leveraging different vulnerabilities in a chain, attackers can infiltrate progressively further into the system or network and gain more control over it. This is something that PSIRT teams must be aware of. Developers, security professionals, and users must be aware of this because chaining can change the order in which a vulnerability needs to be fixed or patched in the affected system. For instance, multiple low-severity vulnerabilities can become a severe one if they are combined.
Performing vulnerability chaining analysis is not a trivial task. Although several commercial companies claim that they can easily perform chaining analysis, in reality the methods and procedures that can be included as part of a chain vulnerability analysis are pretty much endless. PSIRT teams should utilize an approach that works for them to achieve the best end result.
Fixing Theoretical Vulnerabilities
Exploits cannot exist without a vulnerability. However, there isn’t always an exploit for a given vulnerability. From your preparation for the SECFND test, you already know the difference between a vulnerability and an exploit. Also, earlier in this chapter you were reminded of the definition of a vulnerability. As another reminder, an exploit is not a vulnerability. An exploit is a concrete manifestation, either a piece of software or a collection of reproducible steps, that leverage a given vulnerability to compromise an affected system.
In some cases, users call vulnerabilities without exploits “theoretical vulnerabilities.” One of the biggest challenges with “theoretical vulnerabilities” is that there are many smart people out there capable of exploiting them. If you do not know how to exploit a vulnerability today, it does not mean that someone else will not find a way in the future. In fact, someone else may already have found a way to exploit the vulnerability and perhaps is even selling the exploit of the vulnerability in underground markets without public knowledge.
PSIRT personnel should understand there is no such thing as an “entirely theoretical” vulnerability. Sure, having a working exploit can ease the reproducible steps and help to verify whether that same vulnerability is present in different systems. However, because an exploit may not come as part of a vulnerability, you should not completely deprioritize it.
Internally Versus Externally Found Vulnerabilities
A PSIRT can learn about a vulnerability in a product or service during internal testing or during the development phase. However, vulnerabilities can also be reported by external entities, such as security researchers, customers, and other vendors.
The dream of any vendor is to be able to find and patch all security vulnerabilities during the design and development phases. However, that is close to impossible. On the other hand, that is why a secure development lifecycle (SDL) is extremely important for any organization that produces software and hardware. Cisco has an SDL program that is documented at the following URL:
Cisco defines its SDL as “a repeatable and measurable process we’ve designed to increase the resiliency and trustworthiness of our products.” Cisco’s SDL is part of Cisco Product Development Methodology (PDM) and ISO9000 compliance requirements. It includes, but is not limited to, the following:
Base product security requirements
Third-party software (TPS) security
Secure design
Secure coding
Secure analysis
Vulnerability testing
The goal of the SDL is to provide tools and processes that are designed to accelerate the product development methodology, by developing secure, resilient, and trustworthy systems. TPS security is one of the most important tasks for any organization. Most of today’s organizations use open source and third-party libraries. This approach creates two requirements for the product security team. The first is to know what TPS libraries are used, reused, and where. The second is to patch any vulnerabilities that affect such library or TPS components. For example, if a new vulnerability in OpenSSL is disclosed, what do you have to do? Can you quickly assess the impact of such a vulnerability in all your products?
If you include commercial TPS, is the vendor of such software transparently disclosing all the security vulnerabilities, including in their software? Nowadays, many organizations are including security vulnerability disclosure SLAs in their contracts with third-party vendors. This is very important because many TPS vulnerabilities (both commercial and open source) go unpatched for many months—or even years.
TPS software security is a monumental task for any company of any size. To get a feeling of the scale of TPS code usage, visit the third-party security bulletins published by Cisco at https://tools.cisco.com/security/center/publicationListing.x?product=NonCisco#~Vulnerabilities. Another good resource is CVE Details (www.cvedetails.com).
Many tools are available on the market today to enumerate all open source components used in a product. These tools either interrogate the product source code or scan binaries for the presence of TPS. The following are a few examples:
BlackDuck Software: https://www.blackducksoftware.com
AppCheck: http://www.codenomicon.com/products/appcheck
Palamida: http://www.palamida.com
Lexumo: https://www.lexumo.com
SRC:CLR: https://www.sourceclear.com
National CSIRTs and Computer Emergency Response Teams (CERTs)
Numerous countries have their own Computer Emergency Response (or Readiness) Teams. Examples include the US-CERT (https://www.us-cert.gov), Indian Computer Emergency Response Team (http://www.cert-in.org.in), CERT Australia (https://cert.gov.au), and the Australian Computer Emergency Response Team (https://www.auscert.org.au/). The Forum of Incident Response and Security Teams (FIRST) website includes a list of all the national CERTS and other incident response teams at https://www.first.org/members/teams.
These national CERTS and CSIRTs aim to protect their citizens by providing security vulnerability information, security awareness training, best practices, and other information. For example, the following is the US-CERT mission posted at https://www.us-cert.gov/about-us:
“US-CERT’s critical mission activities include:
Providing cybersecurity protection to Federal civilian executive branch agencies through intrusion detection and prevention capabilities.
Developing timely and actionable information for distribution to federal departments and agencies; state, local, tribal and territorial (SLTT) governments; critical infrastructure owners and operators; private industry; and international organizations.
Responding to incidents and analyzing data about emerging cyber threats.
Collaborating with foreign governments and international entities to enhance the nation’s cybersecurity posture.”
Coordination Centers
Several organizations around the world also help with the coordination of security vulnerability disclosures to vendors, hardware and software providers, and security researchers.
One of the best examples is the CERT Division of the Software Engineering Institute (SEI). Their website can be accessed at cert.org, and their “About Us” page summarizes well their role and the role of many coordination centers alike:
“CERT Division of the Software Engineering Institute (SEI), we study and solve problems with widespread cybersecurity implications, research security vulnerabilities in software products, contribute to long-term changes in networked systems, and develop cutting-edge information and training to help improve cybersecurity.
We are more than a research organization. Working with software vendors, we help resolve software vulnerabilities. We develop tools, products, and methods to help organizations conduct forensic examinations, analyze vulnerabilities, and monitor large-scale networks. We help organizations determine how effective their security-related practices are. And we share our work at conferences; in blogs, webinars, and podcasts; and through our many articles, technical reports, and white papers. We collaborate with high-level government organizations, such as the U.S. Department of Defense and the Department of Homeland Security (DHS); law enforcement, including the FBI; the intelligence community; and many industry organizations.
Working together, DHS and the CERT Division meet mutually set goals in areas such as data collection and mining, statistics and trend analysis, computer and network security, incident management, insider threat, software assurance, and more. The results of this work include exercises, courses, and systems that were designed, implemented, and delivered to DHS and its customers as part of the SEI’s mission to transition SEI capabilities to the public and private sectors and improve the practice of cybersecurity.”
Incident Response Providers and Managed Security Service Providers (MSSPs)
Cisco, along with several other vendors, provides incident response and managed security services to its customers. These incident response teams and outsourced CSIRTs operate a bit different because their task is to provide support to their customers. However, they practice the tasks outlined earlier in this chapter for incident response and CSIRTs.
The following are examples of these teams and their services:
Cisco’s Incident Response Service: Provides Cisco customers with readiness or proactive services and post-breach support. The proactive services include infrastructure breach preparedness assessments, security operations readiness assessments, breach communications assessment, and security operations and incident response training. The post-breach (or reactive) services include the evaluation and investigation of the attack, countermeasure development and deployment, as well as the validation of the countermeasure effectiveness. You can obtain more information about Cisco’s Incident Response Service at http://www.cisco.com/c/dam/en/us/services/collateral/se/at-a-glance-c45-734212.pdf.
Cisco’s Active Threat Analytics (ATA) managed security service: The Cisco ATA service offers customers 24-hour continuous monitoring and advanced-analytics capabilities, combined with threat intelligence as well as security analysts and investigators to detect security threats in customer networks. More information about Cisco ATA can be obtained at https://www.cisco.com/c/en/us/products/security/managed-services.html.
Exam Preparation Tasks
Review All Key Topics
Review the most important topics in the chapter, noted with the Key Topic icon in the outer margin of the page. Table 6-2 lists these key topics and the page numbers on which each is found.
Define Key Terms
Define the following key terms from this chapter, and check your answers in the glossary:
Q&A
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. Which of the following aim to protect their citizens by providing security vulnerability information, security awareness training, best practices, and other information?
a. National CERTs
b. PSIRT
c. ATA
d. Global CERTs
2. Which of the following is the team that handles the investigation, resolution, and disclosure of security vulnerabilities in vendor products and services?
a. CSIRT
b. ICASI
c. USIRP
d. PSIRT
3. Which of the following is an example of a coordination center?
a. PSIRT
b. FIRST
c. The CERT/CC division of the Software Engineering Institute (SEI)
d. USIRP from ICASI
4. Which of the following is the most widely adopted standard to calculate the severity of a given security vulnerability?
a. VSS
b. CVSS
c. VCSS
d. CVSC
5. The CVSS base score defines Exploitability metrics that measure how a vulnerability can be exploited as well as Impact metrics that measure the impact on which of the following? (Choose three.)
a. Repudiation
b. Non-repudiation
c. Confidentiality
d. Integrity
e. Availability