Map elements to these steps of analysis based on the NIST.SP800-61 r2

Implementing Cisco Cybersecurity Operations (210-255)

NIST.SP800-61 r2 defines an Incident Response Life Cycle as shown above. For the SECOPS test, it is necessary to know some of the common elements of the steps in the Incident Response Life Cycle.

Preparation

• Gather Useful Information for Incident Response
  • Contact Information for internal teams, law enforcement, and incident response teams.
  • On-Call Information
  • Incident Reporting Mechanisms
  • Issue Tracking system
• Ensure forensic analysis tools are available
• Documentation of the network and hosts
• Baseline information
• Prevention
  • Risk Assessment
  • Malware Prevention
  • User Awareness Training

Detection and Analysis

The detection and analysis phase is where SOC analysts try to detect attacks or precursors to attacks.

Attack Vectors

There are several attack vectors to be familiar with.

• External/Removable Media
• Attrition (DDoS, Brute Force)
• Web (XSS, SQL Injection)
• Email
• Impersonation (Spoofing, Man in the Middle)
• Improper Usage (Violation of AUP)
• Loss or Theft of Equipment
• Other

Signs of an Incident

Precursors

• Web server log entries showing vulnerability scans
• Announcement of a new exploit of a known vulnerability
• Threats against the organization

Indicators

• NIDS alerts
• AV Alerts
• Sysadmin finds files with unusual characters
• Alerts to configuration changes
• Multiple failed login attempts from remote systems
• Deviation from normal baseline network traffic flows.

Incident Documentation

• Current status of the incident
• Summary of incident
• Indicators
• Actions that have been taken
• Chain of custody
• Impact assessments
• Contact information for parties involved
• Evidence gathered
• Next steps

Incident Prioritization

Incidents are not handled first in first out. They should be treated in a priority queue based on relevant factors such as those below:

• Functional Impact
  • None – No effect on the organization’s services
  • Low – Minimal effect, lost efficiency
  • Medium – Lost the ability to provide critical services to a subset of users.
  • High – No longer able to provide critical services to all users.
• Informational Impact
  • None – No information was compromised
  • Privacy Breach – Sensitive PII was accessed or exfiltrated.
  • Proprietary Breach – Protected critical infrastructure information was accessed or exfiltrated
  • Integrity Loss – Sensitive or proprietary information was changed or deleted
• Recoverability
  • Regular – Time to recovery is predictable with existing resources
  • Supplemented – Time to recovery is predictable but needs additional resources
  • Extended – Time to recovery is unpredictable and needs additional resources.
  • Not Recoverable – Recovery is not possible

Incident Notification

Notification requirements vary by organization and industry. Some common people to notify include the CIO, CISO, HR, Public Affairs and Legal. Some organizations will also need to inform US-CERT and law enforcement.

Containment, Eradication, and Recovery

Containment Strategy

Containment strategies vary based on the incident and the organization. Some criterion to use for containment strategy include:

• Damage potential or theft potential
• Evidence preservation
• Service availability
• Time and resources needed
• Effectiveness of the strategy (partial vs full containment)
• Duration of the solution

Evidence Gathering and Handling

Detailed logs on the evidence collected should be maintained. This should include identifying information, who handled the evidence, when it was handled and where it was stored. Chain of custody forms should be maintained individually with each piece of evidence.

Identifying the Attacking Hosts

• Validating the Attacker’s IP Address
• Researching the Attacker through Search Engines
• Using Incident Databases
• Monitor Potential C2

Eradication and Recovery

A phased approach is generally taken to eradicate and then recover from a security incident. During eradication, malware and other software are removed. Recovery entails rebuilding systems from backups and returning them to service.

Post-Incident Activity

After the incident is resolved, the team will review what lessons were learned from the incident. Discussions of lessons learned will also produce incident data to be used in future process improvement. The final part of the post-incident activity is determining the retention and disposition of evidence.