Writing a threat model

Hello everyone, we are continuing our cycle of articles on “paper safety”. Today we will talk about the development of a threat model. If the goal 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 in general educational purposes.


')

Why do you need a threat model?

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

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

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

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

The composition and content of organizational and technical measures to ensure the security of personal data when they are processed 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, including through the use of information security tools in the information system, which have passed the conformity assessment procedure in the prescribed manner in cases where the use of such tools is necessary to neutralize actual threats to the security of personal data.

Requirements for the protection of non-state secret information contained in state information systems (approved by the FSTEC of Russia on February 11, 2013 No. 17)

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

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

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

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

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

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

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

Content of the threat model

With the need to create a document figured out, let's see what the law on its content prescribes. Here, oddly enough, everything is pretty meager.

As a textbook example of describing the content of a threat model, you can use the 17 FSTEC order:

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 the offenders (violator model), possible information system vulnerabilities, ways to implement information security threats and the consequences of violation of information security properties.

You will not believe, but that's all. But on the other hand, although the text is not much, but it is quite informative. Let's reread and write out what should be in our threat model:

• description of the information system;
• structural and functional characteristics;
• description of security threats;
• offender model;
• possible vulnerabilities;
• ways of realizing threats;
• consequences of violation of information security properties.

This is required by law, which is required by the FSTEC. In addition, there are also requirements of the FSB (about them a bit later) and some informal requirements-wishes from FSTEC, which we encountered in the process of agreeing threat models of state information systems.

Introductory part of the threat model

Ok, let's get to the content of the document.

I think about the title page, the 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 like that.

Government Decree of May 11, 2017 No. 555:

4. The terms of reference for the creation of a system and the model of information security threats are approved by an official of the executive body entrusted with the appropriate authority.

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

Section "Regulatory and methodological support"

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

Documents marked with the abbreviation "SKZI" are the regulatory documents of the FSB regulating the handling of encryption tools. If cryptographic tools are not used in the information system (now it is rare, but still), then these regulatory documents should be removed from the list.

A frequent mistake here is the addition of various GOST and other regulatory documents (STR-K is very fond of entering here) that are not related to the modeling of threats. Or canceled documents. For example, often in threat models one can find in the list of normative documents of the FSB so-called “Methodical recommendations ...” and “Typical requirements ...”, which have not been relevant for a long time.

General provisions

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

Description of the information system

Here you can find general information about the information system - where it is located, what is called, what data and what class (level of protection, category) are processed. Here, of course, many are interested in how much detail the information system needs to be described.

In the process of multiple reconciliation of threat models for state information systems, we have worked out a decision on this — there must be a happy medium. This should not be a copy-paste from a technical passport with serial numbers of hardware. 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 very 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 work of the server part of the basic 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 technological processes of processing is (the name of the software). Application software is a client-server application. The client side works as a fat client on user workstations running operating systems (OS list). Users get 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.

A functional (not topological!) Information system diagram is applied.

This is how it usually looks like. Style and other details, of course, can vary greatly, the main thing is the information that can be extracted from the description.

There is also a section called “Security of the premises”. Here we describe how the premises are protected during business and non-working hours - video surveillance, access control, security guard, doorman, alarm system and that's it.

Here, in the template of the threat model, there are purely FSB sections “Determining the relevance of using the CMIS for ensuring the security of personal data” and “Additional objects of protection”. If cryptography is not used, then these sections are simply removed, if used, then there is nothing special to change, in general, there is no need, except for how to enter the name of the information system.

The section "Principles of a threat model" can also not be changed. Just note that there is an option for when the system uses cryptographs, and when not. Choose the right and go further.

Intruder Model

Here you can divide this part into classic and new. The classic is the one where the potential violators of the 1, 2 and further categories are described. In fact, this part of the offender model is left in the template only because regulators like it when it is. Of practical value is the section “Violators according to the Threat Databank of the FSTEC of Russia”.

This section is of practical value because the threats themselves from the FSTEC threats database (hereinafter referred to as IAB) are tied to violators with low, medium and high potential. The section itself is a copy-paste description of the characteristics of violators with low, medium and high potentials. Next is the conclusion of our favorite "expert" by - what the offender for us is relevant. That is, in essence, the compiler chooses the violator “by eye”, because there are simply no methods for choosing the violator.
We will not give these descriptions in full here; we will try to briefly formulate the difference between the potentials of the violators. In addition to the delimitation of the potential violators are still external and internal.

The most talented hacker in the world who perfectly uses existing tools and can create his tools is suddenly a troublemaker 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 average 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 a leak of such information. Violators with high potential, if briefly, it is mainly special services. Here we have the opportunity to attract specialized scientific organizations and information gathering from physical fields and that’s all.

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

"FSB" sections

Then follow the sections “Generalized capabilities of attack sources” and “Realization of information security threats, determined by the capabilities of attack sources”. These sections are not needed unless cryptographic tools are used. If they are still used, then the source data, and in general the tables for these sections are not necessary to be invented, they are taken from the Federal Security Service normative document “Guidelines for the development of legal acts defining threats to the security of personal data that are relevant to the processing of personal data in information personal data systems operated during the implementation of the relevant 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).

We have the truth in the template, the result is somewhat different from the default, given in the above document, the FSB.

The ultimate goal of these sections is to establish a class of cryptographic information protection (CIPS) that can be used in the system in question. This class directly depends on the abuser’s capabilities and is set in accordance with the 378 order of the FSB (for personal data, and for other types of information there are simply no such requirements).

The most commonly used class of cryptographic tools is KC3. Now tell you why.

In general, 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 the means of cryptographic protection of information necessary to fulfill the requirements for personal data protection for each level of protection established by the Government of the Russian Federation” ( approved by order of the Federal Security Service of Russia dated July 10, 2014 No. 378) the class of SKZI for the system under consideration is established, firstly, based on the type and threats, and secondly on the basis of possible infringers.

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

Because the 378 order of the FSB:

• SKZI class KA in cases where threats of type 1 are relevant for the information system;
• SKZI class KV and above in cases where the type 2 threats are relevant for the information system;
• SKZI class KS1 and above in cases where the type 3 threats are relevant for the information system.

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

We will conduct a small "investigation." We download the new registry SKZI , look for SKZI class KA1. The first search was “Hardware-software encoder M-543K”. We go to Google, we write "To buy hardware and software encoder M-543K" - a failure. We are trying to “buy” the following cryptographic device - again a failure. We drive in just “KA1 buy crypto tools” - failure. We get only links to other cryptographic classes KS1-KS3 or to forums where cryptography is discussed. But the fact is that, as has already been said, you simply cannot buy SKZI of the classes KA and KV, only through specialized military units. Why these cryptographs were even mentioned in the personal data document is still not clear. Therefore, in the usual ISPD - only the third type of threats.

With KA and KV figured out, but why precisely KS3, and not KS2 and KS1? There is already a second condition to blame - the offender.

378 order of the FSB:

12. SKZI class KS3 are used to neutralize attacks, in creating methods, the preparation and conduct of which uses the capabilities listed in paragraphs 10 and 11 of this document and at least one of the following additional capabilities:

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

Here is the logic:

• Such common IMSs, such as ViPNet Client or CryptoPRO CSP, are implemented on users' workstations;
• users are potential offenders;
• A potential intruder has physical access to the computer facilities on which their SKZI and the environment of operation are implemented.

Thus, it is only possible to justify a lower class of CIPF only by proving that our users are not potential violators (difficult), or to use only crypto-gateways that are located in server rooms, which, in turn, have access only to privileged users whom we have excluded from the list of potential violators.

Vulnerabilities

As we remember, potential vulnerabilities should be listed in the threat model. In the downloadable template, the threat model of this section does not yet exist, so we briefly describe how to handle this.

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

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

The list of vulnerabilities generated by scanners is very dynamic information. Today we revealed vulnerabilities, tomorrow they were eliminated 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. What is the point of applying a vulnerability scanner report made at the time of the development of a threat model? No

Secondly, a threat model can be created for a physically non-existent (designed, but not built) information system. In this case, we can not 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 the possible classes of vulnerabilities for a specific information system. And in order to give this list of solidity, let us take this list not from the head, but from GOST R 56546-2015 “Information security. Vulnerabilities of information systems. Classification of information systems vulnerabilities. The list under the spoiler. We take it and remove unnecessary, incompatible with the structural and functional characteristics of our system. The section is ready!

Private security threat model

And it is only here that we proceed directly to the determination of actual threats.
The method for determining the actual threats from the FSTEC of 2008 slightly smells slightly and we have already written about it here . But nothing can be done here, as in the same article noted - that is, with what we are working. Let's see what exactly we need to do to get a list of current threats.

Fresh documents from the FSTEC prescribe as a source of information for information security threats to use the AIS. 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 NIS. A definite plus is that now there is no need to invent and formulate threats on their own, although it also prohibits nothing to supplement the threat model with its own threats. Another plus is the prescribed potential of the violator and certain violated security characteristics of the information for each threat - no need to invent anything.

Minuses. The first minus is terribly scary opportunities for sorting threats. When you first begin to make a model of threats according to the NDU, then the natural desire is to weed out threats that may not be relevant in your system according to structural and functional characteristics. For example, to remove threats to virtual containers and hypervisors, because the system does not use virtualization or to select threats to the BIOS / UEFI is necessary for some reason, but there is no such possibility. Not to mention the fact that there are a number of quite exotic threats in the NDBU, for example, connected with supercomputers or grid systems.

Since we, as a licensing organization, are developing many threat models for different systems, we had to manually divide 213 threats into groups, otherwise the work is very difficult, especially considering that the threats are not grouped even in order.

The second minus is the description of the threats themselves. No, somewhere everything is clear and understandable. But there is a threat that is formulated in such a way that you need to break your head in order to figure out what this is all about.

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

Initial security level

The first thing to define 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’s also the coefficient of initial security Y1), for seven indicators, choose one of the values ​​that is most suitable for your system.

List of characteristics under the spoiler.



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

Danger of threats

This section in the template is called “Determining the consequences of violation of information security properties (danger of threats)”. They called it this way because, in essence, by definition of the danger of threats, this is a definition of consequences, but when agreeing on a threat model, the verifiers may not draw this parallel, and since the “determination of consequences” must 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.

Specialists here often argue whether the danger of threats should be determined once and be a constant for all threats - or not. Methodology is not specified, so it is possible and so. Our approach is intermediate - we determine the danger of threats depending on the violation of confidentiality, integrity or availability in the implementation of a specific threat.

According to our logic, the negative consequences do not depend on the method of violation of confidentiality, integrity and availability. For example, if your personal data leaks in some database, then you most likely will not care how it happened - with the help of SQL injection or with the physical access of the intruder to the server (professional interest of the IB person does not count!). Therefore, we define three “danger threats”, so to speak, to violate confidentiality, integrity and availability. Often they may coincide, but it is still better to analyze the threats in the threat model separately. Fortunately, in the AUU for each threat, the characteristics that are violated are also spelled out.

Elimination of “extra” threats

Next, in order to immediately cut off the extra threats, we make a sign with a list of excluded threats and a rationale - why we throw them out.

In the template as an example are presented:

• elimination of threats associated with grid systems, supercomputers, and big data;
• elimination of threats associated with virtualization;
• elimination of threats associated with the use of wireless communication networks;
• exclusion of threats associated with the use of cloud services;
• elimination of threats to process control systems;
• exclusion of threats associated with the use of mobile devices;
• the exclusion of threats, the realization of which is possible only by the violator with high potential.

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

• if you identify an intruder with a low potential, then there are excluded threats that violators with medium and high potential can carry out;
• only the remaining threats that were not excluded in the previous paragraphs are excluded;
• , .

Next comes a table describing the threats that were not excluded. Yes, here it is necessary to copy-paste the text from the NDB, because the threat model should have a “description of threats”, it’s impossible to get rid of the identifiers. Let's see what we have in this table.

Number in order and the identifier of threats from the NDU - everything is clear. Columns "description of the threat" and "method of realization of the threat" - a text block from the NDT. Insert the text in the first column to the words "The realization of the threat is possible ...". In the second - everything else. The separation is again connected with the requirement of regulatory documents that the “Methods of realization of the threat” should be described in the threat model. When coordinating this will help avoid unnecessary questions.



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

Column "Objects of impact" - also take data from the NDT.

The column “Violable properties” - K, TS and D, confidentiality, integrity and availability - were replaced with letters for the same purpose as in the case of violators.

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



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

This moment is also connected with the fact that we are in a sense moving away from the threat modeling methodology. According to the methodology for threats that do not have prerequisites, it is necessary to further consider their relevance. And in some cases, threats that do not have the prerequisites may become relevant. We consider this a flaw in the legislation and still exclude from the final table threats that have no prerequisites.

List of current threats

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

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

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

Briefly go through the columns. The number is in order and the threat is only in the form of an identifier - everything is clear.

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

Based on the measures taken and given 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 coefficient of realizability of the threat Y. It is calculated by the simple formula Y = (Y1 + Y2) / 20.

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



Danger - above, we determined the danger of a threat based on the violated property of security. Here we enter the desired hazard value based on what security properties this particular threat violates.

And finally - the relevance of the threat. Determined by the table:



Hooray! Our threat model is ready.