MITRE publication ‘11 Strategies for a World-Class SOC Centre’. Strategy #11 ‘Increase Efficiency by Expanding SOC Functionality’

Ruslan Rakhmetov, Security Vision

Attackers are continuously improving their TTPs, hiding their presence and developing new tools, and to effectively monitor and respond to cyber incidents, SOC centres must continuously improve. Basic cyber-attack detection, response, cyber threat analytics functions may be insufficient in some cases, so a SOC centre may decide to extend its functionality to meet the current cyber threats and customer needs. Such extended functionality may include proactive threat hunting, Red/Purple Team testing, use of cyber-attack emulation platforms (BAS systems) and Deception solutions (‘traps’), use of forensics, and staff cyber training.

1. Threat Hunting.

Proactive cyber threat hunting is one of the main value-added functions of a SOC that can begin to be developed when maturity in incident response processes and Cyber Threat Intelligence is achieved. Cyber Threat Intelligence focuses on finding new or previously undetected attackers that are already covertly present in the infrastructure. In other words, cyber threat hunting is the proactive search for malicious or suspicious activities in networks, systems, and data that have not been identified by existing standard IS tools and techniques. When searching for cyber threats, analysts are guided by the principle of Assumed Breach, which means literally, ‘Consider yourself already hacked.’ This involves creating and testing certain hypotheses about the actions of attackers who may have previously stealthily penetrated the infrastructure based on the analysts' experience and known cybercriminal TTPs, including the use of forensics. Cyber threat analysts will need to work with the IS data processed by the SOC centre, monitor the performance of the protection systems and the IS incidents being handled, work with cyber threat analytics, and understand the context and business processes of the customer and know what constitutes a deviation from normal infrastructure operations and normal business operations.

To effectively implement the cyber threat intelligence function, the SOC centre must have a certain level of maturity: it must handle cyber incidents correctly and promptly, receive complete and accurate data from network and host devices, and ‘see’ the entire infrastructure. The reasons why a SOC centre may decide to start searching for cyber threats may be insufficient existing means and methods of detecting attacks, cyber intelligence data about cybercriminals' interest in the customer company, or the need to expand current response procedures with additional analytics. The feasibility of investing in cyber threat detection can be assessed in terms of the cost of possibly rebuilding the entire company's infrastructure from scratch if attackers are deeply entrenched in it and were not detected at earlier stages. At the same time, it is important to realise that cyber threat hunting should not be an endless wander through IS data in the hope of discovering something important: there should be specific objectives, a hypothesis, and an execution plan that includes preparation, execution, and completion of the cyber threat hunting operation. In addition, a cyber threat search can only complement, but not replace, a conventional cyber incident response.

1.1 Preparing for a cyber threat search:

Preparation should include the development of a document - the cyber threat search programme - that specifies expected outcomes, resourcing, rules of engagement, authority and agreement from SOC centre managers. It should also define when it is acceptable to observe attackers in the infrastructure without performing active response actions.

In preparation for cyber threat search operations, you should:

- Develop a cyber threat search hypothesis based on ideas and feedback from SOC team members, using the MITRE ATT&CK matrix and making assumptions about the targets, TTPs, and possible actions of attackers;

- Plan and prioritise activities based on the likelihood of cyber threats and SOC objectives;

- Identify available resources, including personnel, systems, tools, and consider possible partner involvement.

1.2 Perform cyber threat operations:

Each cyber threat search operation should be structured roughly as follows:

- Plan for the operation, including the hypothesis developed, objectives, boundaries, timing of the operation, and the IS data sources required for the operation;

- Gain access to the data and collect the necessary information;

- Analyse the collected information through several iterations, recording the results in a structured format suitable for collaboration;

- Plan and conduct periodic data analysis to ensure continuous search for cyber threats using available SOC centre tools (e.g. SIEM, SOAR, Big Data processing platform);

- Perform a response to an identified cyber threat or escalate the case to the response team;

- Regularly communicate the results of operations to the SOC centre managers and synchronise actions among themselves (within the cyber threat intelligence team).

The authors of the publication provide several recommendations for successful cyber threat hunting operations:

- Focus on a specific hypothesis;

- Be curious and inquisitive and pay attention to the little things;

- Invest in people, allocate resources and time to cyber threat hunting;

- Try to approach each new cyber threat hunting operation with a clean slate, not relying solely on previous experience;

- Build a trusting relationship with the customer's employees to gain insights from them and know what is uncharacteristic in the behaviour of systems and business processes;

- Develop hypotheses and scenarios for likely attacks based on previous incidents, cyber intelligence, TTPs from the MITRE ATT&CK matrix, SOC centre alerts and trends, information from external sources (blogs, social media), and based on assumptions about the potential interest of attackers in certain company assets and data.

1.3 Completion of cyber threat search operations (Post-Hunt Activities):

At the conclusion of a cyber threat hunting operation, whether or not attackers have been found, the results of the operation and findings should be communicated to stakeholders (other analysts, SOC centre managers, IS department staff, interested stakeholders). The identified IS deficiencies should be reported and ways to improve cyber defences, including overall cyber hygiene, vulnerability management processes, and SOC cyber incident response (including reconfiguration of IS data sources, correlation rules, response scenarios) should be proposed.

2. Red Team Testing

Another way to proactively test and improve protection measures in SOC is to conduct Red Team testing, which is the execution of actions typical for attackers, using appropriate TTPs, which are used in real cyber attacks, to verify the correctness and effectiveness of response of SOC personnel, processes, technologies. The difference between Red Team testing and penetration testing is that penetration tests are conducted with respect to a particular technology using a specific template, while Red Team testing is usually more comprehensive and resource-intensive, as it may involve working out several attack scenarios and different vectors (including social engineering and penetration into the customer's territory). In addition, SOC-centres are often not notified about Red Team testing to maintain the ‘purity of the experiment’, and the testing itself involves simulating the actions of attackers (including TTPs of APT-groups) and the real cyberattack to verify detection, analysis and response to it.

The benefits of Red Team testing are as follows:

- Improved quality of defence and monitoring as a result of testing, and the resulting increased cost for real attackers to overcome improved defences;

- Improved accuracy and reduced time to threat detection as a result of analysing false positives and false negatives identified as a result of testing;

- Identification of weaknesses in detecting possible privilege escalation and lateral movement of attackers and resulting improved defences;

- Identification and demonstration of cyber security weaknesses.

When conducting Red Team testing, you can either engage SOC centre experts or use the services of a third-party company. Both options have their advantages: members of the SOC-centre team will be able to take a fresh look at the protected infrastructure and protection systems, which they will try to bypass by emulating the actions of an advanced attacker, while employees of a third-party company will have no knowledge of the infrastructure and will be able to take an unconventional path when conducting a test cyberattack.

In both options, it will be important to consider the following:

- Planning: allocating resources and time to Red Team testing, taking into account Red Team and SOC centre capabilities, and assessing the risk of real damage to the company's infrastructure as a result of testing;

- Conflict Resolution: determining how to attribute the event to the current incident or to Red Team's actions;

- Escalation: determining how and when a Red Team incident can be escalated to managers for management and resource allocation;

- Resource allocation: allocating sufficient resources to the Red Team and to the SOC centre and determining the balance between the two.

To improve the effectiveness of Red Team testing, the authors of the publication provide the following tips:

- Identify a trusted person who will be aware of Red Team testing: this could be the SOC centre manager or IT director who can stop testing if damage is done to the company or redirect SOC centre resources to respond to a real incident if necessary;

- Choose realistic cyberattack test scenarios, taking into account the customer company's business processes and infrastructure, as well as previous real cyberattacks;

- When developing Red Team testing functionality, start with simple scenarios and gradually move to more complex ones;

- Define in advance the boundaries and success criteria of testing, do not allow blurring the boundaries of the testing project, try to formulate the criteria of testing success so that to demonstrate the result it is not necessary to perform destructive actions and cause real damage;

- After Red Team testing, you should eliminate its consequences (roll back changes, remove artefacts and software installed by the Red Team, etc.);

- Allocate time to analyse the lessons learned from testing, draw conclusions, and improve protection measures.

3. Purple Team testing

When testing the security of the customer company, the Red Team acts as ‘attackers’, performing actions typical of the attackers' TTPs, and the Blue Team “defends”, seeking to detect and prevent the Red Team's attack. In the case of Red Team and Blue Team members working together, this testing is called Purple Team testing, in which both offence and defence activities are conducted simultaneously, and as a result of this collaboration, both defenders and attackers learn and improve their skills together.

The goal of Purple Team testing is to improve the customer company's defences against attackers, including improving cyber threat detection, response, and prevention by processing feedback on the effectiveness of response scenarios and defence configurations. This should be guided by an approach that ensures Purple Team testing, constant communication, and feedback processing is ongoing. Unlike Red Team, Purple Team testing involves continuous interaction between members of the attack and defence teams (Red and Blue Teams), whereby the Blue Team knows exactly what, where and how the Red Team is performing. At the same time, the authors of the publication recommend that only one or more sets of attacker TTPs be tested during each test to better assess the correctness of the defence measures and fine-tune them.

Purple Teams can work as follows:

- Red Team testing of a single system or some segment of the infrastructure under the supervision of Blue Team members to evaluate the effectiveness of defence measures (tools, sensors, analytics);

- Blue Team members interactively observe every action performed by Red Team members;

- Open vulnerability assessment and emulation of attackers' actions, where Red Team stops at each step of testing and Blue Team analyses the actions performed;

- Testing commercially exploited systems with emulation of the actions of a specific cybercriminal group;

- Using cyber attack emulation platforms for Red Team and Blue Team to work together.

4. Cyberattack Emulation Platforms

Pen tests, Purple Team and Red Team tests, vulnerability assessments are resource intensive, and many attacker TTPs are difficult to accurately replicate. For regular automated assessments of a company's security, you can use BAS (Breach and Attack Simulation) solutions that provide a repeatable, measurable, scalable process for testing the correctness of security measures. BAS testing is performed on specific hosts, networks, and systems of a company, and BAS platforms must support testing of different attacker TTPs in accordance with the MITRE ATT&CK matrix. The reasons for implementing cyberattack emulation platforms may be the lack or insufficient resource support of the Red Team, the need to automate regular testing of attackers' actions, the need to assess the coverage of the MITRE ATT&CK matrix by the current forces and means of the SOC-centre, the need to assess the effectiveness of the implementation of protection measures outside the SOC (e.g., by the IS department).

Cyberattack emulation platforms may have the following characteristics:

- Coverage of attacker TTPs in the BAS system, e.g., based on the coverage of the MITRE ATT&CK matrix;

- Relevance, testing functionality, frequency of updates: the TTPs embedded in the BAS solution should be regularly updated, relevant to the types of assets and systems used in the company, and the BAS platforms themselves should have the functionality to test different types of systems (databases, web servers, applications, cloud services, etc.);

- Pre-defined testing scenarios: BAS solutions should allow combining different attack vectors and TTPs for more comprehensive testing, as well as allow emulating the actions of specific relevant APT groups;

- Transparency and extensibility: BAS solutions should provide full information about the actions performed and the TTPs used in emulating attacks, and these TTPs should be customisable and tailored to the needs of the SOC (e.g., emulate only individual attacker actions or the entire attack chain);

- Risk mitigation: there should be logging of actions performed by the BAS platform, ‘rollback’ of all changes made to the infrastructure as part of the attack (e.g., restoring system settings, accounts to their original state), the ability to stop BAS testing immediately, and robust protection of the BAS platform itself.

The authors of the publication provide the following recommendations for successful implementation of a BAS solution:

- Shared use of the BAS platform by the SOC centre, Red / Blue Teams, pen-testers;

- Gradual deployment: The BAS solution should be deployed with a small number of non-critical assets in a test environment to verify the reliability and security of the solution;

- Ensuring test security: rules for conducting and terminating BAS tests, as well as procedures for handling abnormal situations, should be developed and approved;

- Ensuring that test attacks are relevant to the customer's infrastructure and cyber threats: realistic test scenarios suitable for the customer should be selected that validate the defences actually used;

- Select test devices to validate detection and prevention tools on them: BAS solutions can help SOC Centre, Red Team, Purple Team to configure defences to respond to test attacks conducted using BAS;

- Evaluate the applicability of the results to the entire infrastructure: having conducted BAS testing on a limited set of devices, reasonable conclusions should be drawn as to whether the results are representative of all devices in the customer's infrastructure;

- Continue to use vulnerability scanners: BAS solutions cannot replace vulnerability scanners because scanners test a much larger number of vulnerabilities and configurations than BAS platforms;

- Coordinate with legal counsel on the use of BAS tools for compliance: you should know if the chosen BAS solution can be used for internal audits and testing to prove compliance with legislation;

- BAS platforms do not replace Red Team members: some checks can only be performed manually, and BAS solutions only automate certain activities without replacing staff expertise.

5. Deception solutions (‘traps’)

Deception solutions (‘traps’) are used to hide the real infrastructure of a company, to confuse attackers and to lead them astray. In addition, Deception platforms can be used to proactively search for cyber threats by luring attackers into a controlled environment and allowing them to ‘steal’ fake data (bait), the movement of which can then be tracked: for example, by allowing attackers to ‘steal’ specially created test credentials, attempts to apply or publish them can then be tracked and conclusions drawn. In this way, Deception platforms can complement other attack detection methods (signature-based and anomaly detection) and provide SOCs with valuable information to identify hidden malicious activity. Deception solutions allow automated ‘scattering’ of decoys across a company's infrastructure, analysing the actions performed by attackers, and controlling their movement between decoys. Unlike classic Honeypot/Honeynet technologies, Deception systems allow you to automate the creation and control of decoys, misdirect attackers, provide proactive search and analysis of cyber threats.

Decoys can present themselves as:

- Fake accounts, documents, file ‘balloons’ hosted on a specific device;

- Fake systems, services, servers, which at first glance are indistinguishable from the real ones, but are equipped with sandbox technologies to control and analyse the actions of attackers;

- Fake Active Directory objects that could be of interest to attackers;

- Perimeter decoys that resemble real web services to distract attackers by misdirecting them.

The authors of the publication stress that implementing a Deception solution can only be justified for mature SOCs that are aware of the risks and complexities associated with such systems: from the need to configure Deception infrastructure to the possibility of attackers taking over the Deception infrastructure and using it as a springboard for further attacks on the company. Before implementing the Deception platform, it is necessary to make sure that the SOC centre is mature and ready to use the Deception solution wisely, allocate appropriate resources, develop rules for dealing with detected attacks (for example, the procedure for making decisions on further monitoring of attackers' actions or blocking their actions), and coordinate the implementation and use of the platform with the legal block and company managers.

To successfully implement and operate the Deception platform, you should:

- Clearly define the end goals of the solution application, e.g. by using the MITRE Engage framework;

- Select a suitable Deception solution: the authors of the publication recommend using commercial products to simplify the creation of Deception infrastructure and ‘decoys’, especially if the SOC centre is new to Deception;

- Try to replicate near-real elements of the infrastructure within the Deception project: ‘decoys’ and Deception objects should change over time and make it appear as if users are working with them as if they were real;

- Provide control and monitoring of the Deception infrastructure created to prevent attackers from ‘escaping’ from the controlled environment.

6. VPO Analysis

In their work, SOCs regularly encounter suspicious files that need to be analysed to understand possible malicious activities and consequences. As the SOC centre matures, the functionality of on-premises and cloud-based antivirus becomes insufficient, so there is a need to develop an internal VPO analysis function.

The objectives of VPO analysis can be:

- Examination of VPO samples to understand the attack vector and likely targets, which may lead analysts to already known VPO families or cybercriminal groups;

- Investigating the functionality of the VPO and its behaviour, including methods of entrenchment and stealth, and how it communicates with the attackers' command and control centre (Command and Control server, abbreviated as C&C or C2 server);

- Enriching VPO information with current incident data and building a knowledge base of cyber threats, malicious campaigns, and cyber groups to further improve response and proactively search for cyber threats.

The SOC Centre's VPO analysis increases the likelihood of identifying and countering attackers because the results of the analysis are specific to the customer company. In addition, a SOC centre with good VPO analysis competencies can be invaluable to the IS community and provide better cyber incident investigation services.

An in-depth analysis of the VPO in-house will help the SOC centre understand the following:

- Whether the VPO was specifically created for a targeted attack against the client company, or whether it was a widespread virus used against different targets;

- Whether and how the VPO interacts with the attackers' C2 server;

- What access credentials (passwords, certificates, keys) are ‘hardwired’ into the VPO, where they are used;

- Whether the VPO was written from scratch or whether the code base of an already known VPO that has been previously encountered and analysed elsewhere was used;

- What exactly the VPO does: does the VPO download additional modules, does it record user keystrokes, what actions does it perform on the infected device;

- What are the motives of the attackers - authors of the VPO, what are their resources and capabilities.

To successfully implement the internal function of the SOC-centre to analyse VPOs, the authors of the publication recommend the following:

- Assess the SOC centre's need for internal VPO analysis, assess how often the SOC encounters unknown and complex VPO samples;

- Estimate the level of return on investment in an internal VPO analysis function that is resource intensive for the SOC centre;

- Establish interaction between virus analysts and members of the incident response team, cyber threat and Threat Hunting analysts in the SOC centre, as well as with other SOC centres and the IS community;

- Support initiatives for analysts to publish articles on the results of the VPO research - this will not only help to enhance the SOC centre's reputation with the community and customers, but also help to retain staff and attract new talent;

- Establish a dedicated infrastructure for VPO analysis, secure it, and give virus analysts the freedom to choose the tools and methods of analysis;

- Document the authority, general procedures and rules for VPO analysis in the SOC centre.

7. Forensics

The use of forensics (computer forensics) in a SOC centre may be required to conduct cyber incident investigations as well as to prosecute perpetrators under the law. In the event of a serious incident, the legal department should be involved to determine whether legally relevant evidence needs to be collected using strictly defined methods and tools. Forensics can be performed on RAM, hard drive (operating system and file analysis), network traffic, mobile devices, cloud storage, and data of various formats.

Success factors in establishing an in-house computer forensics function in a SOC centre, according to the authors of the publication, are:

- Assess the purpose of conducting forensics: whether the forensics will only be used to support cyber incident investigations within the SOC centre or whether options are being considered to use the data collected in court;

- Obtain the necessary authority to conduct the forensic analysis, and document the processes for conducting the forensic analysis;

- Be aware that the data being analysed may contain illegal or injurious content, so minimise the potential negative impact of the information obtained on the analyst;

- Keep in mind that forensics is a niche section of IS forensics, so avoid forming a point of failure in the form of a single forensics analyst in the SOC centre;

- Prepare for a dramatic increase in the load on the forensics function in case of a major incident: appoint a person responsible for prioritising and controlling forensics analysis, set reasonable boundaries for the end of forensics analysis, establish interaction with third-party partners (MSS provider, other SOC-centre, integrator) so that they can be engaged quickly.

8. Conduct staff cyber exercises

When time and human resources are limited, tabletop exercises can be used to test cyber incident response preparedness by walking the responsible IS team members through documents (policies, scenarios, response procedures) step-by-step and verifying their understanding and readiness to execute them. Staff cyber drills do not include a full technical analysis of the test incident, but rather a speculative assessment of team members' readiness to perform their actions (e.g., finding responsible contacts, using tools and defences).

Conducting a staff cyber exercise will be useful in achieving the following objectives:

- Understanding by all response participants of their actions, alerting participants to potential incidents and requirements for interaction with the IS team;

- Increasing and updating the knowledge of responders on their roles and responsibilities;

- Identifying gaps in response processes and resourcing (people, information, tools);

- Identify possible difficulties that participants may have in responding to real incidents.

To conduct a successful HQ cyber exercise, realistic scenarios for test cyber attacks should be developed, an exercise plan should be prepared in advance, all personnel involved in the response should be invited, and the cyber exercise should be fun and as close to a live response as possible. HQ cyber exercises are useful because they allow everyone involved in the response process, even those who are not deeply immersed in IS (e.g., lawyers, PR, executives), to test their knowledge and improve their readiness to respond to a real cyberattack.

In addition, the authors provide the following recommendations for a successful staff cyber exercise:

- Select the person responsible for organising the HQ cyber exercise (selection of scenarios, invitees, location and timing, logistics);

- Choose the person responsible for organising the staff cyber exercise (liaising with all participants, running scenarios, moderation);

- Give the participants of the HQ cyber exercise new introductions as the exercise progresses to make the scenario more dynamic;

- Define the scope and boundaries of the staff cyber exercise depending on the audience that will attend, and monitor the activities performed by the participants;

- Minutes should be kept and identified gaps and issues should be documented;

- Select a time frame for the cyber HQ exercise, keep to the chosen pace, but allow flexibility in the timetable if necessary.