MITRE publication ‘11 World-Class SOC Centre Strategies’. Strategy #5: Prioritise response to cyber incidents

Ruslan Rakhmetov, Security Vision

Responding to cyber incidents is a key function of any SOC, and IS incident handling is often understood not only as response (tactical and operational technical activities), but also as cyber incident management (strategic activities, including planning, coordination, collaboration, reporting); the authors of this publication suggest using the terms ‘response’ and ‘management’ interchangeably.

1. Selection of frameworks and methodologies.

The authors recommend the following frameworks to guide the preparation of a cyberincident response plan:

- NIST Special Publication SP 800-61, Computer Security Incident Handling Guide;

- NIST Special Publication SP 800-184 ‘Guide for Cybersecurity Event Recovery’;

- ENISA (EU Cybersecurity Agency) ‘Reference Incident Classification Taxonomy’;

- Open Source MISP platform's classification of cyber incident types;

- The OODA (‘Observe, Orient, Decide, Act’ i.e., ‘Observe, Orient, Decide, Act’) concept.

In general, the approach to cyber incident management that the authors of the MITRE publication focus on is the cycle of ‘Prepare, Plan - Identify, Analyse - Contain, Eliminate, Recover - Post Incident Actions’. The description of the recommendations in Strategy #5 follows this cycle.

2. Planning.

Proper planning will help ensure an effective, efficient, relevant, and comprehensive response when a cyber incident occurs, with responses appropriate to the level of criticality of the situation.

To prepare for most incidents, the SOC centre will need:

- Staff with strong technical, analytical, communication skills;

- Documentation: SOPs (standard operating procedures), the SOC centre's CONOPS (Concept of Operations) (i.e. a description of how the SOC centre operates, the authority and responsibility of SOC personnel, a description of the SOC centre's role model, functions, capabilities, requirements), and a description of escalation procedures;

- Means of coordinating the analysis and response activities of the SOC team members;

- A list of responsible persons with whom incident response coordination is required and their contact details;

- Tools to collect and analyse artefacts to identify facts relating to cyber incidents;

- Authority to perform rapid and decisive actions, as well as incident downgrade, de-escalation, and passive monitoring as necessary.

The response plan may include documents such as:

- A description of the roles and responsible members of the response team, with areas of responsibility, including outsourcer contacts;

- Contacts, methods of communication, list of focal points to understand who, when and how to be notified, including internal and external contacts, as well as legal department representatives and law enforcement officials;

- Background documentation, manuals, descriptions of procedures performed such as SOPs, reporting guidelines, applicable policies;

- A description of the tools, technologies, and physical resources used by the SOC, describing how to access them;

- A list of critical network and data recovery processes, including detailed recovery instructions;

- A reference to the SOC Charter and other documents that assign the SOC specific authorities used in the response.

Before prioritising incident types, a comprehensive list of expected and simulated cyber attacks should first be compiled, including both the most frequent and known types and those that are rare but dangerous. In the domestic context, the list of incident types can be compiled on the basis of an updated threat model, and can also be guided by methodological recommendations, in particular, from the FSTEC BDU. In addition, the authors of the publication recommend using data from the MITRE ATT&CK matrix when creating the list of incidents, indicating the priority for each type of cyber incident/unwanted (unacceptable) IS event, as well as a brief description of response methods. Of course, this list will be unique for each organisation and infrastructure, as will the priority and response method.

Response methods and steps for relevant incident types are detailed in incident handling manuals - playbooks or response scenarios - which are required to streamline the response and make it repeatable and templatable for SOC team members. This is also important for new employees, who will find it easier to get up to speed, and for experienced employees, who will not have to ‘reinvent the wheel’ every time they respond, but can pay attention to new features and details of the incident. Properly written descriptions of the sequence of response activities (response scenarios) are also a key success factor in automating response activities.

The authors of the publication recommend developing playbooks for all types of incidents that are handled in the SOC at least once a month. The playbook should generally include the name of the scenario, the problem to be solved and the scope of applicability, the conditions under which the scenario is activated, the response procedures and steps to be followed, and the metadata of the document itself (version number, author, revision history). Response scenarios should not only correspond to the Customer's business processes and information infrastructure, but also maintain a balance between detailed description of actions and providing SOC employees with the necessary creative freedom in response. In this case, it is important to include a check-list in the scenario, which will be convenient to check both a novice and an experienced expert of the SOC-centre in order not to forget to perform all the mandatory actions during the response.

The developed scripts should be regularly updated with the results of post-incident actions to ensure continuity of the response improvement process, and the current versions of the playbooks should be stored in a single knowledge base for quick and easy search and sharing.

3. Identification and Analysis.

The processes for identifying and analysing cyber incidents can be divided into three groups: incident research (i.e., triage, which includes receiving, sorting, categorising, prioritising incidents), incident analysis (analysing events and incidents for investigative purposes), and investigation (finding out the sources and causes of incidents, reporting).

3.1 Incident Triage.

Reports of possible incidents can arrive at the SOC in a variety of ways: by email, by phone, in the form of requests to IT, from counterparties, and from the monitoring tools of the SOC itself. When incoming information is received, it is often unclear whether an alert or message is an indication of an incident or not, so triage procedures are performed to verify the incoming message and determine the type of incident.

The grouping and categorisation of incidents is performed differently in each SOC due to differences in business processes and infrastructure, but the authors of the publication provide the following examples and recommendations for correct triage of incidents:

- Incidents can be categorised based on attack vectors and impact on company assets, but confusion can arise when different tactics and categorisation techniques are used in an attack.

- You can categorise incidents based on the applicable response (for example, responding to a cyberattack on a web application will be different from responding to a VPO infection or DDoS attack).

- Incident categories can be selected based on the organisational units that will be involved in the response (e.g. email administrators for a phishing attack and web application administrators for a website attack).

- Incident category types should be defined before the incident occurs to simplify planning, and new types can always be added at a later date.

- Incident triage guidelines should be developed for timeliness and to avoid queuing of incoming incidents that are slow to be processed by SOC staff.

3.2 Incident Analysis.

When reviewing a new incident, it is important to use information from a variety of sources to form a more complete, holistic picture of what happened. The authors of the publication provide the following recommendations for analysing incidents:

- Test assumptions and hypotheses based on facts, not speculation.

- Look for evidence and data that adds to the picture of what happened, even if it is outside the SOC's ‘field of view’.

- Analyse indicators of compromise (hashes, IP/URL addresses, traffic dumps, etc.) to get a complete picture of the TTPs used by the attackers.

- Create a timeline of relevant events to understand the attackers' actions and the stages of the attack.

- Use a comparison of known and unknown software components, for example, by using a list of ‘known good’ hashes of system files or trusted publisher certificates to compare against suspicious file data.

- Do not rely on compromise indicators alone, as attackers can easily change hashes, IP/URL addresses, etc., hence it is recommended to build TTPs models of attackers and use attack indicators for a more accurate analysis of attackers' behaviour and their ultimate goals.

- Analysing attack scenarios and hypotheses on the basis of already available facts helps to make assumptions about further actions of attackers and search for additional information about the attack.

- Avoid the biases and preconceptions that analysts may form based on experience, where it seems that all incidents of the same type are somewhat similar; the authors of the document recommend treating each incident as completely new, as each cyberattack will be unique in some way, which will require adjusting the response accordingly.

3.3 Investigation.

When responding, the use of forensics (computer forensics) boils down to identifying suspicious or malicious activity that may be related to the incident in question. Data from antimalware, network equipment, and endpoint devices can be used to obtain information about activity, based on vendor recommendations and publications on the forensics of relevant asset classes and operating systems. The authors of the document believe that the most valuable and consistent incident data can be obtained from endpoints and information systems (including EDR solutions), from which IS events should be transferred to secure storage to prevent unauthorised modification by attackers. Identifying the ‘patient zero’ from which the horizontal movement of attackers in the infrastructure began will help identify the attacked assets in the network, the direction of the attackers' movement and their targets, and take appropriate action.

The authors of the publication recommend analysing the following artefacts:

- File system and files, with a search for unknown directories, files, objects;

- Running processes, with analyses of unknown processes and searching for anomalies in the behaviour of known processes;

- Scripts, executable files;

- System file hashes that do not match ‘known good’ hashes, and file digital signature data that does not match known trusted publishers;

- System audit logs, looking for activity of unknown accounts, privilege changes, instances of new trusted hosts being created, and significant file changes;

- Network activity, including VPN connections, remote connections, tunnel creation, use of RDP and SSH, which can be used to create an unauthorised data and command channel by attackers.

When analysing and investigating incidents, SOC team members often encounter a large number of false positives that outnumber the true positives (‘combat’) in most cyberattack detection systems, so it is important to continually fine-tune (tuning) the protection systems, enrich the context of events, and use automation tools. Often, SOCs also use a ‘non-threat’ or ‘benign positive’ response category, in which the detection tool correctly detected a true-positive event that, upon verification, turned out to be non-malicious; this can occur when detecting sanctioned pen-test activity or objectively suspicious user or device behaviour that, upon verification, turned out to be legitimate activity.

The authors of the publication also provide SOC team members with their recommendations on how to effectively and efficiently analyse anomalies and indirect indicators of sophisticated cyberattacks:

- Stay calm: when signs or consequences of a cyberattack are detected, users may exaggerate the scale of the problem; the SOC's job in this case is to calmly, objectively and expertly understand the situation before responding.

- Establish liaison with law enforcement and internal legal services in advance: in the event of an incident requiring legal action, liaising with subject matter experts will be very helpful.

- When responding, communicate with users, owners of systems and services, and system administrators: employees can tell you what oddities or anomalies they have noticed in information systems.

- Provide for the possibility of calling on expertise outside the SOC: in the event of a large-scale incident, or if there are complexities in the analysis (e.g. the need for reverse engineering), the SOC may not have sufficient resources to carry out the tasks, so it may be useful to agree in advance to liaise with third parties, such as another SOC or integrator/vendor.

- Contextualise information: when analysing an incident, understand what the activity means in the context of the operation of the business process, service, information system, what events preceded the incident, whether the recorded events are characteristic or anomalous, where the events occurred, what sources can provide even more context.

- Avoid jumping to conclusions and making assumptions: when handling an incident, you should first examine the content of events, networking data, and artefacts before making a judgement on the nature of the incident, as incorrect assumptions can waste time and resources, as well as reputation.

- Distinguish facts from assumptions: techniques for analysing and testing evidence, correlations and causation should be implemented in advance.

- Do not over-emphasise attribution, but try to associate attackers with the incident: while it is useful to compare the current incident to previous incidents and to groups of attackers, hasty incorrect hypotheses about connections can lead to inappropriate responses, and it is not necessary to conduct a thorough attribution of the attack to correctly respond to known activity.

4. Containment, Elimination, Recovery.

When performing response actions, mistakes may be made and ineffective countermeasures may be implemented, which themselves may result in damage to the company (e.g., stopping critical services) or inappropriate expenditure of significant resources.

The authors of the publication provide a number of recommendations for conducting correct containment, remediation, recovery:

- Ensure coordinated movement toward a common goal within the SOC: in the midst of responding to a critical cyber incident, SOC members may overstep their authority and take countermeasures that will harm the company (e.g., requiring a critical server or business service to be shut down); to avoid such mistakes, build communication within the SOC, work with employees and company executives, and ensure a clear chain of command within the SOC.

- Build a management structure: you should develop a chain of command in advance, define the boundaries of areas of responsibility, build interaction within the SOC team, and assign a person responsible for each cyber incident.

- Don't fall victim to the ‘fog of cyber warfare’: when responding (especially to complex, multi-vector cyber attacks), make sure that accurate and complete details of the cyber incident are collected, because without this, it is impossible to fully address the consequences of the attack and prevent its recurrence.

- Prepare to answer ‘So what?’ questions: when communicating information about a cyber incident to top management and owners, it is important not to get into technical terms, but to explain the situation from a business perspective, the achievement of company goals, and financial costs; be prepared to answer questions about what was attacked, whether the attack was successful, who is behind it and what their motivation is, and how to continue business processes.

- Report when you are ready: although there will be many who will want prompt and frequent situation reports when an incident occurs and responds, the timeframe and recipients of incident reports should be determined in advance; when responding to a major incident, the authors of the publication recommend holding two separate meetings every one to two days: the first meeting can be attended by those directly involved in the response, while the second can be attended by managers to whom higher-level information will be reported

Before implementing active response, containment, and remediation activities, the SOC team should first ensure that they have all the necessary information. Determine whether the planned countermeasures and response activities will affect legitimate critical business processes by contacting the appropriate people in the company and checking with them for details. The full scope of the attack and affected assets should also be determined, as a hasty response could result in an incorrect estimate of the number of affected assets, an unaddressed presence of attackers in the infrastructure, and possibly an attempt by attackers to better conceal their actions in order to become more invisible.

In addition, certain cases may require the use of legal counsel and the gathering of legally relevant evidence when evidence of cybercrime is identified - balancing the completeness of evidence gathering, understanding the attackers' objectives, and avoiding critical damage from an ongoing cyberattack. The authors of the publication stress that it is important to respond not only to eliminate the threat and remove the attackers from the infrastructure, but also to consider the negative consequences of active response actions (‘reloading’ servers will render services unavailable and may result in the loss of forensic artefacts, shutting down processes may have only a temporary effect, and changing credentials may have no effect if the attackers have access to different accounts or if the access token remains valid

As part of the response, it is also important to use a centralised system for SOC team members to work together, monitor their actions and track progress in responding to cyber incidents; recording and monitoring incidents in disparate systems or spreadsheets can only lead to confusion and disorganisation. At a minimum, a unified cyber incident tracking system should include information such as general incident information and details, a timeline of the incident and actions being taken, the name and contact details of the person responsible, response actions taken and in progress, and the current status of the cyber incident. When responding, it is important for team members to adhere to the developed scenarios and SOPs, and once the incident is closed, the knowledge base should be updated based on the ‘lessons learnt’ of each cyber attack and the appropriate response.

5. Post-incident actions.

Regular updating of the centralised knowledge base and solutions based on the results of the analysis of ‘lessons learned’ from cyber incidents that have occurred and the response actions performed, and the subsequent modification of appropriate response procedures and scenarios, directly affects the SOC's ability to perform its assigned tasks.

The post-incident review of a closed incident, according to the authors of the publication, should include a discussion of the following questions:

- What measures and actions helped in the response?

- What measures and actions did not help the response?

- What slowed the response?

- Was there confusion? When and where, how can it be avoided in the future?

- Did the responders have access to the necessary information?

- Were missing but required tools identified, were tools unavailable, were available tools useless?

- What tools or data were insufficient for a successful response?

- Who should have been involved in the incident response (but was not)?

- What skills were needed and which were actually used?

- Did alerting and reporting work well?

The information gathered should feed into the ‘input’ phase of planning to improve the effectiveness of the SOC, adjust investment strategies, and hire workers with the right expertise. The deficiencies in the customer company's IS management system identified as a result of the response should also be regularly and systematically communicated to the responsible persons to improve cyber security and prevent similar incidents in the future. When creating and assigning a list of identified deficiencies in the customer company's IS management system to a responsible person, it is necessary to provide references to the relevant incidents that revealed these deficiencies - this will help to work on improving the state of IS in the company in a more structured way and prevent the systematic repetition of the same cyber security mistakes, as well as give the SOC centre team members an opportunity to see the results of their own efforts to improve security.