Chapter 09: Building an Incident Response Program Flashcards
Security Event
An event is an obvservable occurrence in a system or network
A security event is any observable occurrence that relates to a security function
Examples:
* A user accessing a file stored on a server
* An admin chanigng permissions on a shared folder
* An attacker conducting a port scan
Adverse Event
Any event that has negative consequences
Examples:
* Malware infection on a system
* Server crash
* Usera ccessinga. file that they’re not authorized to view
Security Incident
A violation or imminent threat of violation of computer security policies, AUPs, or standard security practices
Examples:
* Accidental loss of sensitive information
* Intrusion into a computer system by an attacker
* Use of a keylogger on an executive’s system to steal credentials
* Launch of a DoS attack against a website
CSIRT
Computer Security Incident Response Team
Teams responsible for responding to security incidents that occur within an org by following standardized response procedures and incorporating their subject matter expertise and professional judgment
Phases of Incident Response
Orgs depend on members of the CSIRT to respond calmly and consistently in the event of a security incident
The crisis-like atmosphere that surrounds many security incidents can lead to poor decision making, unless the org has a clearly thought out and refined process that describes how they’ll handle it
NIST has a simple incident response process:
* Preparation
* Detection and Analysis
* Containment, Eradication, and Recovery
* Post-Incident Activity
CSIRT Team Expectations
The CSIRT requires careful preparation to ensure that the CSIRT has the:
* Proper policy foundation
* Operating procedures that will be effective in the org’s computing environment
* Receives appropriate training
* Prepared to respond to an incident
Preparation
In this phase, you build strong defenses and a defense in depth approach to reduce the likelihood and impact of future incidents
This means sometimes including people outside of the CSIRT in your response plans
During the preparation phase, the org should:
* Conduct training
* Conduct testing
* Document procedures
* Assemble the hardware, software, and information required to conduct and incident investigation
NIST recommends that every org’s incident response toolkit should include, at a minimum, the following:
* Digital forensics workstations
* Backup devices
* Laptops for data collection, analysis, and reporting
* Spare server and networking equipment
* Blank removable media
* Portable printer
* Forensic and packet capture software
* Bootable USB media containing trusted copies of forensic tools
* Office supplies and evidence collection materials
NOTE: The preparation phase is not a “one and done” planning process—whenever an org is not actively involved in an incident response effort, it should be planning for the next incident
Dion’s Preparation Phase
* Preparing for IR involves documenting procedures, putting resources and procedures in place, and conducting training
* Call List: Predefined list of IR contacts in hierarchical order for notification of escalation
* Incident Form: Records the detail about the reporting of an incident and assigns it a case or job number
* Date, time, and location
* Report and incident handler names
* How incident was observed / detected
* Type of incident
* Scope of incident
* Incident description and event logging
NIST 800-61
This publication contains a wealth of information that’s useful to both government agencies and private orgnaizations who want to develop incident response plans
It describes four major categories of security event indicators
Alerts
* That originate from IDS/IPS, SIEM, antivirus software, file integrity checking software, and/or third-party monitoring services
Logs
* Generated by OS, services, apps, network devices, and network flows
Publicly Available Information
* About new vulnerabilities and exploits detected in the wild, or in a controlled lab environment
People
* From inside the org or external sources who report suspicious activity that may indicate a security incident is in progress
Detection and Analysis
When any of the information sources—alerts, logs, publicly available info, or people—indicate that a security incident may be occurring, analysts should shift into the initial validation mode
This is where you attempt to determine whether an incident is taking place that merits further activation of the incident response process
NIST recommends the following actions to improve the effectiveness of incident analysis:
Profile networks and systems to measure the characteristics of expected activity
* This will improve the org’s ability to identiy if abnormal activity during the detection and analysis process
Understand normal behavior of users, systems, networks, and apps
* This behavior will vary between orgs at different times of the day, week, and year, and with changes in the business cycle
* A solid understanding of normal behavior is critical to recognizing deviations from those patterns
Create a logging policy that specifies the information that must be logged by systems, apps, and network devices
* The policy should also specify where those log records should be stored, preferably in a centralized log management system, and the retention period for the logs
Perform event correlation to combine information from multiple sources
* This function is typically performed by a SIEM system
Synchronize clocks across servers, workstations, and network devices
* This is done to facilitate the correlation of log entries from different systems
* Orgs may easily achieve this objective by operationg a NTP server
Maintain an organizationwide knowledgebase that contains critical information about systems and apps
* This should include information about system profiles, usage patterns, and other information that may be useful to responders who aren’t familiar with the inner workings of a system
Capture network traffic as soon as an incident is suspected
* If the org doesn’t routinely capture network traffic, responders should immediately begin packet captures during the detection and analysis phase
* This information may provide critical details about an attacker’s intentions and activity
Filter information to reduce clultter
* Incident investigations generate massive amounts of information, and it’s almost impossible to interpret all of it without both inclusion and exclusion filters
* Incident response teams may wish to create some predefined filters during the preapration phase to assist with future analysis efforts
Seek assistance from external resources
* Responders should know the parameters for involving outside sources in their response efforts
* This may be as simple as conducting a Google search for a strange error message, or it may involve full-fledged coordination with other response teams
Containment, Eradication, and Recovery
After completing the incident detection and analysis phase, the CSIRT moves on to take active measures designed to contain the effects of the incident, eradicate the incident from the network, and recover normal operations
At a high-level, this phase is designed to achieve the following objectives:
1. Select a containment strategy appropriate to the incident circumstances
2. Implement the selected containment strategy to limit the damage caused by the incident
3. Gather additional evidence as needed to support the response effort and potential legal action
4. Identify the attackers and attacking systems
5. Eradicate the effects of the incident and recover normal business operations
Post-Incident Activity
Security incidents don’t end after security professionals remove attackers from the network or complete the recovery effort to restore normal business operations
Once the immediate danger has passed and normal operations resume, the CSIRT enters post-incident activity, which consists of:
* Forensic Analysis
* Root Cause Analysis
* Lessons Learned Review
* Evidence Retention
Post-Incident: Forensic Analysis
Forensic analysis techniques help you carefully and methodically sift through mountains of digital evidence to reconstruct the details of an incident
Post-Incident: Root Cause Analysis
The root cause analysis is critical to implementing a secure recovery that corrects any control deficiencies that led to the original attack
If you don’t understand how an attacker breached your security controls, it’s hard to correct and fix the controls
Post-Incident: Lessons Learned Review
During the lessons learned review, responders conduct a thorough review of the incident and their response, with a focus on improving procedures and tools for the next incident
It should be hosted by an independent facilitator who wasn’t involved in the incident response and is an objective outsider
This allows the facilitator to guide the discussion in a productive manner without participants feeling that the facilitator is advacnging a hidden agenda
NIST recommends that this discussion answer the following questions:
* Exactly what happened and at what times?
* How well did staff and management perform in responding to 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 simmilar incident occurs?
* How could information sharing with other orgs have been 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?
NOTE: Once these are answered, it’s on management to ensure that the org takes appropriate follow up actions
Post-Incident: Evidence Retention
At the conclusion of an incident, the CSIRT has likely gathered a lot of evidence
The team leader should work with staff to identify both internal and external evidence retention requirements
If the incident may result in civil litigation or criminal prosecution, the team should consult attorneys prior to discarding anything
If there’s no likelihood that the evidence will be used in court, fall back on the org’s retention policies
BC Plan
Business continuity plan
The goal is to ensure the org is able to maintain normal operations, even during an unexpected event
When an incident strikes, business continuity controls may protect the business’ core functions from disruption
NIST SP 800-34:
1. Develop a policy for contingency planning
2. Conduct a business impact analysis
3. Identify the preventative controls
4. Create recovery strategies
5. Develop the BCP
6. Test, train, and exercise the BCP
7. Maintain the BCP
DR Plan
Disaster recovery plan, subset of your BCP
The goal is to help the org quickly recover normal operations if they’re disrupted
An incident may cause service disruptions that would trigger the DR plan
Incident Response Policy
This serves as the cornerstone of an org’s incident response program
The policy should be written to guide efforts at a high level and provide the authority for incident response, and it should be approved at the highest possible level within the org (preferably by CEO)
The key is to write the policy so that it’s relatively timeless, which means it should:
* Contain statements that provide authority for incident response
* Assign responsibility to the CSIRT
* Describe the role of individual users and state organizational priorities
NIST recommends that incident response policies contain these key elements:
* Statement of management commitment
* Purpose and objectives of the policy
* Scope of the policy (to whom it applies and under what circumstances)
* Definition of cybersecurity incidents and related terms
* Organizational structure and definition of roles, responsibilities, and level of authority
* Prioritization or severity rating scheme for incidents
* Performance measures for CSIRT
* Reporting and contact forms
Incident Response Procedures and Playbooks
Procedures provide the detailed, tactical information that CSIRT members need when responding to an incident—they represent the collective wisdom of team members and subject matter experts collected during periods of calm, and are ready to be applied in the event of an actual incident
CSIRT teams will also develop playbooks that describe the specific procedures they will follow in the event of a specific type of incident
The idea with a playbook is that the team should be able to pick it up and find an operational plan for responding to the incidnet that they can follow
Playbooks are crucial in the early hours of incident response to ensure that the team has a planned, measured response to the first reports of a potential incident
Documenting the Incident Response Plan
When developing the incident response plan documentation, orgs should pay particular attention to creating tools that may be useful during an incident response
These tools should provide clear guidance to response teams that may be quickly read and interpreted during a crisis situation
EX checklist on page 354
Creating an Incident Response Team
The core incident response team consists of cyber pros with specific expertise in incident response, but it can loop in other team members on an incident-by-incident basis for their specific perspective
In large orgs, the team may be fulltime employees dedicated to incident response, where small orgs might have cyber pros that fill other fulltime roles step into CSIRT roles in the aftermath of an incident
Management should always have an active role in incident response efforts, and they may be called on during an incident response to make critical decisions about:
* Shutting down critical servers
* Communicating with law enforcement
* Press to the general public
* Assessing the impact of an incident to key stakeholders
In addition to the core team and management, the CSIRT could include reps from the following:
* Technical subject matters experts like system engineers, network admins, database admins, desktop experts, app experts
* IT support staff who may be needed to carry out actions directy by the CSIRT
* Legal counsel to ensure that the team’s actions comply with legal, policy, and regulatory requirements, and can advise team leads on compliance issues and comms with regulatory bodies
* HR staff responsible for investigating potential employee malfeasance
* PR and marketing who can coordinate with the media and general public
The CSIRT should be run by a designated leader who:
* Has clear authority to direct incident response efforts and serve as a liaison to management
* Is a skilled incident responder
* Is assigned to the CSIRT fulltime or serves in a cyber leadership position
Dion Core Team Recommendations
* IR manager
* Security analyst
* Triage analyst
* Forensic analyst
* Threat researcher
* Cross functional support (legal, HR, etc)
Incident Response Providers
Orgs may want to outsource all of their incident response to a provider
Retaining an incident response provider gives access to expertise that might not otherwise exist at the org, but it can be insanely expensive
CSIRT Scope of Control
The org’s incident response policy should clearly outline the scope of the CSIRT, inclduing answers to the following:
* What triggers the activation of the CSIRT?
* Who’s authorized to activate the CSIRT?
* Does the CSIRT cover the entire org, or is it responsible only for certain business units, information categories, or other divisions of responsibility?
* Is the CSIRT authorized to communicate with law enforcement, regulatory bodies, or other external parties? If so, which ones?
* Does the CSIRT have internal comms and/or escalation responsibilities? If so, what triggers those requirements?
Threat Classification
NIST provides the following attack vectors that are useful for classifying threats:
External/Removable Media
* An attack executed from a removable media or peripheral device
* EX: Malicious code spreading onto a system from an infected USB
Attrition
* An attack that employes brute-force methods to compromise, degrade, or destroy systems, networks or services
* EX: A DDoS intended to impair or deny access to a service or app
* EX: A brute force attack against an authentication mechanism
Web
* An attack executed from a website or web-based app
* EX: XSS used to steal credentials
* EX: Redirect to a site that exploits a browser vulnerability and installs malware
Email
* An attack executed via an email message or attachment
* EX: Exploit code disguised as an attached document
* EX: Link to a malicious website in the body of an email
Impersonaton
* An attack involving replacement of something benign with something malicious
* EX: Spoofing, MITM, rogue wireless points, SQL injection
Improper Usage
* Any incident resulting from violation of an org’s acceptable usage policies by an unauthorized user, excluding the previous categories
* EX: User installs a file-sharing software, leading to the loss of sensitive data
* EX: User performs illegal activities on a system
Loss or Theft of Equipment
* The loss or theft of a computing device or media used by the org, like a laptop, smartphone, or authentication token
Unknown
* An attack of unknown origin
Other
* An attack of known origin that doesn’t fit into any of the previous categories
Severity Classifications
Since CSIRT may investigate many security incidents each year, it’s important to use a standardized process to communicate the severity of each incident to management and other stakeholders
It assists in the prioritization and scope of incident response efforts
Two key measures to determine the severtiy are:
1. Scope of the impact
2. Types of data involved in the incident
Scope of the Impact
The scope of an incident’s impact depends on the degree of impairment that it causes the org, as well as the effort required to recover from the incident
The following are scopes to focus on:
* Functional impact
* Recoverability effort
Functional Impact
The degree of impairment that the incident causes the org
NIST recommends using four categories to describe the functional impact:
None
* No effect to the org’s ability to provide all services to all users
Low
* Minimal effect
* The org can still provide all critical services to all users, but has lost efficiency
Medium
* The org has lost the ability to provide a critical service to a sbuset of system users
High
* The org is no longer able to provide some critical services to any users
Economic Impact
NIST doesn’t include any assessment of the economic impact of a security incident on an org
It might be worthwhile to incorporate economic impact or measure financial impact using a separate scale
EXAMPLE:
None
* The org doesn’t expect to experience any financial impact
* Financial impact is negligible
Low
* The org expects to experience a financial impact of $10k or less
Medium
* The org experts to experience a financial impact of more than $10k but less than $500k
High
* The org expects to experience a financial impact of $500k or more
Page 359 for example and clarification
Recoverability Effort
You must measure the time that services will be unavailable
Can be expressed as a function of the amount of downtime experienced by the service or the time required to recover from the incident
NIST recommends the following:
Regular
* Time to recovery is predictable with existing resources
Supplemented
* Time to recovery is predictable with additional resources
Extended
* Time to recovery is unpredictable
* Additional resources and outside help are needed
Not Recoverable
* Recovery from the incident isn’t possible (EX: sensitive data exfiltrated and posted publicly)
* Launch investigation
Datatypes
When a security incident affects the C or I of sensitive information, analysts should assign a data impact rating
The data impact ratings from NIST are:
None
* No information was exfiltrated, changed, deleted, or otherwise compromised
Privacy Breach
* Sensitive PII of taxpayers, employees, beneficiaries, etc was accessed or exfiltrated
Proprietary Breach
* Unclassified proprietary information, like protected critical infrastructure information (PCII), was accessed or exfiltrated
Integrity Loss
* Sensitive or proprietary information was changed or deleted
Dion Datatype Breach Priority
1. Data Exfiltration
2. Insider Data Exfiltration
3. Device Theft / Loss
4. Accidental Data
5. Integrity / Availability
Private Organization Datatypes
The NIST recommendations skew towards government agencies, so you may want to augment their recommendations with the following:
None
* No information was exfiltrated, changed, deleted, or otherwise compromised
Regulated Information Breach
* Information regulated by an external compliance obligation was accessed or exfiltrated
* This may include PII that triggers a data breach notification law, PHI under HIPAA, and/or payment card information protected under PCI DSS
* For org’s subject to GDPR, it should also include SPI (sensitive personal information) which includes: genetic data, trade union memberships, sexual information, religion, etc
Intellectual Property Breach
* Sensitive intellectual property was accessed or exfiltrated
* This may include product development plans, formulas, or other sensitive trade secrets
Confidential Information Breach
* Corporate confidential information was accessed or exfiltrated
* This includes information that’s sensitive or classified as a high-value asset but doesn’t fit under the categories of regulated information or intellectual property
* EX: Corporate financial information or information about mergers and acquisitions
Integrity Loss
* Sensitive or proprietary information was changed or deleted
MITRE ATT&CK
Adversarial Tactics, Techniques, and Common Knowledge
A knowledgebase of adversary tactics and techniques, and the matrices include detailed descriptions, definitions, and examples for the complete threat lifecycle
It ranges from initial access through execution, persistence, privilege escalation, and exfiltration
At each level, it lists techniques and components, allowing threat assessment modeling to leverage common descriptions and knowledge
Good model to map out an overall adversary and all their different capabilities and capacities that they use in their attacks, and we can compare one to another
If we’re on IR, we can look at that map and recognize it’s common against a particular adversary, which helps figure out what defense you want to use
Diamond Model of Intrusion Analysis
This model describes a sequence where an adversaty deploys a capability targeted at an infrastructure against a victim (an intrusion event)
Activities are called events, and analysts label the vertices of the diamond as events that are detected or discovered
It’s intended to help analysts discover more information by highlighting the relationship between elements by following the edges between the events
The Diamond Model uses a number of specific terms:
Core Features of an Event
* These are the adversary, capability, infrastructure, and victim (the vertices of the diamond)
Meta Features
* Start and end timestamps, phase, result, direction, methodology, and resources
* These are used to order events in a sequence known as an activity thread, as well as for grouping events based on their features
Confidence Value
* Undefined by the model
* Analysts are expected to determine this based on their work
The Diamond Model focuses heavily on understanding the attacker and their motivations, and then uses the relationships between these elements to allow analyst to both understand the threat and consider what other data or information they may need to obtain, or may already have available
Cyber Kill Chain
Lockheed Martin developed this seven stage process, which is as follows:
Reconnaissance
* In this phase, adversaries are planning their attacks and will gather intel about the target, including both OSINT and direct acquisition of target data via scanning
* Defenders must gather data about recon activities and prioritize defenses based on that information
Weaponization
* Building or otherwise acquiring a weaponizer that combines malware and an exploit into a payload that can be delivered to a target
* This may require creating decoy documents, choosing the right C2 tool, etc
* The model emphasizes the fact that defenders need to conduct full malware analysis at this stage to understand not only what payload is dropped, but how the weaponized exploit was made
* Defenders should also build detections for weaponizers, look at the timeline of when malware was created vs its use, and collect both files and metadata to help them see if the tools are widely shared or closely held and thus potentially very narrowly targeted
Delivery
* Occurs when the adversary either deploys their tool directly against targets or via release that relies on staff at the target interacting with it like with an email payload, USB, or websites they visit
* Defenders in this stage must observe how the attack was delivered and what was targeted, and then will infer what the adversary was intending to accomplish
* Retention of logs is also important in this stage, as defenders need them to track what occurred
Exploitation
* Uses a software, hardware, or human vulnerability to gain access
* This can involve zero-day exploits and may use either adversary-triggered exploits or victim-triggered exploits
* Defense against this stage focuses on user awareness, secure coding, vulnerability scanning, pentesting, endpoint hardening, and anything else that ensures orgs have a strong security posture and limited attack surface
Installation
* Focuses on persistent backdoor access for attackers
* Defenders must monitor for typical artifacts of a persistent remote shell or other remote access methodologies
C2
* Access allows two-way comms and continued control of the remote system
* Defenders will seek to detect the C2 infrastructure by hardening the network, deploying detection capabilities, and conducting ongoing research to ensure they’re aware of new C2 models and tech
Actions on Objectives
* The final stage, occurs when the mission’s goal is achieved
* Adversaries will collect credentials, escalate privileges, pivot and move laterally through the environment, and gather and exfiltrate information
* They may also cause damage to systems or data
* Defenders must establish their incident resonse playbook, detect the actions of the attackers and capture data about them, respond to alerts, and assess the damage caused
If we know all the ways an attacker tries to break into our system, we can use the six Ds to fight them:
* Detect
* Deny
* Disrupt
* Degrade
* Deceive
* Destroy
* NOTE: Lockheed Martin whitepaper (bookmarked) outlines how you can map 6 Ds to the Cyber Kill Chain
The Unified Kill Chain
Combines both the Cyber Kill Chain and MITRE ATT&CK into a single kill chain model
It uses 18 phases to describe attacks that occur both inside and outside a defended network
NOTE: Not relevant to CySA+ exam but maybe useful in real-world job
Developing Testing Strategies
The two testing strategies to know for the exam:
The Open Source Security Testing Methodology Manual (OSS TMM)
* Published by the Institute for Security and Open Methodologies
* Provides guidance on testing the security of physical locations, human interactions, and comms
The Open Web Application Security Project (OWASP) Web Security Testing Guide
* Provides a resource focused specifically on testing the security of web apps
