Scott E. Donaldson1 , Stanley G. Siegel2, Chris K. Williams3 and Abdul Aslam3
(1)
Falls Church, Virginia, USA
(2)
Potomac, Maryland, USA
(3)
San Diego, California, USA
Overview
Some cyberattackers penetrate cyberdefenses no matter how well the defenses are designed, implemented, and maintained.
Enterprise endpoints and servers will be compromised.
Generally, an enterprise can accept a number of minor cyberincidents provided they are contained before significant damage is done.
Responding to these incidents (in other words, incident response) and the corresponding costs are part of modern cyberenvironments.
Enterprises need to embrace this reality and deal with compromised systems as quickly and cheaply as possible.
This chapter describes
an enterprise incident response process to deal with a detected cyberattack
; and
what type of enterprise support is needed to respond to an incident.
Topics
An Incident Response Process
Supporting the Incident Response Process
Incident Response Process
Context
High-Level Sequence of Events
Attack
Attack can be as simple as a computer getting infected with a virus.
It can also be as elaborate as a multi-phased attack.
Incident Investigation
Once attack
is detected, defenders respond with preliminary investigation to filter out false positives.
Corroborating evidence is collected to verify sensor reported attack.
Once verified, defenders formally start enterprise’s incident response process.
Containment
Once the extent
of the attack is understood, containment begins.
Objectives include removing the attacker, fixing broken cybersecurity controls, and emplacing interim security fixes that should make it more difficult for the attacker to get in again.
Remediation
After
attack is contained, defenders remediate the damage, rebuild affected systems, clean up defaced web sites, and restore normal operations.
At the conclusion of remediation, the enterprise formally closes out incident.
Post-Incident
After the initial incident is remediated, follow-on attacks by the same attacker using the same tools, techniques, and procedures should be thwarted or at least rapidly detected and defeated.
Additional controls put in place may lead to long-term permanent security enhancements or strengthened controls.
At the next level of detail, incident response can be embodied in a ten-step process.
Step 1: Identify the Incident
Step 2: Investigate the Incident
Step 3: Collect Evidence
Step 4: Report the Results
Step 5: Contain the Incident
Step 6: Repair Gaps or Malfunctions
Step 7: Remediate Compromised Accounts, Computers, and Networks
Step 8: Validate Remediation and Strengthened Security Controls
Step 9: Report the Conclusion of the Incident
Step 10: Resume Normal IT Operations
Step 1—Identify the Incident
How does an enterprise
know a security incident has occurred?
Enterprise security monitoring system generates an alert.
Users notice something wrong with enterprise IT systems.
The enterprise name shows up on the front page of the news!
Regardless, the incident response process needs to be engaged.
Incident response is a formal mechanism for declaring an incident and initiating the process.
Everyone involved in the process needs to
know that a security incident is taking place; and
understand how the process should be prioritized in relation to other responsibilities.
Generally, supporting
security incidents should be a close second priority behind maintaining normal operations and services, but ahead of system improvements, upgrades, or audits.
This situation is challenging because staff members are normally 100% engaged in supporting operations.
Who is in charge?
Notionally, with full backing of CIO, IT Security is in charge.
CIO makes tough calls allocating resources.
When a security incident is declared, IT Security goes from having an enterprise-supporting role to having a leading role.
Resolving incident will likely have operational impacts.
Step 2—Investigate the Incident
Simple investigations
involve a single computer, account, network address, or piece of malware.
Complex investigations can involve hundreds of systems and take months to complete.
Investigation team maintains four lists to track the following Indicators of Compromise (IOCs):
Computers in the internal IT environment that were compromised, including personal computers, servers, and infrastructure systems
Networks accounts on the internal network that were compromised or used by attackers, including regular user accounts, privileged systems administrator accounts, and service accounts used by applications to communicate with each other
Tools, techniques, and procedures (TTPs) used to conduct the attack, including viruses, malware, remote controller programs, and operating system tools such as secure shell and remote desktop
Internet locations used by the attackers to control systems on the inside or to receive exfiltrated data
The graphic depicts the IOC Cycle
that investigators can use to help identify the full scope of the incident.
Computers
Inspect
a computer that generated an alert from anti-virus or some type of malware activity
Network Accounts
Analyze the computer and identify user accounts that were used from that computer
Track the use of the accounts across the network
Identify non-legitimate uses of those accounts
Tools, Techniques, and Procedures (TTPs)
Analyze
the malware and identify hash signatures of the files involved or specific strings of software
Search the rest of enterprise for malware
Also look for network communications patterns that are distinct to the software involved (Such patterns are particularly useful when attackers are using operating system tools that are already built into the system.)
Internet Locations
Analyze
the computer and its network connections
Look for web connections to the Internet or evidence of protocol tunneling to Internet addresses
Each time the IOC Cycle is performed, more computers, network accounts, TTPs
, or Internet locations related to the incident may be found.
Step 3—Collect Evidence
The systems
involved in cyberincidents are often governed by laws, regulations, or industry standards that require formal reporting or other procedures.
May be necessary to formally collect evidence and maintain chains of custody for evidence
May need internal auditors, external auditors, or law enforcement authorities
Regulatory frameworks that might trigger formal evidence collection requirements in the United States include the following:
Personal Card Industry (PCI): Regulates data including credit card numbers and sometimes online banking information
Personally Identifiable Information (PII): Regulates data regarding personal identification and identity, regulated by United States privacy laws
Health Insurance Portability and Accountability Act (HIPAA): Regulates data containing personal health information
International Traffic In Arms Regulations (ITAR): Regulates technologies that are export-controlled by the United States Department of State
Sarbanes-Oxley (SOX): Regulates
financial data for public companies related to company finance and financial results reporting
Step 4—Report the Results
Investigators report
to enterprise management on what is going on and what the plan is for going forward.
If investigators engage external services to assist in the investigation, then they will likely issue a formal report outlining what malware they found and evidence they collected.
Report content should include the following information:
Timeline of what is known about the attack, including the first infection, lateral movements, and the time of discovery
Regulatory impact of affected computers and data so that enterprise management understands evidence collection and regulatory reporting requirements
Business impact of the attack, including how current business is being affected and how future business may be affected by the remediation process
Incident resolution plan to remove the attackers from the enterprise, strengthen defenses, and restore normal operations
Technical data about the attack, including computers, accounts, network addresses, and malware involved in the attacker activities
Enterprise management
needs to make decisions and provide guidance on executing the incident resolution plan.
Step 5—Contain the Incident
Containment
Is first step
in incident remediation
Blocks computers, tools, accounts, and network addresses from being used by attackers
Must be carefully thought through to avoid a “whack-a-mole” scenario where attack continues to spread at the same time the enterprise tries to contain it
Needs to avoid a situation where attackers know they have been detected and contained because, if attackers know, they can change their methods and become invisible again
Containment generally consists of the following actions:
Computers that have been compromised are disconnected from the network or malware is removed from them so it can no longer run.
Attackers’ software tools are detected and blocked from running on enterprise computers.
User and service accounts that have been compromised are disabled or their credentials changed so they can no longer be used by the attackers.
Internet locations being used
by the attackers are blocked so they can no longer be used to communicate with computers inside the network.
Step 6—Repair Gaps or Malfunctions
Once the incident is contained,
perhaps
the most important step is to identify security deficiencies that allowed the incident to occur and close those deficiencies;
the enterprise may not be able to fix every deficiency, but it needs to strengthen security enough so the original attack will not succeed if the attackers come back and try it again;
some desired security enhancements may take more time or money than is available; and
residual risks will need to be managed until the risks can be remediated.
Some key steps in repairing the enterprise security controls include the following:
Analyze attack sequence to understand how the attack occurred, what steps were involved in it, and where the enterprise can disrupt, detect, delay, and defeat future attacks.
Identify controlsthat
are in place or can be put in place quickly to catch the attack should it occur again.
Emphasize detection to ensure the enterprise can detect future attacks while they are in progress and before they can be completed or cause significant damage.
Consider training to protect against attack vectors and methods that rely on user behaviors and mistakes such as clicking on links in phishing e-mails.
Step 7—Remediate Compromised Accounts, Computers, and Networks
Once the security
controls are repaired,
the enterprise can proceed with remediating affected computers, accounts, and network components to bring them back to normal operations;
malware needs to be thoroughly eradicated; and
potential backdoors need to be cleaned up and closed off.
Some key remediation steps include the following:
Change account credentials and passwords so they are no longer available to attackers
Wipe and rebuild affected computers, where possible, while being careful not to move infection from the old system to the new one
Manually clean up systems where wiping and rebuilding is too labor-intensive or disruptive to be practical
Restore data from backups
, where necessary
Step 8—Validate Remediation and Strengthen Security Controls
Once remediation takes place,
security personnel
need to validate the remediation activities to ensure they were performed correctly;
validation is needed because often security directs IT to take remediation actions, but before actions are completed, another crisis comes up and remediation gets put on the back burner or forgotten; and
validation is needed to close out the incident.
Validation involves the following:
Checking computers to ensure affected computers are remediated (for example, rebuilding or cleaning up computers to remove malware and tools used in the attack)
Checking user accounts to ensure affected accounts are remediated (such as changing the password)
Checking network configurationto
ensure network blocks or other changes are properly documented so they can be sustained
Checking security controls to ensure a future attack of the same type will be detected and disrupted
Checking regulator requirements to ensure necessary requirements are complied with and reports filed, if necessary
Identifying future actions as part of long-term strengthening of the enterprise security posture
Conducting an after-action review to understand what went well with the incident response process, what went poorly, and how the process can be improved going forward
Step 9—Report the Conclusion of the Incident
The incident response team provides enterprise management with a final report
to close out the incident.
The report documents the major incident details and supports future incident responses and investigations.
The report helps enterprise understand attack vectors and scenarios and provides valuable input to future cyberdefense planning efforts.
The final report can follow the same basic outline as the initial report, except all known facts are included.
Key elements of the final report include the following:
Major differences from initial report, including initial “facts” that turned out to be incorrect or assumptions that turned out false
Timeline of the attack
and remediation sequence, including dates and times of
Initial attacker activity
Initial discovery of breach
Major incident response activities including beginning and completion of containment, remediation, and validation activities
Times of day, which should be referenced against an appropriate time zone to prevent confusion
Key elements of the final report include the following (continued):
Regulatory impact of the incident, as well as any changes in regulatory impact and reporting that occurred during the investigation
Technical data about the attack, including lists of computers, accounts, network addresses, and malware involved in the attack activities
After-action report describing what went well with the incident response, what went poorly, and what lessons were learned
It is OK if final report contradicts
the initial report in many places.
Frequently, initial reports contain inaccuracies due to challenges of collecting good information during a crisis.
This reality does not necessarily reflect poorly on the incident team’s efforts; it’s just a matter of fact caused by the realities and confusion of the crisis.
Step 10—Resume Normal IT Operations
Things should be back to normal
and systems should be fully operational.
Temporary risk mitigation activities (for example, manual security controls, manual audits and checks) may still be ongoing.
The enterprise needs to be cautious that such temporary measures do not become permanent.
Permanent risk mitigation activities (for example, security control enhancements, system hardening) will likely be on-going for some time after the incident is resolved.
Support the Incident Response Process
Incident response involves many supporting cybersecurity capabilities to include the following:
Detection: If an enterprise cannot detect intrusions, it will not be able to start the incident response process.
Key Detection Capabilities
Privileged activity monitoring
Network intrusion detection
Traffic analysis and data analytics
Data leakage protection
Anti-virus software
In-memory malware detection
Rogue network device detection
Event correlation
Investigation: Investigation requires solid forensic capabilities across a wide variety of systems.
Key Forensic Capabilities
Endpoint logging policies and forensic imaging support
Network packet intercept and capture
Firewall and IDS logging
Administrator audit trails
Forensics and e-discovery tools
Threat intelligence
Indicators of compromise
Network activity patterns across the entire network’s critical connectivity links
Remediation: Remediation requires the ability to move faster than the attackers and remove them from the enterprise faster than they can maneuver to avoid removal.
Key Remediation Capabilities
Multi-factor authentication for administrators
Network service management
Application whitelisting
Identity life cycle management
Rapid computer imaging
Patch management and deployment
High availability and disaster recovery capabilities
Incident response
Is not just about a single enterprise cybersecurity functional area or capability
Involves leveraging all functional areas and appropriate capabilities to mount an effective response when incidents occur
