Good afternoon, Khabrovsk!
1. Instead of joining
A recently published translation of
Mental Information Security Models interested me not only in the general message (in particular, the use of models in training is an acute question for me, because learning is a continuous process), but also with a list of links to models. Why is he so important? We will understand in the course of the article.
Some of the models listed in the text have to be encountered as part of the work process (monitoring and response can be connected with MITER ATT & CK and Kill Chain). I had a general idea of others, but how to apply them, or what key features make it possible to increase the efficiency of this process, remained behind the scenes. Honestly, I heard the names of some models for the first time.
Armed with links and free time, I began to study the topic. I believe that this material may be useful as a sightseeing tour or a short summary on the topic. Looking ahead, I will say that the description of some models disappointed me. But first things first.
First of all, a few words about yourself. My name is Alexander Nosarev, and I work in the IB integrator. My focus is on monitoring and response systems. According to the duty of the service, the main areas of activity are the organization and automation of log collection and analysis processes in the context of information security, as well as the response processes to violations and incidents identified by the analysis.
Work only on direct job duties is, of course, good. But you won’t go so far — albeit to a lesser extent, but I have to deal with the results of the entire life cycle of building IS in the enterprise, which affect the final result more than my own work.
But back to our models. I set myself the task of developing a unified approach that would allow us to determine the key features of the objects under study and answer the following questions: when can and should one or another model be applied, on what postulates is it based, what results can be achieved, etc.
To do this, it was decided to start with a theoretical part, built both on the original publication, and on our own research and experience. May she be with us in the article.
2. General theory
General theory What is a model? This is a system, the study of which serves as a means to obtain information about another system; Presentation of some real process, device or concept.
However, this definition is formulated generally. We specify the area of research: IS models in monitoring and response activities.
I will list the main goals of the application of models in the named field of activity:
- Systematization and coordination of actions in the analysis of data, in the investigation, prevention and elimination of the consequences and causes of incidents. On the one hand, this is necessary for solving tasks of the operational or tactical levels (transferring work on an incident from one specialist to another, building the most efficient processes, etc.). And on the other hand, for such strategic tasks as prioritizing the implementation and connection of specific SIS to the monitoring system, creating content for monitoring and response systems, conducting cyber orders, etc.
- Description of systems (information security, IT, organizational, etc.) for the creation, storage, transmission of information, modernization, audit, etc. Moreover, the value of the model as an instrument for describing the system is important. This includes everything from a controlled network model to a malicious event model in that network.
- Training - transfer of knowledge about the system and methods for solving problems using its models. Training in practice is, in my opinion, the most effective method. But sooner or later, the question arises of systematizing the knowledge gained both for the individual and for the organization. This primarily helps to find hidden connections and identify further areas of development or pain points.
- The solution to other problems is the application of methods to a system model.
Are all models equally useful for achieving these goals? Of course not. However, that which passed the test of time and was not forgotten in the annals of history deserves attention. What criteria do such models satisfy first of all?
- Simplicity. The complexity of the problem solved using the model should be higher than the complexity of the model. Otherwise, the meaning of its use is lost. Therefore, it is advisable to apply the model to a relatively independent part of the system for which the problem is being solved, and if necessary, combine these representations. A striking example is the division of a network model into levels L2, L3, etc.
- Utility. Namely, the aggregate of the width of the region of applicability of the model and the details of its development. The wider the scope, the more likely it is that a well-known model is suitable for solving a new problem. The deeper the details, the simpler the model to use. That is, everything can already be described for you, including the process of adding additional details, entities and their relationships, if necessary. Often these requirements contradict each other, therefore, a balance is important, which can be called the level of abstraction of the model. The higher the level of abstraction, the wider the range of applicability of the model.
Before applying the model, you must remember the following properties:
- Limitedness. Any model reflects only those characteristics that are necessary to solve the task assigned to it with a certain accuracy. Therefore, it is important to know the limits of applicability of the model and methods of working with it. This property characterizes the sufficiency of the model for solving the problem.
- Iterativeness Any model reflects only those characteristics of the simulated system that are known to the creator of the model. When new, previously unknown characteristics appear, the model must be revised (which does not necessarily imply a change). This feature suggests the need to revise the model to solve the problem.
Mechanics can serve as a classic example of the materiality of these properties: once there was only classical mechanics, but now there are both quantum and relativistic ones.
The theory differs from practice, therefore, a number of features arise when using models in activities:
- The choice of model comes from the options we know. That is why I was so interested in the list from the translated article.
- The application of the model generates perception errors due to both general cognitive distortions and personal experience. So, in particular, those models that seemed uninteresting to me can help you. And after the investigation of the incident, a specialist with the background of the network administrator should pay attention to whether he missed any host artifacts. And it’s better to consult with colleagues in general.
- Models can be layered. That is, the task is divided into subtasks (or vice versa, subtasks can be synthesized into one global), for the solution of which models are used, possibly different from the models for solving the parent task. At the same time, models can be both complementary and competing. It is important to remember the features of each model and be able to link them to each other so that the perfect solution to one problem does not lead to degradation of adjacent ones.
The contribution to the application of a specific model (except for the task itself) is made by:
- Threat Model
- Asset categorization.
- Risk assessment.
These useful documents not only allow you to introduce some restrictions and assumptions that can simplify the model, but also generally talk about the applicability of a particular model. However, you should not forget that the criminals of your OSA do not use it, and the incident may not fit into it during the investigation.
Based on the above theoretical part and the found description of the models (from the picture-scheme for some to dozens of pages for others), it was decided to use the following main characteristics of the models in this abstract article:
- Level of abstraction.
- Application area.
- The main provisions and principles.
- Basic entities and methods.
- Relationship with other models (if available).
- Solved tasks.
- Examples (if necessary).
3. Models
The list of models is taken from the original article. Added to it is the CVSS3 model, to demonstrate a low-level abstraction model with widespread use in information security.
If you read the entire article laziness, then here is a small navigator on the models indicating the main scope of their application. I will cite it in a conclusion for readers in order.
Model Navigator Universal models:
- Investigation process - a technique for finding answers to questions during investigation and training; can be applied to more general studies.
Models for working with information security incidents:
- Diamond - search and documentation of incidents, conversion of investigation results into TI.
- MITER ATT & CK - incident search, behavioral analytics.
- The intent of the proof is forensic.
- PICERL - incident response.
Models for building an information security system:
- Defense in Depth - separation of the defense system relative to the SPI.
- Cyber Kill Chain - separation of the defense system regarding the stages of the attack.
- Pyramid of Pain - work with IOC.
- MITER ATT & CK - creating content for the monitoring system and its evaluation.
- The intent of the evidence is the introduction of special monitoring tools.
- PICERL - incident response preparation.
- CVSS3 - building a vulnerability management system.
3.1. Investigation Process Model
Abstraction Level: High.
Scope: Any research process.
Key points and principles:
- Visible is not reality. We possess only limited information and complete empty spaces of the puzzle with assumptions or skip them altogether.
- Knowledge is formed by questions.
- In the process of perception, we introduce distortions (cognitive and from personal experience).
The main entities:
- Observation - evidence of a means of information security (SZI) or the assumption of an analyst, confirmed by something.
- Question. Must be checked, usually refers to implicit relationships between objects.
- Hypothesis. It consists of an assumption and the reasons for its assumption.
- The answer is the collected evidence confirming or refuting (which is preferable, since this speeds up the research process) hypothesis. May raise other questions.
- A conclusion that allows you to describe the event that occurred.
Tasks to be solved:
- Search for facts of compromise.
- SOC analyst training.
All models with a high level of abstraction seem simple. But, firstly, not all felt-tip pens taste the same (yellow bitter more). And secondly, most of these models managed to find some details that increase the efficiency of their application. In particular, for this model it is:
- The approach to "observation". It is not necessary to initiate an investigation or selection of SZI, starting from logs or a window demanding a ransom from the encryptor on the victim's PC. But you should always be able to explain why you initiated the process. Information security trends, in your opinion, have led to an increase in certain risks. It is convenient for attackers to attack your asset based on the weaknesses of its protection known to you. Protests in Tibet can lead to massive attacks by your users from Tibet from China. Anything.
- The composition of the hypothesis. Without verbalizing the reason explaining the hypothesis, you will not have formal criteria for testing the hypothesis.
- Formalization of the conclusion. The result description scheme should be fixed. Otherwise, the generalization of such results and the adoption of strategic decisions based on it may become impossible. Or you just miss something as a result of your research.
3.2. Model "Diamond"
Abstraction Level: High.
Scope: Any research process in the framework of work with information security incidents.
Key points and principles:
- For each compromising event, there is an attacker who performs an action to solve his task. It takes advantage of the opportunities provided by the infrastructure. These opportunities are directed against the victim and serve to achieve the goal of the attacker.
- There are attackers who are looking for ways to compromise hosts and networks in order to advance in their intentions and satisfy their needs.
- Any system, and therefore any target asset, has vulnerabilities and weaknesses.
- Each malicious activity consists of phases, the successful implementation of which leads to the success of the activity as a whole.
- Each invasion event requires one or more conditions in order to be successful.
- There is always a relationship between the attacker and the victim, even if they are implicit or indirect.
- There are cybercriminals with motivation, resources, and the ability to maintain a malicious presence over an extended period of time. This malicious activity can occur in one or more victims and includes overcoming countermeasures.
The main entities:
- An attacker is a performer and a customer, personifying TTP and the ultimate target of the attack, respectively.
- Infrastructure used by an attacker.
- Opportunities. Characterized by quality and quantity.
- Victim. Assets and a person with “susceptibility” to the actions of attackers.
The diamond model has been known to me since college, but it is usually painted in the form of a single diamond, and I did not happen to dig deeper. Therefore, the question always arose in my head: how will it solve my problem? There was no answer to it. After reading the description, I found the following interesting details.
Entity Relationships:
- Event - the action of an attacker at a specific stage using specific techniques. It is characterized by a set of metapoles. It is the event that is displayed in the form of a diamond.
- Activity flow - events, united on the basis of meta-fields.
- Activity group - a group of activity streams based on meta-fields.
All elements of these entities are assigned a confidence rating.
Thus, the diamond model combined with phasing of the invasion process, for example, according to the Kill Chain model, provides an excellent framework for describing the attack process. The chaining takes place according to the following principle: what appeared to be a victim or an opportunity in one event can become an infrastructure in the following. Events can also relate to one phase and go sequentially or in parallel. Moreover, for the emergence of a connection, events do not have to relate to one activity stream. These can be dependent flows, for example, hacking through a contractor. Additional meta-fields allow you to describe the details of the attack.
In addition, the authors propose describing entities and their relationships with vectors (elements have a numerical or fixed verbal meaning). This makes it possible to cluster incidents to find answers to a question. For example, the establishment of a group of attackers, an attempt to predict the next or missing action during the investigation, the choice of SZI to close the most popular capabilities of attackers, etc. On this aspect, significant emphasis is placed on the description.
The model is extensible, especially in terms of meta-fields. For example, the authors propose such an option.
Additional entities:
- Socio-political aspect (motive).
- The technological aspect.
This approach also involves the use of non-technical countermeasures. These methods are implemented by influencing the motive and motivation of the attackers. An example given in the description of the model: one of the real hacker attacks was stopped after calls by competent comrades to the mothers of the performers. As they say, in war all means are good.
Tasks to be solved:
- Systematization and coordination of actions during data analysis, investigation, prevention and elimination of the causes of incidents.
- Mathematical miscalculation of analytical issues of investigation, prevention and elimination of the causes of incidents based on graphs.
- The use of not only technical countermeasures. For example, the exclusion of attack vectors by non-technical means, the limitation of the circulation circuits of protected information, etc.
In describing the incident, we can move from the view from the defender to the view from the side of the attacker. Then we get a graph of possible attack options, from which we can build on the construction of the information security system.
3.3. Model MITER ATT & CK
Abstraction Level: Medium.
Application area:
- Information security of computer networks (for Application Security, Database Security, etc. in a neighboring project of the same organization MITER CAPEC ).
- Sensors on end devices should be deployed in the organization, providing continuous monitoring (not snapshots). The matrix has been updated several times, so the data is not entirely relevant. But an approximate idea of what can be detected without sensors is displayed by the green blocks of one of the previous iterations of the model (spoiler: none).
Systems for which a matrix exists:
- Enterprise: Windows, Linux, MacOS.
- Mobile: Android, iOS.
Key points:
- The model is built from the point of view of the attacker. Therefore, we can go from the question “what happened?” To “what can happen?”. Those. from reactive to proactive actions.
- The model is based on real incidents (open reports). All attack vectors for which the moon is needed in the fifth phase of Mercury are excluded. Those. We work according to the Pareto principle, which gives a quick result. But this is also a minus, because more than one month can elapse between the beginning of the active use of techniques and their appearance in the matrix.
- The level of abstraction is sufficient to correlate attacking actions with defense actions. In fact, this is not so, but various projects based on the model, such as RedCanary and Atomic Threat Coverage, make it possible to level this disadvantage. Also, in the course of preparing the publication, this interesting article was published .
- The short-term goals of the attackers are determined by a set of tactics and answer the question “why?”.
- Tools for achieving short-term goals are determined by a set of techniques and answer the question “how?”.
- Each group corresponds to a set of tactics and techniques.
.
Basic principles:
- Tracking activity after a compromise. The concept of the perimeter and associated SZI is gradually transforming. But it has long been clear that tracking the only fact of compromise on the perimeter is a dead end.
- Focus on the behavior of the attacker, and not on single flags that signal violations. This adds work to analysts, because testing of not all hypotheses can or should be automated. Automation bears fruit only when the cost of it is less than the completion of the same tasks automatically. But the number of both false positive and false negative responses reduces significantly.
- Provides part of the threat model. Allows you to act proactively by adding controls and content to the monitoring system.
- Iterativeness You can evaluate what is already being monitored, what is easy to start monitoring, what requires additional controls or analysts, and what will be the next level of information security development in the organization.
- Development and testing were carried out in a realistic environment. Therefore, our theoretical matrix boat has a chance not to break into the real IT infrastructure of the company.
The main entities:
- Tactics.
- Technics.
- Malicious group.
- Malicious software.
Tasks to be solved:
- Emulation of the actions of an attacker to confirm the ability to prevent, detect and eliminate the consequences.
- Planning Red Team activity.
- Behavioral analytics of the actions of attackers.
- Assessment of weak points of protection.
- Assessment of SOC maturity levels (based on matrix coverage).
- TI data enrichment. Perhaps because the matrix is essentially built on TI reports.
- Situational awareness. Similar to the previous paragraph.
- Analytics of anomalies. Rather, a pleasant bonus arising from the experience of using the matrix.
- Forensics.
Target Identified Entities:
- Time window of the incident.
- Compromised / involved hosts.
- Compromised accounts.
- Attackers
- Used tactics and techniques.
Splitting into tactics captures part of the Kill Chain, but each stage includes from one to several tactics.
3.4. Deep Defense Model
Abstraction Level: High.
Scope: Building an information security system.
Key points and principles:
- Lack of a single point of compromise.
- Redundancy and overlapping attack vectors.
Tasks to be solved: Construction of echeloned (with respect to methods and means) protection to increase the time and cost of attack, as well as protection against specific weaknesses of protective measures.
The model itself illustrates well and can be successfully applied even with a new approach to the IS perimeter in an organization.
3.5. Pyramid of pain model
Abstraction Level: High.
Scope: Any research process within the framework of work with IOC.
Key points and principles: Detection and prevention of the use of IOC can weaken an attacker, the degree of this effect depends on the type of IOC.
Main entities: IOC types.
Tasks to be solved: Detection of IOC for investigation, prevention and elimination of the causes of incidents.
Since this model fits most into TI, I’ll leave a
link here to one of the latest interesting articles on the topic. It discusses the life cycle of indicators and other interesting points. In addition, the model shows why there is so great interest in TTP descriptions, for example, the aforementioned MITER ATT & CK.
3.6. Model "Cyber Kill Chain"
Abstraction Level: High.
Scope: Work with information security incidents.
Key points and principles:
- To achieve the ultimate goal, the attacker solves several mandatory tasks.
- Prevention, detection or elimination of the causes, process and consequences of completing a task significantly affects the achievement of an ultimate goal by an attacker.
Main entities: Stages reflecting the tasks of the attacker: reconnaissance, weapons, delivery, operation, installation, management, actions within the network.
Tasks to be solved: Building a layered (relative to the stages) information protection system.
A good example of a scalable model. Many analogues have been generated with more or less detail depending on the tasks being solved.
This is also a good example of overlapping models. It goes well with the MITER ATT & CK or the Diamond.
3.7. The Intention of Evidence Model
Abstraction Level: High.
Scope: Work with information security incidents.
Key points and principles:
- There is evidence of malicious activity provided by software developers intentionally and unintentionally.
- The level of trust, the method of collection, etc.
Main entities and methods: Type of evidence (intentional, unintentional).
Tasks to be solved: Prioritize the collection of evidence and assess their reliability.
Examples:
- Software and OS logs are intentional proof.
- The query cache is an unintended evidence.
- Network traffic is proof by design, i.e. the existence of an object is proved by the very fact of its existence.
I would call this concept a “model” with a big stretch. It allows a section to be drawn between forensics, which may involve unintentional evidence, and monitoring, often without such means. Or having, but pointwise. Except for this, I could not stand the benefit of it.
3.8. PICERL Incident Response Process Model
Abstraction Level: Medium.
Scope: Response to information security incidents.
Key points and principles: Responding to IS incidents includes several stages.
Key entities: IS incident response stages: preparation, detection, containment, eradication, restoration, analysis of results.
Tasks to be solved: Building a life cycle for responding to IS incidents.
In principle, this is a good analogue of the Kill Chain model, but only in relation to response. Taking into account the indicated actions for each of the stages, it can serve as a good help for creating play books. The main thing is not to forget to impose first the organizational structure and the powers of the people involved, and then - the features of the IT infrastructure.
3.9. Model CVSS3
Abstraction Level: Low.
Scope: Prioritization of vulnerabilities.
Key Points and Principles: A vulnerability assessment can be calculated using the following metrics:
- Basic metrics.
- Time metrics (change over time).
- Context metrics (depending on the IT infrastructure of the organization).
Basic entities (in brackets the possible values accepted by the metric are indicated):
Basic metrics:
Vulnerable component , characterized by operational metrics:
- Attack vector AV (NALP), the degree of distance of a potential attacker from a vulnerable object.
- Difficulty in exploiting the AC (LH) vulnerability, a qualitative assessment of the complexity of an attack.
- Authentication / Required PR Privilege Level (HLN).
- The need for user interaction UI (NR).
- Operating limits S (UC), whether the exploited and the attacked components differ.
Attacked component (characterized by impact metrics):
- Assessment of the degree of influence on the confidentiality, integrity and availability of the attacked component C, I, A (NMH).
Time metrics:
- E (ND/XHF POC/PU).
- RL (ND/XUW TF/T OF/O).
- RC (XURC).
:
- CR, IR, AR (ND/XHML).
- MAV, MAC, MPR, MUI, MS, MC, MI, MA, I- .
Tasks to be solved: Prioritization of vulnerabilities (assessment + vector) and vulnerability chains.
A more detailed description of the model is set out, including here . The article includes examples of the transition to evaluation from CVSS2 to CVSS3, which illustrates well the iteration principle for models. Also during the preparation of the publication, CVSS3.1 was released.
Although many metrics are peer-reviewed, the standard provides some of this expertise. Therefore, the final assessment does not depend so much on the organization that conducts it.
3.10 Other models
Outside the discussion, models such as:
- CIA
- Dread
- STRIDE
- Joint Intelligence Preparation of the Operational Environment (JIOPE)
- ADAM
- Attack trees
- The Analysis of Competing Hypotheses (ACH)
4. Instead of a conclusion.
A systematic approach to security, based on the use of models of varying degrees of formalization, as well as various domestic and foreign standards, allows us to avoid quite a few mistakes. It helps not only not to forget the conditions and factors necessary for the successful construction of the system (be it the ISIS as a whole or the investigation of a specific incident). But it also allows you to discard unnecessary parameters, which only complicate the picture.
It is important to remember that models, as well as standards, are not the ultimate truth. Not only because they must be subject to periodic review in order to maximally unambiguously display a real object as part of the task being solved. But also because, on the whole, they should be selected on the basis of the task, limitations and assumptions accepted by you, which, of course, change over time. The decision to use a particular model is also subject to the requirements of external processes that supply information for your tasks or accept data that is the result of your work. In my opinion, this article can contribute to the goal of choosing the most suitable model. Next - the business is yours.
To summarize, I’ll duplicate a small navigator by model indicating the main area of their application.
Universal models:
- Investigation process - a technique for finding answers to questions during investigation and training; can be applied to more general studies.
Models for working with information security incidents:
- Diamond - search and document incidents, convert investigation results to TI
- MITER ATT & CK - incident search, behavioral analytics.
- The intent of the proof is forensic.
- PICERL - incident response.
Models for building an information security system:
- Defense in Depth - separation of the defense system relative to the SPI.
- Cyber Kill Chain - separation of the defense system regarding the stages of the attack.
- Pyramid of Pain - work with IOC.
- MITER ATT & CK - creating content for the monitoring system and its evaluation.
- The intent of the evidence is the introduction of special monitoring tools.
- PICERL - incident response preparation.
- CVSS3 - building a vulnerability management system.
It is worth remembering that these models can be applied for other purposes. In addition, they can specify requirements for adjacent areas. For example, determine the composition and format of the data that will be used in them at the input or output of related processes.