MITRE's publication ‘11 Strategies for a World-Class SOC Centre’. Strategy #7 ‘Choose and Collect the Right Data’

Ruslan Rakhmetov, Security Vision

When analysing the actions of attackers, a holistic, strategic approach to selecting and processing data that will give the most complete and accurate picture of the cyberattack is required. Sensor data, audit logs, logs from network and host systems, applications, and monitoring points are important, regardless of their location - they make up the bulk of the data processed by the SOC. Strategy #7 focuses on how to efficiently and effectively select and process the right data in reasonable quantities from the right sources.

1. Data Collection Planning.

During the planning phase of data collection, it is important to identify the most valuable sources and data so that significant IS events are not missed. In doing so, it is important to strike a balance between collecting insufficient data, which may result in an inability to detect a cyberattack, and collecting too much data due to the resource cost to analysts and technology solutions. The value of the data processed by the SOC is at its peak when there is enough data to effectively detect cyberattacks without overburdening SOC personnel and technology. When planning data collection, it is important to understand what tasks will be accomplished by processing the selected data; not only the SOC, but also other IT/IS departments within the company may be interested in data collection. IS telemetry processing can be useful for protecting information assets, systems, networks, defending against insider threats, collecting digital evidence, monitoring information infrastructure performance, identifying system errors, finding root causes of incidents, and managing system configurations.

The data that a SOC centre needs can be obtained from a variety of sources; understanding how these sources function is key to determining which data can be used for which incident detection scenarios (use cases), and which data is the first priority. Appendix E of the publication contains a list of possible sources of IS telemetry (various protection systems, OS logs, network devices, infrastructure elements) and their characteristics: type of information transmitted, estimated number of events per day, and subjective assessment of the usefulness of data from different sources.

When selecting the sources and type of data, SOC centre members should also answer the following questions:

- How will data from specialised IS systems be able to complement information from event logs?

- What is the quality and understandability of the generated logs: are the logs suitable for human or information system analysis, what is the logical relationship of the generated events to each other, can logging policies be customised to meet the needs of the SOC?

- Availability and ability to process logs: are logs written in vendor-neutral format, can they be processed by log collection tools and in the current SIEM system, what are the costs of setting up parsing and normalisation of data from the source, can system owners provide direct access to audit logs from their systems, is there an off-the-shelf solution in the infrastructure for centralised log processing (syslog collector, message bus, centralised data storage), what will be the total volume of logs collected, can the application handle the load?

- Coverage of the logging system: will the selected data source be able to cover a significant part of the company's infrastructure, will the source be able to improve the quality of monitoring of a critical system?

When setting up monitoring and data collection, it is important to keep in mind its possible negative impact on the company's infrastructure; to minimise the negative impact, the authors of the publication provide the following recommendations:

- Minimise the number of log collection agents installed, especially on end systems;

- Carefully tune agent performance parameters such as frequency of requests, number of events transmitted in each request, and consumption of endpoint computing resources;

- Use existing collection points (e.g., syslog collectors and management servers), with the assumption that data is transmitted to these collection points without loss or delay, the SIEM has an agent for such a collection point, and data from the collection point is transmitted without delay to allow correlation with other relevant events;

- Use guaranteed delivery where possible: use TCP instead of UDP, place collection agents in logical/physical proximity to the data source to minimise latency and increase the use of encryption techniques for transmitted data, and use message bus technologies such as Apache Kafka to provide batch processing, encryption, data compression;

- Use a SIEM solution or Log Management system that can migrate data from a single agent to multiple storage locations to ensure resilience and continuity of monitoring and log collection processes;

- Try to use stable and cyber resilient IS telemetry collection systems, analyse their crash rates, resilience to attacks and to attempts to disrupt and interfere with their operation by malicious actors.

When planning for data collection, formal internal arrangements for source connectivity, data collection and monitoring services provided by the SOC centre should be established and documented. Such a document should include contact details of technical specialists and managers, a list of the data to be collected, the purpose of the data collection (specific use cases, types of cyber threats), a list of those responsible for storing and providing audit logs on request, a list of contact persons to contact in the event of a source failure, as well as measures taken to ensure the security of the data collected (personal data, sensitive information), references to relevant internal regulations and a list of systems used by the SOC centre.

It is also necessary for the SOC centre to integrate into the processes of creating new services and systems in the customer company so that the requirements for enabling logging and forwarding are met when creating or changing infrastructure elements, and it is recommended to develop and agree on internal standards for these actions, as well as to standardise the deployment, maintenance and costs of monitoring and log collection. The costs of IS telemetry collection and processing processes are directly related to the amount of data collected: different protection systems and IT/IS systems can transmit different amounts of data that can be used in preventing cyberattacks, detecting incidents, and analysing/formulating the consequences of an incident, so it is recommended to choose the most efficient and effective data sources in a particular infrastructure, which, at reasonable costs of storage and processing, can provide the greatest assistance to the SOC centre.

Fine-tuning (tuning) of data sources is done to achieve a balance between the amount of data and its usefulness in detecting cyberattacks: too coarse a tuning can either miss important events due to insufficient information received, or ‘flood’ the SOC team members with necessary and unnecessary data, which can also lead to missing an incident due to fatigue from the number of events and alerts. In the publication it is recommended to filter out the sources that provide uninformative data - this will allow to filter out the ‘information noise’ at the first stage. When working in distributed infrastructures, it is recommended to process data locally, i.e. closer to the sources at the respective sites, and to analyse it centrally, which will allow to distribute the load. In addition, not only ‘failure’ events (when an antimalware system blocks activity or IT/IS systems do not allow requested operations) but also ‘success’ events (when certain actions were allowed and performed) should be logged, as it is important in an investigation to understand not only the failed actions of the attackers but also the operations they performed.

The authors of the publication also cite three main approaches to customising data sources, which have their pros and cons:

- Enabling all possible options and collecting all possible data from all sources, followed by ‘weeding out’ uninformative events and disabling ineffective logging options;

- Enabling journaling options and processing new types of data as needed, with prior articulation of needs for monitoring certain types of events and using certain sources;

- Utilising existing data processing tools, such as Log Management middleware systems or Big Data processing platforms, allowing IS telemetry to be processed closer to the source of the data before it is fed into the SOC loop.

The publication emphasises the importance of controlling the functioning of data sources, which can continuously appear and disappear with the introduction of new systems and the shutdown of old ones, especially in large infrastructures. The authors of the publication provide the following recommendations for managing the maintenance of sensors and data sources:

- Apply configuration management techniques to control changes to data source settings (e.g., by controlling the list of sources and the individuals responsible for each source);

- Maintain communication with system administrators and engineering staff to monitor changes to the infrastructure and receive updates on new system commissioning;

- Regularly check the status of data sources - this can be done on a daily basis or when a new SOC centre shift takes over; also check the correctness of the data received, especially from critical sources, and include data source coverage and operability in the SOC metrics system;

- Use inbuilt tools to assess the health of sensors and data sources that can alert you to errors;

- Try to identify data source failures promptly and contact those responsible for the system immediately to find the cause of the failure ‘on the fly’.

In conclusion of the section on data collection planning, the authors of the publication remind about the importance of agreeing on the retention period of the collected data: the retention period may be determined by internal requirements of the customer company, legal regulations, as well as the customer company's risk profile and budget constraints. As a rule, the data retention period is set at 12 months or more, but in some cases it can be extended. In this case, it is important to ensure not only the technical possibility of information storage (i.e. use a spacious disc subsystem), but also the possibility of operational search on the collected data throughout the entire volume of information.

Next, Strategy 7 describes various information protection technologies that can provide information to the SOC Centre for monitoring and response. A detailed description of the technologies could be devoted to separate large publications, so below we will give only a brief description of the content of the sections of Strategy No.7.

2. Intrusion Detection Tools.

Intrusion detection tools can be categorised into the following types:

- Behavioural analysis-based systems (including anomaly detection and machine learning) and signature-based systems (including matching indicators of compromise);

- Network-based and host-based intrusion detection tools;

- Passive monitoring (Intrusion Detection Systems, IDS) and active intrusion prevention (Intrusion Prevention Systems, IPS).

3. Endpoint monitoring and protection tools.

Data from endpoints (servers, workstations) typically provides a more complete and holistic picture of what is happening to detect and confirm cyberattacks than network defences. Endpoints can monitor the state of file systems, RAM, CPUs, and connected devices. For advanced monitoring and protection, Endpoint Detection and Response (EDR) solutions can be used to detect malicious activity by analysing multiple factors, provide advanced IS telemetry, and enable proactive response actions. Application startup control solutions prohibit or allow processes to run based on the allow or deny list model, the management of which is resource-intensive. Classic antivirus and host-based firewalls can still be used for cyber security, but only in combination with other technologies to build an echeloned cyber defence system.

Other tools described in the publication include Data Loss Prevention (DLP) and user activity monitoring systems. At the same time, the authors of the publication point out the need to apply specific protection measures depending on the criticality of the system, privileges of users working in it, vulnerabilities and attack surface of the system.

4. Network monitoring tools.

Despite the declining popularity of network monitoring tools, including due to the prevalence of encrypted traffic, these solutions can still be used by the SOC-centre as one of the simplest and most affordable options. Important characteristics of network-based IPSs will include: false positive rates, details and context of signatures triggered, active response capabilities, throughput and impact on network infrastructure, as well as how they integrate with other technologies and cost.

5. Cloud infrastructures.

With the increasing use of cloud technologies, the SOC must take cloud-based systems, services, resources to monitor. Many of the approaches used to protect on-prem infrastructures can be applied to cloud infrastructures, but given the large distribution of cloud networks, it makes sense to focus on monitoring specific services and endpoints. One should also be prepared to deal with new types of data sources and with previously unfamiliar cloud defence technologies.

6. Zero-trust infrastructures.

In Zero Trust scenarios, you can use a combination of different monitoring products: EDR for endpoints, DLP for data, and user and resource monitoring for applications.

7. OT infrastructures.

In OT systems and networks, ensuring availability is a higher priority than ensuring confidentiality and integrity. The main challenges to protecting OT infrastructures can be proprietary specific communication protocols, diversity of vendors and models, restrictions on installation and use of devices, limited choice of specialised protection systems for OT infrastructures. Particular attention should be paid to technological junctions between IT and OT networks, as well as interaction with IoT devices.