The IR playbook/handbook

One key aspect of the IR plan is the use of playbooks. An IR playbook is a set of instructions and actions to be performed at every step in the IR process. Playbooks are created to give organizations a clear path through the process, but with a degree of flexibility in the event that the incident under investigation does not fit neatly into the box.

A good indicator of which playbooks are critical is the organization’s risk assessment. Examining the risk assessment for any threat rated critical or high will indicate which scenarios need to be addressed via an IR playbook. Most organizations would identify a number of threats—such as a network intrusion via a zero-day exploit, ransomware, or phishing—as critical, requiring preventive and detective controls. As the risk assessment has identified those as critical risks, it is best to start the playbooks with those threats.

In the absence of a risk or threat assessment, organizations should have a minimum of five playbooks that cover the most common scenarios that they will face, as outlined here:

• Phishing
• Malware
• Ransomware
• Vulnerabilities in externally facing systems
• Business email compromise (BEC)

Note

The last several years have demonstrated the devastating impact a ransomware attack can have on an organization. This book will examine several scenarios as part of the overall ransomware threat to provide a better understanding of preparation and response to this type of attack.

For example, let’s examine the breakdown of a playbook for a common threat—social engineering. For this playbook, we are going to divide it out into the IR process that was previously discussed, as follows:

• Preparation: In this section, the organization will highlight the preparation that is undertaken. In the case of phishing, this can include employee awareness to identify potential phishing emails or the use of an email appliance that scans attachments for malware.
• Detection: For phishing attacks, organizations are often alerted by aware employees or through email security controls. Organizations should also plan on receiving alerts via malware prevention or host intrusion prevention system (HIPS) controls.
• Analysis: If an event is detected, analyzing any evidence available will be critical to classifying and appropriately responding to an incident. In this case, the analysis may include examining the compromised host’s memory, examining event logs for suspicious entries, and reviewing any network traffic going to and from the host.
• Containment: If a host has been identified as compromised, it should be isolated from the network.
• Eradication: In the event that malware has been identified, it should be removed. If not, the playbook should have an alternative such as reimaging with a known good image.
• Recovery: The recovery stage includes scanning the host for potential vulnerabilities and monitoring the system for any anomalous traffic.
• Post-incident activity: The playbook should also give guidance on which actions should take place after an incident. Many of these actions will be the same across the catalog of playbooks but are important to include, ensuring that they are completed in full.

The following diagram is a sample playbook for a phishing attack. Note that each phase of the IR cycle is addressed, as well as specific actions that should be taken as part of the response. Additionally, organizations can break specific actions down, such as through log analysis for a certain playbook, for greater detail:

Figure 1.2 – Social engineering playbook

Playbooks can be configured in a number of ways—for example, a written document can be added to the IR plan for specific types of incidents. Other times, organizations can use a flow diagram utilizing software such as iStudio or Visio. They are designed to give the CSIRT and any other personnel a set of instructions to follow in an incident. This allows less time to be wasted if a course of action is planned out. Playbooks serve as a guide, and they should be updated regularly, especially if they are used in an incident, and any key pieces or steps identified. It should be noted that playbooks are not written in stone and are not a checklist. CSIRT personnel are not bound to the playbook in terms of actions and should be free to undertake additional actions if the incident requires it.

Escalation process

A critical component of the IR plan is escalation procedures. Escalation procedures outline who is responsible for moving an event or series of events from just anomalies in the information system to an incident. The CSIRT will become burned out if they are sent to investigate too many false positives. Escalation procedures ensure that the CSIRT is effectively utilized and that personnel is only contacted if their expertise is required.

The procedures start with the parties who are most likely to observe anomalies or events in the system that may be indicative of a larger incident—for example, the help desk may receive a number of calls that indicate a potential malware infection. The escalation procedures may indicate that if malware is detected and cannot be removed via malware prevention controls, personnel are to contact the CSIRT member on call. An important consideration at this step is determining which information should be contained within the escalation report. The following guidelines capture the details necessary for the CSIRT to begin addressing the issue:

• Date and time of detection: This first data point is self-explanatory. There are two main considerations though. The first is the time zone. The preferred time zone is Coordinated Universal Time (UTC). This is especially useful if all systems that are logging activity are configured to UTC. The second is the format. There can be some debate, but a good all-around method is to place the date and time together in the following formation: 20220117T1637 UTC.
• Reporting person: This serves as the initial point of contact for any additional personnel that may be called into the escalation. This individual should have visibility into the incident to answer any questions. This is often the SOC manager or another responsible party.
• Incident type: In the escalation, it is important to identify the type of incident that is being escalated. This may dictate a specific type of response. Here is a list of incident types to consider:
  • Ransomware
  • Malware infection
  • External system compromise
  • Ongoing compromise
  • Data exfiltration
  • C2
  • DoS
  • Other
• Incident severity: This is the first assessment of the incident’s severity. Having an idea of the severity of the issue will allow the IR team to align resources properly.
• The number of systems impacted: If possible, it is important to provide an order of magnitude of the incident. This should include the number of systems, operating system type, and the function of the systems—for example, an incident that is impacting only Linux servers running Apache versus Windows desktops.
• Patient Zero identified: This data is not often included in the initial escalation, as Patient Zero—or the first system identified as compromised—is often located during the analysis phase of an incident.
• Tactics identified: Any tactics that have been identified should be escalated as well. For example, lateral movement tactics using Server Message Block (SMB) or Remote Desktop Protocol (RDP) should be escalated as they indicate a larger network-wide security incident. A good rubric of tactics to use is the MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK) framework, which will be covered in a later chapter.
• Indicators of compromise (IOCs): Data points such as IP addresses, domain names, or file hashes related to the initial detection should be passed up to be included as part of the analysis.
• Actions taken: If any actions were taken, the reporting party or their colleagues should be recorded as well. For example, if the reporting group has the ability to block the execution of code and was successfully able to block further execution of malware, this has a direct impact on the type of response the IR team will execute.

There are a variety of methods that can be used to communicate this information to the CSIRT. A ticketing system can be configured to automatically notify CSIRT personnel with a ticket containing pertinent escalation details. Another option is the use of an email template that is sent to specific CSIRT personnel that handles escalations. During an incident, all actions taken by the CSIRT and other personnel from the start of the incident should be documented and tracked.

Information

For organizations that have limited resources and experience a limited number of incidents per year, most IT ticketing systems are sufficient for tracking incidents. The drawback to this method is that these systems generally lack an IR focus and do not have additional features that are designed to support IR activities. Larger organizations that have a higher frequency of incidents may be best served by implementing a purpose-designed IR tracking system. These systems allow the integration of evidence collection and incident playbooks.

CSIRT members will then take control. If they are able to contain malware to that single system and identify an infection vector, they will attempt to remove the malware and, barring that, have the system reimaged and redeployed. At that point, the incident has been successfully concluded. The CSIRT member can document the incident and close it out without having to engage any other resources.

Another example where escalation moves further up into an all-out CSIRT response can start very simply with an audit of Active Directory credentials. In this case, a server administrator with access management responsibilities is conducting a semi-annual audit of administrator credentials. During the audit, they identify three new administrator user accounts that do not tie to any known access rights. After further digging, they determine that these user accounts were created within several hours of each other and were created over a weekend. The server administrator contacts the CSIRT for investigation.

The CSIRT analyst looks at the situation and determines that a compromise may have happened. The CSIRT member directs the server administrator to check event logs for any logins using those administrator accounts. The server administrator identifies two logins: one on a database server and another on a web server in the demilitarized zone (DMZ). The CSIRT analyst then directs the network administrator assigned to the CSIRT to examine network traffic between the SQL database and the web server. Also, based on the circumstances, the CSIRT analyst escalates this to the CSIRT coordinator and informs them of the situation. The CSIRT coordinator then begins the process of engaging other CSIRT core teams and technical support members to assist.

After examining the network traffic, it is determined that an external threat actor has compromised both systems and is in the process of exfiltrating the customer database from the internal network. At this point, the CSIRT coordinator identifies this as a high-level incident and begins the process of bringing support personnel into a briefing. As this incident has involved the compromise of customer data, CSIRT support personnel—such as marketing or communications and legal—need to become involved. If more resources are required, the CSIRT coordinator will take the lead in making that decision.

Escalation procedures are created to ensure that the appropriate individuals have the proper authority and training to call upon resources when needed. The escalation procedures should also address the involvement of other personnel outside the core CSIRT members, based on the severity of the incident. One of the critical functions of escalation procedures is to clearly define which individuals have the authority to declare anomalous activity in an incident. The escalation procedures should also address the involvement of other personnel outside core CSIRT members, based on the severity of the incident.