I decided to share how the team of the Jet CSIRT Information Security Monitoring and Response Center and I ourselves formed such a scenario approach and how we use it in practice to protect our clients. Today I will tell you what we took as a basis, how we solved the difficulties and where we ended up. Looking ahead, I will note that our approach should not be taken as an absolute truth. In the case of a corporate SOC, it may be useful in some places, and redundant in some places.
Step 1. Select the requirements for the approach
First of all, we identified six main requirements that our scenario approach had to meet.
- Flexibility of logic
It was important for us to be able to quickly adjust the logic of the correlation rule, for example, add a specific profile or an exception.
- Implementation on any SIEM system
We originally created Jet CSIRT as a multi-vendor so that almost any SIEM system could be used as the main core. Therefore, most of the developments had to be unified for any monitoring system.
- Applicability for scaling infrastructure
We immediately foresaw the possibility of developing and expanding the infrastructure, in which our developments should not have “dropped out” from the established processes.
- Clear presentation
We also needed to be able to provide customers with information on detected threats in a simple, understandable way, without code or complications.
- Ability to cover different sets of different systems and protections
Our clients’ infrastructures are built using different systems, security tools, software and their configurations. Therefore, we wanted the scenario approach to cover these systems as much as possible, based on their type or class.
- Possibility to select scenarios according to specified criteria
Finally, we paid great attention to the ease of choosing scenarios according to given criteria: the type of controlled system, the type of controlled activity, etc.
Step 2. Finding the basis
To develop an approach, we turned to best practices:
- Cyber Kill Chain;
- MITER ATT & CK;
- MITER Cyber Analytics Repository;
- FBI Insider Threats;
- Various materials and tools for analytics, detection and testing of threats
- github.com/Neo23x0/sigma (by the way, we not only use the correlation rules from this database, but also actively develop it by participating in the OSCD community)
After analyzing these materials, we have identified some basis for a future approach.
- To ensure the possibility of combining activities according to certain criteria, we decided to focus on the APT Kill chain and Insider Kill chain.
- To understand what is being detected and by what methods, we used the categories, techniques and tactics of MITER ATT & CK.
- We took into account the developments in the logic of correlation rules, including those that have already been created in Jet CSIRT.
As a result, we have defined two basic units for detecting threats: the scenario and its condition.
Scenario is a general description of the conditions for malicious, unwanted, or controlled activity and combines the conditions by the type of activity and the set of specified markers: Kill chain stages, ID of techniques, the name of tactics MITER and others.
Below is an example of highlighting similar MITER techniques and further highlighting sources of information to combine a set of rules.
Example of combining rules into a set
Script condition, in turn, specifies this activity in relation to a specific action on a controlled source.
All scenarios are combined according to several unified criteria into nine categories:
- illegitimate administrative activity;
- compromising an account;
- compromise of the node;
- violation of security policies;
- malware infection;
- malicious network activity;
- unauthorized access to systems;
- data leak;
- denial of service attack.
Step 3. Working with scripts
Now about the scripts themselves. To manage and store the script cards, we chose the GitLab code repository management system, since in it you can work on different scripts at the same time, organize a single place for storing actual scripts and easily create copies (forks). We divided all scenario cards into four blocks.
Scenario card content
Basic description contains information that can be used to uniquely identify the scenario and at the same time search by criteria. This block uses the attribute format. An example of one of these descriptions for a scenario looks like this:
Sections with logical framework and correlation rules include an easy-to-read description of the identified threat, known false positives, and the rules themselves for various SIEM systems.
Example of a section with a logical structure
Example of rules for SIEM
Response instructions contain short guides on areas of investigation, notification templates and basic response actions.
When creating the main base of scripts, we asked ourselves how to organize work with scripts for a specific infrastructure, because each client has its own set of systems. This is where the GitLab fork comes in handy. The main script base serves as a start for a separate customer repository.
This capability will also come in handy for enterprise SOCs with distributed infrastructure. Infrastructure can vary by office or department, resulting in unique scenarios, conditions, and exceptions.
In the diagram below, you can see how our scripts are migrated to the repository of each client.
Migration by client
Step 4. Development of scenarios
When we came to a common methodology for scenarios, the question of how to develop them further arose, because the attackers are constantly improving techniques and tactics, which requires us to regularly create new scenarios and adjust existing ones. Here we have identified four main “sources” of scenario development.
- Our own research based on public and private reports on targeted attacks and information on new malware.
- Own experience in providing monitoring and response services, participating in incident investigation, attack response and post-incident activity.
- New techniques and tactics from MITER ATT & CK, which is constantly growing and developing.
- Targeted requests from clients, in which a particular problem needs to be solved by means of the monitoring system.
We divided the entire direct development process of scenarios into stages – from creation, testing and verification on the Jet CSIRT infrastructure to direct implementation to our clients.
According to the results
As a result, we managed to solve a number of problems and get new advantages when working in this format.
- We have systematized and structured all knowledge, as well as combined atomic threat detection techniques into groups to make it easier for us to navigate the threat detection capabilities.
- New team members can easily learn what works in a Jet CSIRT and how. With the advent of the technique, we were able to maximize the range of threat detection.
- We have made it easy to present the detected threats for information security specialists who are not familiar with SIEM systems.
- We managed to eliminate the problem with the loss of developments, when any files with information could be destroyed, lost, or stored by their creators.
- We have unified incident handling: we have written complete playbooks for all available scenarios with the necessary actions and measures.
- We now have the opportunity to quickly and without any difficulties use any of the implemented rules without access to a specific SIEM system. We have implemented version control and changes in the logic and added exceptions for the script.
I hope our experience will be useful for you and will help you understand the nuances of forming a scenario approach to identifying threats to your own SOC.
Author: Dmitry Lifanov, Lead Analyst of the Center for Monitoring and Incident Response of Information Security Jet CSIRT, Jet Infosystems