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
