Writing a Threat Model

Hello everyone, we continue our series of articles on “paper security”. Today we’ll talk about developing a threat model. If the purpose of reading this article is to gain practical skills, then it is better to immediately download our document templates , which also contain a threat model template. But even without a template at hand, the article can also be found for educational purposes.

Why do we need a threat model?

The need to develop a threat model is regulated by a number of regulatory documents. Here is some of them.

Part 2 of Article 19 of the Law No. 152-FZ “On Personal Data”:

2. The security of personal data is achieved, in particular:

1) by identifying threats to the security of personal data when they are processed in personal data information systems;

Composition and content of organizational and technical measures to ensure the security of personal data during their processing in personal data information systems (approved by order of the FSTEC of Russia dated February 18, 2013 No. 21):

4. Measures to ensure the security of personal data are implemented, inter alia, through the use of information protection tools in the information system that have passed the conformity assessment procedure in the prescribed manner, in cases where the use of such tools is necessary to neutralize current threats to the security of personal data.

Requirements for the protection of information not constituting state secrets contained in state information systems (approved by the FSTEC of Russia dated February 11, 2013 No. 17)

Formation of requirements for information protection ... including includes:
...
identification of information security threats , the implementation of which may lead to a violation of information security in the information system, and the development on their basis of a model of information security threats;
...

Requirements for information protection in automated control systems for production and technological processes at critical facilities, potentially hazardous facilities, as well as facilities that pose an increased danger to human life and health and the environment (approved by order of the FSTEC of Russia dated March 14, 2014 No. 31):

Formation of requirements for information protection in an automated control system ... including includes:
...
identification of information security threats, the implementation of which may lead to a violation of the normal mode of operation of the automated management system, and the development of a model of information security threats on their basis ;

Requirements for ensuring the security of significant objects of critical information infrastructure of the Russian Federation (approved by order of the FSTEC of Russia dated December 25, 2017 No. 239):

11. The development of organizational and technical measures to ensure the security of a significant object is carried out by the subject of critical information infrastructure ... and should include:

a) analysis of information security threats and development of a model of information security threats or its refinement (if any);

So, the conclusion from this is simple: for any information systems that are somehow to be protected in accordance with the law, it is necessary to develop a threat model.

Threat Model Content

We have figured out the need to create a document, let’s see what the legislation prescribes for its content. Here, oddly enough, everything is rather scarce.

As a textbook example of describing the content of a threat model, we can cite 17 orders of the FSTEC:

The model of information security threats should contain a description of the information system and its structural and functional characteristics, as well as a description of information security threats, including a description of the capabilities of violators (model of the violator), possible vulnerabilities of the information system, ways to implement information security threats and the consequences of violation of information security properties.

You won’t believe it, but that’s all. But on the other hand, although there is not much text, it is quite informative. Let's re-read and write down what should be in our threat model:

• description of the information system;
• structural and functional characteristics;
• Description of security threats
• intruder model;
• possible vulnerabilities;
• ways to implement threats;
• consequences of violation of information security properties.

This is under the law, which requires FSTEC. There are also additional requirements of the FSB (about them a bit later) and some unofficial requirements-wishes from the FSTEC, which we encountered in the process of coordinating threat models of state information systems.

Introductory part of the threat model

Well, let's get down to the contents of the document.

I think about the title page, a list of abbreviations, terms and definitions, everything is clear. Although, perhaps, it is worthwhile to elaborate on ... suddenly the title page.

In the template it is signed by the head of the owner of the information system. It is not just that.

Decree of the Government of the Russian Federation of May 11, 2017 No. 555:

4. The terms of reference for the creation of the system and the model of information security threats are approved by the official of the executive authority, which is vested with the relevant authority.

Naturally, if the information system is not state-owned and the system operator is not an executive authority, then anyone can sign a threat model. It’s just that we have repeatedly faced when, subject to the above conditions (state information system of the executive authority), the customer asked us to change the title page so that only the representatives of the licensed company (that is, ours) signed there. I had to explain why the FSTEC would return such a model of threats for revision.

Section "Normative and methodological support"

Here I would like to recall that the threat model can be developed for very different systems - from ISDN to KII. Therefore, the list of regulatory documents may vary. For example, if we are developing a threat model for automated process control systems, then 21 and 17 orders of the FSTEC should be removed from the template and the 31st should be added.

Documents marked with the abbreviation “SKZI” are regulatory documents of the FSB governing the handling of encryption tools. If cryptocurrencies are not used in the information system (now it is a rarity, but still), then these regulatory documents should be removed from the list.

A common mistake here is the addition of various GOSTs and other regulatory documents (they like to enter STR-K here very much), which have nothing to do with threat modeling. Or canceled documents. For example, often in threat models, one can find in the list of regulatory documents the FSB so-called “Methodological Recommendations ...” and “Typical Requirements ...”, which have not been relevant for a long time .

General Provisions

Here, the template presents standard water - why do we need a threat model, etc. What we need to focus on here is a comment about the type of information under consideration. By default, the most common option is presented in the template - personal data (PD). But the system may not have personal data, but there may be other confidential information (CI), and information may not be confidential, but protected (CI) according to other characteristics - integrity and accessibility.

Information System Description

Here you can find general information about the information system - where it is located, as it is called, what data and which class (security level, category) are processed. Here, of course, many are interested in how thoroughly it is necessary to describe the information system.

In the process of multiple approvals of threat models for state information systems, we have developed a solution regarding this - there must be a middle ground. This should not be a copy paste from the technical passport indicating the serial numbers of technical equipment. But on the other hand, a person who is not familiar with the system, who read its description in the threat model, should roughly understand how this system works.

Example:

The server part of the Nipel information system is a cluster of physical servers on which the ESXi 6.x hypervisor is deployed. The server part of the main services of the information system is provided by virtual servers (server names) under the control of operating systems (OS list). The main software that implements the processing processes is (software name). Application software is a client-server application. The client part works as a thick client on user workstations running operating systems (OS list). Users gain access to the information system, both from the local network and through the Internet using secure communication channels. In general, the information system functions as shown in the diagram.

The functional (not topological!) Scheme of the information system is applied.

That's about what it usually looks like. Style and other details, of course, can be very different, the main thing is information that can be drawn from the description.

There is also a section “Security of premises”. Here we describe how the premises are protected during working and non-working hours - video surveillance, ACS, security guard, watchman, alarm and that's all.

The FSB sections “Determining the relevance of the use of cryptographic information protection to ensure the security of personal data” and “Additional objects of protection” are also included in the threat model template. If cryptography is not used, then these sections are simply removed, if used, then there is nothing special to change, in general, and you do not need to enter the name of the information system.

The section "Principles of the threat model" can also not be changed. Just note that there is an option for cases when cryptocurrencies are used in the system, and when not. Choose the one you need and move on.

Intruder Model

Here you can divide this part into classic and new. Classical is the one where potential violators of categories 1, 2 and beyond are described. In fact, this part of the intruder model is left in the template only because regulators like it when it is. The practical value is provided by the section “Violators according to the data bank of the FSTEC Russia threats”.

This section is of practical value because the threats themselves from the FSTEC threat data bank (hereinafter referred to as the BDU) are tied to violators with low, medium, and high potential. The section itself is a copy-paste of descriptions of the characteristics of violators with low, medium and high potentials. The following is the conclusion of our favorite "expert" way - which offender is relevant to us. That is, in fact, the compiler selects the intruder “by eye”, because there are simply no methods for choosing the offender.
We will not give these descriptions in full here, we will try to briefly formulate how the potentials of violators differ. In addition to differentiating in potential, violators are still external and internal.

The most talented hacker in the world who perfectly uses existing tools and can create his own tools is suddenly an intruder with low potential. An intruder with the same capabilities, but having some insider information about the system is already an average potential. The main phrase that distinguishes the medium potential from the low: "They have access to information about the structural and functional characteristics and features of the functioning of the information system." Here you need to think carefully about how likely such information is to leak. High potential offenders, in short, are mainly intelligence agencies. Here we have the opportunity to attract specialized scientific organizations and obtain information from physical fields, and that’s all.

In realistic situations, the potential of the intruder is either low or medium.

"FSB" sections

Next are the sections “Generalized capabilities of attack sources” and “Implementation of information security threats identified by the capabilities of attack sources”. These sections are not needed if cryptocurrencies are not used. If they are nevertheless used, then the initial data, and generally tables for these sections do not need to be invented, they are taken from the FSB normative document “Methodological recommendations on the development of regulatory legal acts that define threats to the security of personal data relevant to the processing of personal data in information personal data systems operated in the course of the respective activities ”(approved by the management of the 8th Center of the Federal Security Service of Russia on March 31, 2015, No. 149/7/2 / 6-432).

Our truth in the template, the result is somewhat different from the default, given in the above-mentioned FSB document.

The ultimate goal of these sections is to establish a class of means of cryptographic information protection (CPSI), which can be used in the system under consideration. This class directly depends on the capabilities of the violator and is set in accordance with the 378 order of the FSB (for personal data, but for other types of information there are simply no such requirements).

Most often, the applicable class of cryptocurrencies is KC3. Now let’s tell you why.

In general, in the document “Composition and content of organizational and technical measures to ensure the security of personal data when they are processed in personal data information systems using cryptographic information protection means necessary to fulfill the requirements for personal data protection established by the Government of the Russian Federation for each of the security levels” ( approved by order of the Federal Security Service of Russia dated July 10, 2014 No. 378) the cryptographic information protection class for the system in question is established, firstly, based on and threats, and secondly on the basis of possible infringers.

We will not dwell on the types of threats in detail; there is a lot of information on the Internet. Let us dwell on the fact that there are 3 types of threats and by hook or by crook, if you plan to use cryptography, you need to do the 3rd type of threat (irrelevant threats associated with undeclared capabilities in application and system-wide software). Why?

Because the 378 FSB order:

• CPS class KA in cases when threats of type 1 are relevant to the information system;
• CIPF of class KV and higher in cases where threats of type 2 are relevant to the information system;
• CIPF of class KS1 and higher in cases where threats of type 3 are relevant to the information system.

It seems clear, but what's the problem? The problem is that you cannot buy CPS of classes KA1, KV1 and KV2 just like that, even if you have a lot of money that they cost.

We will carry out a small “investigation”. Download the fresh registry CPSI, we are looking for cryptographic information protection class KA1. The first search came across "Hardware-software encoder M-543K." We go to Google, we write "Buy hardware-software encoder M-543K" - a failure. Trying to “buy” the next cryptocurrency - again, failure. We simply drive in “KA1 cryptocurrency to buy” - a failure. We get only links to other cryptocurrency classes KS1-KC3 or to forums where cryptography is discussed. But the fact is that, as already mentioned, you just can’t buy SCZI classes of spacecraft and spacecraft, only through specialized military units. Why these cryptocurrencies were generally mentioned in the document on personal data is still not clear. Therefore, in ordinary ISDN, it is only the third type of threat.

With KA and KV figured out, but why KC3, and not KS2 and KS1? Here the second condition is already to blame - the offender.

378 FSB order:

12. KS3 class cryptographic information protection systems are used to neutralize attacks, when creating methods, preparing and carrying out which capabilities from the number listed in clauses 10 and 11 of this document and at least one of the following additional capabilities are used:

a) physical access to the CBT on which cryptographic information protection devices are implemented and SF ;
b) the ability to locate the hardware components of the cryptographic information protection system and the SF, limited by the measures implemented in the information system in which the cryptographic information protection system is used and aimed at preventing and suppressing unauthorized actions.

Here the logic is this:

• such common cryptographic information protection tools as, for example, ViPNet Client or CryptoPRO CSP are implemented at user workstations;
• users are potential violators;
• a potential intruder has physical access to computer facilities on which their cryptographic information protection and operating environment are implemented.

Thus, it is possible to justify a lower class of cryptographic information protection systems justifying that our users are not potential violators (difficult), or to use only crypto-gateways located in server rooms, which, in turn, are accessible only to privileged users, whom we excluded from the list of potential violators.

Vulnerabilities

As we recall, the vulnerability model should be indicated in the threat model. The downloadable model of the threat model does not yet have this section, so we’ll briefly describe how to deal with this.

The compiler of the threat model should immediately ask a question: what does a direct list of vulnerabilities identified by the scanner need to be applied to the document? The question is good and the answer is not unique. We know colleagues who do just that, but we think this approach is wrong and that’s why.

First, the model of threats to information security is a document, although subject to change, but still more or less static. Developed once and forgot to significant infrastructure changes in the system.

The list of vulnerabilities that is generated by scanners is very dynamic information. Today we identified vulnerabilities, tomorrow they were fixed and scanned again - we received a new report. The day after tomorrow new signatures appeared, the scanner was updated and found new vulnerabilities, and so on in a circle. What is the point of applying a vulnerability scanner report made at the time the threat model was developed? Nothing.

Secondly, a threat model can be created for a physically non-existent (designed, but not built) information system. In this case, we can’t even scan anything.

The way out of this situation is simple. Specify in the threat model not specific vulnerabilities with the CVE identifier and CVSS rating, but list possible vulnerability classes for a particular information system. And to give this list solidity, we’ll take this list not from the head, but from GOST R 56546-2015 “Information protection. Vulnerabilities in information systems. Classification of vulnerabilities in information systems. " List under the spoiler. We take it and remove unnecessary ones that are not compatible with the structural and functional characteristics of our system. The section is ready!

Private Security Threat Model

And only here we proceed directly to the identification of current threats.
The methodology for determining current threats from the FSTEC in 2008 is a little smacking, and we already wrote about it here . But there is nothing to be done, as is noted in the same article - what is, we are working with. Let's see what exactly we need to do to get a list of current threats.

Fresh documents from the FSTEC prescribe the use of an NDU as a source of information security threats. Now there are 213 threats and the list can be replenished.

Here, I would immediately like to talk about the pros and cons of the BDU. A definite plus is that now there is no need to come up with and formulate threats on your own, although supplementing the threat model with your own threats also prohibits nothing. Another plus is the registered potential of the violator and certain violated information security characteristics for each threat - you do not need to invent anything.

Minuses. The first minus is the terribly meager ability to sort threats. When you first begin to create a threat model using an NLD, the natural desire is to weed out threats that may not be relevant in your system according to structural and functional characteristics. For example, remove threats for virtual containers and hypervisors, because the system does not use virtualization or select threats for BIOS / UEFI for some reason, but there is no such possibility. Not to mention the fact that the BDU has a number of quite exotic threats associated, for example, with supercomputers or grid systems.

Since we, as a licensee organization, are developing many threat models for different systems, we had to manually group 213 threats, otherwise the work is very difficult, especially considering that the threats are not even grouped in any way.

The second minus is a description of the threats themselves. No, somewhere everything is clear and understandable. But sometimes a threat is formulated so that you need to smash your head in order to figure out what it is all about.

Let us return to the definition of the list of actual threats.

Initial Security Level

The first thing to determine is a global parameter - the level of initial security. It is global because it is determined once and does not change from threat to threat.

To determine the level of initial security (it is the initial security factor Y1), you need to select one of the values ​​that is most suitable for your system for seven indicators.

List of features under the spoiler.



Each value corresponds to a high, medium or low level of security. We consider what percentage we got for indicators with different values. About the high level of initial security - forget it does not happen. If “high” and “medium” scored 70% and higher, then we determine the average level of initial security (Y1 = 5), if not, then low (Y1 = 10).

Danger of threats

This section in the template is called “Determining the Consequences of Violating Information Security Properties (Danger of Threats)”. They called it just that, because, in essence, by definition of danger of threats this is a definition of consequences, but when approving a threat model, inspectors may not draw this parallel, and since the “definition of consequences” should be in the threat model, they write a comment.

So, the danger of threats can be low, medium or high, depending on whether minor negative, just negative or significant negative consequences occur when the threat is realized, respectively.

Experts here often argue whether the danger of threats should be determined once and be constant for all threats - or not. This is not specified by the methodology, therefore it is possible and so and so. Our approach is intermediate - we determine the danger of threats depending on the violation of confidentiality, integrity or availability when implementing a specific threat.

According to our logic, the negative consequences do not depend on the method of violating confidentiality, integrity and accessibility. For example, if your personal data flows into some kind of database, then it most likely will not matter to you how it happened - with the help of SQL injection or with the physical access of the intruder to the server (the professional interest of the security officer does not count!). Therefore, we define three “danger threats”, so to speak, for violating confidentiality, integrity and accessibility. Often they may coincide, but it’s better to analyze separately in the threat model. Fortunately, in the NOS for each threat, the violated characteristics are also registered.

Elimination of "unnecessary" threats

Further, in order to immediately cut off unnecessary threats, we make a plate with a list of excluded threats and a justification - why we throw them away.

The template shows as an example:

• elimination of threats associated with grid systems, supercomputers and big data;
• elimination of threats related to virtualization;
• elimination of threats associated with the use of wireless communication networks;
• elimination of threats associated with the use of cloud services;
• elimination of threats to ICS;
• elimination of threats associated with the use of mobile devices;
• elimination of threats, the implementation of which is possible only by an intruder with a high potential.

On the last point, you need to clarify a couple of points:

• if you have identified an intruder with a low potential, then threats that can be carried out by violators with a medium and high potential are excluded here;
• исключаются только оставшиеся угрозы, которые не были исключены в предыдущих пунктах;
• обращайте внимание на то, что в БДУ для некоторых угроз для внутренних и внешних нарушителей может быть определен разный потенциал.

Описание угроз

Next is a table describing threats that have not been excluded. Yes, here you just need to copy-paste the text from the BDU, because the threat model should have a “description of the threats”, it will not work out with identifiers. Let's see what we have in this table.

The number in order and the threat identifier from the BDU - everything is clear here. The “threat description” and “threat implementation method” columns are a text block from the NOS. In the first column we insert the text before the words "Realization of the threat is possible ...". In the second - everything else. The separation is again connected with the requirement of regulatory documents that the “Threat implementation methods” should be described in the threat model. When agreed, this will help to avoid unnecessary questions.



The following table columns are the potentials of internal and external intruders. In order to make the table more compact and give more space to text blocks, we previously mapped the high, medium, and low potentials to the numbers 1, 2, and 3, respectively. If the potential is not specified in the control unit, put a dash.

Column “Impacts” - we also take data from the control unit.

The column “Disturbed properties” - K, C and D, confidentiality, integrity and accessibility - was replaced with letters for the same purpose as in the case of violators.

And the last columns are “Prerequisites” and “Justification for the absence of prerequisites”. The first is the beginning of determining the coefficient Y2, it is also the probability of the threat, which in turn is determined from the presence of prerequisites for the realization of the threat and the adoption of measures to neutralize the threat.



It is important to say here that the last column is purely our initiative and is not provided for by law. Therefore, you can safely remove it. But we consider it important that if a specialist further eliminates threats, because there are no prerequisites for their implementation, it is important that he describes why he decided so.

Also connected with this point is the fact that we are here in a sense moving away from the threat modeling technique. According to the methodology for threats that have no prerequisites, it is necessary to further calculate their relevance. And in some cases, threats that have no prerequisites can become relevant. We consider this a defect in the legislation and from the final table we exclude threats that have no prerequisites.

List of current threats

More precisely, the last table is a list of current and irrelevant threats and a set of remaining parameters to determine their relevance. There are already no threats for which there are no prerequisites, but from the remaining threats, based on the calculation of the coefficients, some threats may be considered irrelevant.

In the last table, we deliberately did not include some parameters:

• Y1 - this parameter is global, so just keep it in mind;
• prerequisites - in the final table we have only threats that have prerequisites, therefore there is no sense in this column.

Let's go through the columns briefly. The number in order and the threat is only in the form of an identifier - everything is clear here.

“Measures taken” - by “expert” means we determine whether measures have been taken to neutralize this threat (by the way, another trick of the method is that if the measures are “taken”, the threat can still remain relevant). There may be three options: accepted; accepted but insufficient; not accepted (+, + -, - respectively).

Based on the measures taken and taking into account that there are prerequisites for the threat, the probability coefficient (Y2) is determined, how to determine it is higher under the spoiler.

The next column is the threat realizability coefficient Y. It is calculated using the simple formula Y = (Y1 + Y2) / 20.

The possibility of implementation is a verbal analogue of the coefficient Y. It is determined depending on the numerical value as follows:



Danger - above we have identified the danger of a threat based on the violated security feature. Here we already enter the necessary value of the danger based on what security features this particular threat violates.

Well, the last one is the relevance of the threat. Determined by the table:



Hooray! Our threat model is ready.