Problems of the current methodology for determining current threats from the FSTEC



    Good day, Habr! Today we would like to criticize the document “Methodology for identifying current threats to the security of personal data when they are processed in personal data information systems”, approved by the FSTEC of Russia on February 14, 2008. (hereinafter referred to as the Methodology).

    This Methodology is the only approved document for determining current security threats, and in accordance with the current legislation, “Methodological documents developed and approved by the FSTEC of Russia ... ” are used to identify information security threats and develop a model of information security threats .

    As can be seen from the date of approval of the Methodology, it is already over 10 years old and there are really many problems with it. Which ones - we will consider further.



    Problem number 1. Link to personal data



    This problem pops up already in the title of the document: “Methodology for determining the actual threats to the security of personal data during their processing in personal data information systems ”.

    Further along the text of the Methodology we see the following:

    The methodology is intended for use in carrying out work to ensure the security of personal data during their processing in the following automated personal data information systems:

    • state or municipal ISPDn;
    • ISPDn, created and (or) operated by enterprises, organizations and institutions (hereinafter referred to as organizations) regardless of the form of ownership necessary to perform the functions of these organizations in accordance with their purpose;
    • ISPDn created and used by individuals, with the exception of cases where the latter use these systems exclusively for personal and family needs.



    Well, ok, linking to personal data and ISPD, but what's the problem? And the problem arises when we need to write a threat model, for example, for a state information system (GIS), in which personal data is not processed.

    Everything would be fine if every GIS operator cooked in its own sauce in terms of information security - would develop a threat model using the method itself, would use it only by itself and would not show it to anyone. Only here, by a resolution of the Government of the Russian Federation dated May 11, 2017 No. 555, operators of all newly created GIS were obliged to coordinate threat models and technical specifications for creating an information protection system with the FSTEC of Russia and the FSB of Russia.

    And, of course, in the case of an overly “creative” approach to developing a threat model, the GIS operator will receive an answer that “The threat model is developed without taking into account regulatory documents approved by the FSTEC of Russia, redo it”.

    And we simply do not have another approved methodology.

    Problem number 2. Controversial Legitimacy



    The very first paragraph of the Methodology says:

    The methodology for determining the actual threats to the security of personal data (PDN) during their processing in personal data information systems (ISPDn) was developed by the FSTEC of Russia on the basis of Federal Law of July 27, 2006 No. 152-ФЗ “On Personal Data” and “Regulation on Ensuring Personal Security” data during their processing in personal data information systems ”, approved by the Decree of the Government of the Russian Federation of November 17, 2007 No. 781 , taking into account the current regulatory documents of the FSTEC of Russia on the protection of information rmacii.


    The problem here is that the bold resolution of the Government was canceled in 2012. But if only it appeared in this paragraph, then the Methodology could be considered completely illegitimate. But there is still 152-FZ, which is quite lively and acting. The opinions of lawyers on the issue of legitimacy of the Methodology diverge.

    In any case, as already mentioned, this is the only document that is somehow approved, so we suffer and use it. Why are we “tormented”? Let's consider further.

    (Semi) Problem number 3. Lack of communication with the FSTEC Russia



    While all relevant FSTEC regulatory documents require the use of a threat data bank as a source of threat models , the Methodology refers to the document “Basic model of personal data security threats when they are processed in personal data information systems”, which was also approved in 2008 and which in fact is impossible to use.

    This, on the whole, is not a direct problem, we are simply using the NOS and that’s it. But at the same time, this situation clearly illustrates the inconsistencies and inconsistencies of regulatory documents. While the 17, 21 and 239 orders of the FSTEC refer to the somehow updated BDU, the Methodology stuck in 2008.

    Problem number 4. Initial Security Index



    So, we got to the actual methodology for determining the actual threats. Its essence is as follows: we have a list of threats, for each threat, in order to determine its relevance (or not relevance), we need to determine a number of parameters, and then through the calculations / manipulations described in the Methodology, come to the desired goal - a list of actual threats.

    The first of these parameters that we need to determine is the "level of initial security", it is also the "degree of initial security", it is the "coefficient of initial security", it is Y1 (by the way, this is another intermediate problem of the methodology - there are too many names for one and the same entity).

    The degree of initial security is determined as follows. There are 7 indicators (technical and operational characteristics of the system), for each indicator there are several options for the values ​​and for each indicator you need to choose only one of these values, the most suitable for our information system. The selected value is associated with a level of security (high, medium or low).

    Next, we consider how many options we have with the levels of "high", "medium" and "low". If out of 7 indicators, 70% or more received a "high level of security", then the degree of initial security of the entire system is high (Y1 = 0). If out of 7 indicators, 70% or more received a high or medium level of security, then the degree of initial security of the entire system is average (Y1 = 5). If the previous two conditions are not satisfied, then the degree of initial security of the entire system is low (Y1 = 10).

    List of characteristics and their values
    technical and operational characteristicssecurity level
    tallaveragelow
    1. by territorial distribution:
    distributed ispn, which covers several areas, territories, districts or the state as a whole--+
    urban ispdn, covering not more than one settlement (city, village)--+
    корпоративная распределенная испдн, охватывающая многие подразделения одной организации-+-
    локальная (кампусная) испдн, развернутая в пределах одного здания-+-
    локальная испдн, развернутая в пределах одного здания+--
    2. по наличию соединения с сетями связи общего пользования:
    испдн, имеющая многоточечный выход в сеть связи общего пользования--+
    испдн, имеющая одноточечный выход в сеть связи общего пользования-+-
    испдн, физически отделенная от сети общего пользования+--
    3. по встроенным (легальным) операциям с записями баз персональных данных:
    чтение, поиск+--
    запись, удаление, сортировка-+-
    модификация, передача--+
    4. по разграничению доступа к персональным данным:
    испдн, к которой имеют доступ определенные перечнем сотрудники организации, являющейся владельцем испдн, либо субъект пдн-+-
    испдн, к которой имеют доступ все сотрудники организации, являющейся владельцем испдн--+
    испдн с открытым доступом--+
    5. по наличию соединений с другими базами пдн иных испдн:
    интегрированная испдн (организация) использует несколько баз пдн испдн, при этом организация не является владельцем всех используемых баз пдн)--+
    испдн, в которой используется одна баз пдн, принадлежащая организации — владельцу данной испдн+--
    6. по уровню обобщения (обезличивания) пдн:
    испдн, в которой предоставляемые пользователю данные являются обезличенными (на уровне организации, отрасли, области, региона и т. д.)+--
    испдн, в которой данные обезличиваются только при передаче в другие организации и не обезличены при предоставлении пользователю в организации-+-
    испдн, в которой предоставляемые пользователю данные не являются обезличенными (т. е. присутствует информация, позволяющая идентифицировать субъекта пдн)--+
    7. по объему пдн, которые предоставляются сторонним пользователям испдн без предварительной обработки
    испдн, предоставляющая всю базу данных с пдн--+
    испдн, предоставляющая часть пдн-+-
    испдн, не предоставляющая никакой информации+--



    It seems normal, but.

    Firstly, indicators, their values ​​and security levels are distributed so that in a real information system (not a stand-alone computer disconnected from the network, both communication and electrical), you will never get a high degree of security .

    Secondly, the indicators themselves and their values ​​are very strange. It often happens that two values ​​are suitable for one indicator at once, or none is suitable.

    Example 1:



    The indicator "By territorial distribution".

    Possible values:

    • Distributed ISPD, which covers several regions, territories, districts or the state as a whole;
    • urban ISPDn, covering not more than one settlement (city, village);
    • Corporate distributed ISPD, covering many divisions of the same organization;
    • local (campus) ISPD, deployed within several closely located buildings;
    • local ISPD, deployed within the same building.


    Here, situations are not uncommon when two values ​​are suitable for an information system at once: “distributed” and “corporate” or “urban” and “corporate”.

    Example 2:



    Indicator “On the differentiation of access to personal data”

    Possible values:

    • ISPDn, to which access is determined by a list of employees of the organization that is the owner of ISPD, or an individual PDN;
    • ISPDn, to which all employees of the organization that owns the ISPD have access;
    • ISPD with open access.


    There are two extremes, either the system is open or has access to it, only employees of the organization that owns this information system.

    In the modern world, there are often situations where access to protected information is provided to third-party users (who are not employees of the owner of the information system), while the system is not publicly available. These points are perfectly reflected in the orders 17 and 21 of the FSTEC (there are separate measures for connecting external users), but are absent in the Methodology. At the same time, we cannot add our own values; the Methodology does not provide for this.

    Thirdly, there are indicators that are tightly connected with personal data and out of their context are simply not applicable, for example, the indicator “By the level of generalization (depersonalization) of personal data”. When we use the Methodology to develop a threat model for GIS that does not process PD, this indicator simply needs to be thrown out.

    And what does “ISPDn, which does not provide any information” alone cost ...

    Problem number 5. Calculation of relevance for threats that have no prerequisites



    If there is Y1, then there must be Y2. Y2 is a different "threat probability." There are 4 gradations: unlikely, low probability, average probability and high probability (Y2 = 0, 2, 5, 10, respectively).

    The likelihood of a threat depends on the presence of preconditions for the realization of the threat and on the presence / absence / incompleteness of the measures taken to neutralize the threat.

    A threat is considered unlikely if there are no objective prerequisites for the implementation of the threat for it.

    So, what's the problem? And the problem is that instead of writing in the Methodology that unlikely threats are simply excluded from the list of actual threats, for them we simply have our own value Y2. And this means that for threats for which there are no prerequisites (for example, threats associated with virtualization environments in systems where virtualization is not used), we must calculate the coefficients and determine the relevance / relevance. Isn’t it nonsense?

    Bullshit, especially considering that under a certain set of circumstances, threats for which there are no prerequisites, purely by the Methodology, can suddenly become relevant. This is possible with a low level of initial security and / or with an average / high risk of threats. But in any case, we must spend time calculating. Therefore, it is good practice in this place not to apply the “forehead” methodology, but to weed out unlikely threats at the preliminary stage.

    So far, the experience of agreeing with the FSTEC threat models for GIS suggests that the regulator has no complaints about this approach.

    (Semi) Problem number 6. Another meaningless parameter



    The first meaningless (in reality, not applicable) parameter was a high degree of initial security. Further, if you carefully read the Methodology, you can find its bro.

    If those who have read up to this place are interested in what we are doing with Y1 and Y2, then we use them to calculate Y (it is also the possibility of realizing a threat) using the uncomplicated formula Y = (Y1 + Y2) / 20. Depending on the resulting value, the feasibility may be low, medium, high or very high. And the last gradation is meaningless.



    Here is a table from the Methodology by which we determine the relevance of a threat in two ways - the possibility of a threat (it’s Y) and the danger of a threat (see below). The table shows that the high and very high possibility of implementing a threat are no different, all threats at these levels will be relevant, despite the importance of the threat of the threat.

    What was the point of introducing an extra pointless gradation - it is not clear. In general, this is neither cold nor hot for us, so this can only be partially considered a problem.

    Problem number 7. Negative consequences (danger of threats)



    Well, let's move on to the “Danger of Threat” parameter. There are gradations (this is a turn!) Low, medium and high. They differ in what consequences for the subject of personal data the implementation of the threat will lead to: minor negative, just negative, significant negative, respectively.

    You probably think that further in the Methodology it is written in detail and with figures - what are minor negative consequences and how do they differ from significant ones? No, the compiler of the document limited himself to the phrase that the danger of threats is determined “based on a survey of experts (specialists in the field of information protection)”. I think it’s no secret to anyone that in such cases, many threat model developers will simply always put the threat of threats low by default in order to reduce the list of current threats. In addition, it is worth noting that often there are no “experts” who can be interviewed within a radius of 200 km.

    Actually, the problems with the danger of threats do not end there. In addition, developers of threat models for information systems, in which personal data are not processed, are again tormented. And if the concept of “personal data” can be easily replaced by “protected information”, then what should the “subject of personal data” be replaced in the context of the negative consequences? Here, already every threat model developer acts according to the situation.

    And what is FSTEC?



    A reasonable question - if the current methodology is so bad, then how is the regulator with plans to update the document?

    Here the story is this - back in 2015, the FSTEC posted a draft of a new threat modeling technique . For some time, the FSTEC accepted from all interested parties proposals and wishes for improving the project. Then the first six months to the questions “Where is the new methodology?” Followed by the answer that the regulator received a lot of feedback on the draft document and is now processing the whole thing. Then, about another year, the FSTEC representatives answered the same question that the document was being approved by the Ministry of Justice (the draft document with corrections based on feedback from the population was not posted, the link above is the original version). And then they began to shrug.

    In general, the fate of replacing the Methodology is both sad and foggy at the same time. It is sad because the project was not bad, certainly better than what you have to use now, although we also had our own questions and complaints there.

    Conclusion



    What is the result:

    • we have the only legitimate method for determining the current threats to information security and in most cases the current legislation requires us to use it;
    • the current methodology is problematic from the beginning, plus it is outdated and does not agree with more recent regulatory documents of the same FSTEC;
    • the current method is tied to personal data and to personal data subjects, which leads to the need to invent a bicycle when developing threat models for information systems without personal data;
    • threat models for GIS must be agreed with the FSTEC, therefore for GIS we cannot but use the current methodology;
    • for ISPD, too, we cannot but use it, since the methodology was developed "pursuant to 152-FZ"
    • nothing is known about the plans of the FSTEC to replace the outdated and poor methodological document.


    These are the everyday life of domestic IBE. Good to all.

    Also popular now: