Defense level x1. Classification of information security tools from the fstek and the fsb of russia

The requirements of the FSB are still a mystery to many experts. Why is this happening?

• Optional use of encryption by operators.
• Difficult to understand normative base.
• Lack of clarifications to the documents by the regulator.
• Fear of operators incurring additional checks when using cryptography.

But despite all the difficulties, cryptographic protection indispensable when transferring personal data over an insecure communication channel, this includes, for example, remote work employees with a customer database, exchange of information between branches and head office, transfer of personal information of employees to third parties. In one form or another, such tasks are present in almost every organization.

Let's take a look at the regulatory framework on this issue in general terms. There are three main documents on the cryptographic protection of personal data in the Russian Federation:

1. Guidelines for ensuring the security of personal data with the help of cryptographic tools when they are processed in personal data information systems using automation tools, approved by the leadership of the 8th Center of the FSB of Russia on February 21, 2008 No. 149 / 54-144 -
2. Standard requirements for organizing and ensuring the functioning of encryption (cryptographic) tools designed to protect information that does not contain information constituting state secret, if they are used to ensure the security of personal data during their processing in personal data information systems ", approved by the leadership of the 8th Center of the FSB of Russia on February 21, 2008 No. 149/6/6-622 - The document has not been officially published.
3. Order of the Federal Security Service No. 378 dated July 10, 2014 “On approval of 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 using cryptographic information protection tools necessary to fulfill the protection requirements established by the Government of the Russian Federation personal data for each of the security levels”. Registered with the Ministry of Justice of Russia on August 18, 2014.

The document was adopted back in the days of the "old" documents of the FSTEC ("four books", 58th Order, 781 Government Decrees) and supplemented their content. It should be noted that the normative document in question was not registered with the Ministry of Justice, and today its status is unclear. Most likely, in connection with the publication of Order 378, the Guidelines have lost their relevance. However, I want to briefly dwell on the content of the document so that it is clear how the requirements for encryption systems have historically evolved.

The requirements of the above document (as well as other regulations in the field of cryptographic protection of PD) do not apply to the following cases:

• Processing of personal data without the use of automation tools;
• Work with personal data constituting a state secret;
• Usage technical means located outside the Russian Federation.

The document says that in the case of using cryptographic protection tools, it is necessary to develop a threat model according to the requirements of both the FSTEC and the FSB (with rare exceptions). Operators can create models of threats and the intruder themselves, only if necessary, attracting licensees from the FSB. All threats in the document are divided into attacks and threats that are not attacks, examples of common threats are given. You can be guided by the Methodology as a reference material when writing a model for new requirements.

The top-level threat model determines the security characteristics of PD and other protected objects. In the detailed threat model, the required conditions for cryptoprotection are indicated.

The threat model is influenced by various factors: conditions for the creation and use of PD, forms of presentation of PD, security characteristics, etc.

In addition to the usual characteristics: integrity, confidentiality and availability, non-repudiation, accounting, authenticity and adequacy are also distinguished.

Top level threat model example:

1. Threat to confidentiality of personal data.
2. Threat to the integrity of personal data.
3. The threat to the availability of personal data.

The document is devoted not only to the formation of a threat model, but also to the specifics of compiling an adequate model of an intruder. All violations in the Guidelines are divided into two classes: direct and indirect violations of the security of personal data (threats that create conditions for the emergence of direct threats). There are 6 main types of offenders: H1, H2, H3, H4, H5, H6. The higher the number, the more opportunities, the offender of each next type inherits the capabilities of the previous one. The operator independently determines the level of training of violators, the tools available to them and makes an assumption about collusion. The document indicates the main characteristics of the intruder of each type. Also, 6 levels of crypto-protection are defined: KC1, KC2, KC3, KB1, KB2, KA1 and 6 classes of crypto-means with similar names, nothing has changed in this regard to this day. ISPDs are also divided into 6 classes, depending on the highest category of the offender. AK1 - if the highest category of the offender is H1, AK2 - if H2, AK3 - if H3, AK4 - if H4, AK5 - if H5, AK6 - if H6. The means of cryptoprotection are distributed accordingly: AK1 - KS1, AK2 - KS2, AK3 - KS3, AK4 - KV1, AK5 - KV2, AK6 - KA1.

Typical requirements

The standard requirements were written in the same period as the Guidelines, they are not registered with the Ministry of Justice, and their status is unclear today. In my opinion, the document contains useful information for study. The duties of users of cryptographic tools are described in detail, the main rules for them are indicated:

• prevent copying of key information;
• do not disclose information about the keys;
• do not record on key media extraneous information etc.

The process of destroying the key is described, the main requirements for the premises are presented. standard forms magazines. Based on the information contained in the document, some useful instructions can be built.

Order 378

The entire professional community was waiting for the release of Order 378, and now, finally, it came into force. To date, this is the main document in the field of cryptographic protection of personal data, and its effect applies to all ISPDs that use cryptographic IPS as protection. The order defines the requirements not only for cryptographic protection, but also for the regime for ensuring the security of premises, the procedure for storing information media and other organizational measures depending on the level of system security. Separately, it is indicated that the operator should use the information security equipment that has passed the conformity assessment - certified according to safety requirements. Protective measures are described in great detail, including requirements for the equipment of the premises (locks, sealing devices, window bars, etc.). Unlike the provisions methodological recommendations in Order 378, the CIPF class is determined in relation to the level of security and the actual type of threats. The attacker's capabilities are taken into account only when determining the CIPF class for the 4th level of security.

Table 1. CIPF class

The dependence on the level of security and the type of threats is quite obvious, and, as we can see, the operator can almost always choose a class of cryptographic information protection from several options.

The document is distinguished by a clear logic of presentation - it is enough to know the level of security of your system - the requirements for ISPD of each level are presented in separate sections. It should be noted that the requirements are inherited from lower to higher levels, ISPD of the 1st security level must meet the requirements for ISPD of the 2nd, 3rd and 4th levels. In my opinion, it will not be difficult even for a novice specialist to deal with the requirements of the new Order.

Of course, in one short article it is impossible to determine all the nuances of the cryptographic protection of personal data, and is it necessary to do this? We have analyzed the main points here, understood the logic of the documents, the rest are details that you can study on your own. And in the fifth part, no less important issues will be considered: the definition of requirements for the personal data protection system and the choice of protection measures.

The requirements for information security in the design of information systems indicate features that characterize the means of information protection used. They are defined by various acts of regulators in the field of providing information security, in particular - the FSTEC and the FSB of Russia. What security classes there are, types and types of protection tools, as well as where to learn more about this, is reflected in the article.

Introduction

Today, the issues of ensuring information security are the subject of close attention, since technologies being introduced everywhere without information security are becoming a source of new serious problems.

The FSB of Russia reports on the seriousness of the situation: the amount of damage caused by cybercriminals over several years around the world ranged from $300 billion to $1 trillion. According to the information provided by the Prosecutor General of the Russian Federation, in the first half of 2017 alone, the number of crimes in the field of high technologies in Russia increased six times, the total amount of damage exceeded $ 18 million. An increase in targeted attacks in the industrial sector in 2017 was noted around the world . In particular, in Russia, the increase in the number of attacks compared to 2016 was 22%.

Information technologies began to be used as a weapon for military-political, terrorist purposes, to interfere in the internal affairs of sovereign states, as well as to commit other crimes. The Russian Federation stands for the creation of an international information security system.

On the territory of the Russian Federation, information owners and operators of information systems are required to block attempts of unauthorized access to information, as well as monitor the state of security of the IT infrastructure on an ongoing basis. At the same time, information protection is ensured through the adoption of various measures, including technical ones.

Information security tools, or information security tools, provide protection of information in information systems, which are essentially a combination of information stored in databases, information technologies that ensure its processing, and technical means.

Modern information systems are characterized by the use of various hardware and software platforms, the territorial distribution of components, as well as interaction with open data transmission networks.

How to protect information in such conditions? Relevant requirements are made by authorized bodies, in particular, the FSTEC and the FSB of Russia. Within the framework of the article, we will try to reflect the main approaches to the classification of information security systems, taking into account the requirements of these regulators. Other ways of describing the classification of information security facilities, reflected in the regulatory documents of Russian departments, as well as foreign organizations and agencies, are beyond the scope of this article and are not considered further.

The article may be useful to beginners in the field of information security as a source of structured information about the methods of classifying information security information based on the requirements of the FSTEC of Russia (to a greater extent) and, briefly, the FSB of Russia.

The structure that determines the procedure and coordinates the actions of providing non-cryptographic methods of information security is the FSTEC of Russia (formerly the State Technical Commission under the President of the Russian Federation, the State Technical Commission).

If the reader had to see the State Register of certified information security tools, which is formed by the FSTEC of Russia, then he certainly paid attention to the presence in the descriptive part of the purpose of the information security facility of such phrases as “class RD SVT”, “level of absence of NDV”, etc. (Figure 1) .

Figure 1. A fragment of the register of certified information security facilities

Classification of cryptographic means of information protection

The FSB of Russia defines the following classes of cryptographic information security tools: KS1, KS2, KS3, KB and KA.

The main features of the SZI class KS1 include their ability to withstand attacks carried out from outside the controlled zone. This implies that the creation of attack methods, their preparation and implementation is carried out without the participation of specialists in the field of development and analysis of cryptographic information security tools. It is assumed that information about the system in which these information security tools are used can be obtained from open sources.

If a cryptographic IPS can withstand attacks blocked by means of class CS1, as well as carried out within a controlled zone, then such IPS corresponds to class CS2. At the same time, it is assumed, for example, that during the preparation of an attack, information about physical measures for protecting information systems, providing a controlled zone, etc., could become available.

If it is possible to resist attacks in the presence of physical access to funds computer science with installed cryptographic information security means that such means correspond to the KS3 class.

If a cryptographic information security facility resists attacks, the creation of which involved specialists in the development and analysis of these tools, including research centers, it was possible to conduct laboratory studies of protection tools, then we are talking about compliance with the KV class.

If specialists in the field of using NDV of system software were involved in the development of attack methods, the corresponding design documentation was available and there was access to any hardware components of cryptographic information security facilities, then KA class tools can provide protection against such attacks.

Classification of electronic signature protection means

Facilities electronic signature depending on the ability to withstand attacks, it is customary to compare with the following classes: KS1, KS2, KS3, KV1, KV2 and KA1. This classification is similar to the one discussed above in relation to cryptographic IPS.

conclusions

The article considered some methods of classifying information security in Russia, which are based on the regulatory framework of regulators in the field of information protection. The considered classification options are not exhaustive. Nevertheless, we hope that the presented summary information will allow a novice specialist in the field of information security to quickly navigate.

Means of cryptographic protection of information of protection classes KS2 and KS1 in accordance with the requirements of the Federal Security Service of Russia differ in the actual capabilities of attack sources and the measures taken to counter attacks.

1. Current capabilities of attack sources

Cryptographic information protection tools (CIPF) of the KS1 class are used with the actual capabilities of attack sources, namely, to independently create attack methods, prepare and conduct attacks only outside the controlled zone.

1. independently create methods of attacks, prepare and conduct attacks only outside the controlled zone;
2. independently create attack methods, prepare and conduct attacks within the controlled zone, but without physical access to the hardware on which the cryptographic information protection system and their operating environment (SF) are implemented.

Thus, the CIPF of class KS2 differs from KS1 in terms of neutralization by the actual ability of attack sources, to independently create attack methods, prepare and carry out attacks within the controlled zone, but without physical access to the hardware on which CIPF and SF are implemented.

2. Versions of the CIPF protection class KS3, KS2 and KS1

Option 1 is the basic CIPF software providing the protection class KS1.

Option 2 is the CIPF of class KS2, consisting of a basic CIPF of class KS1 together with a certified hardware and software module trusted boot(APMDZ).

Option 3 is the CIPF of the KS3 class, which consists of the CIPF of the KS2 class together with specialized software for creating and controlling a closed software environment.

Thus, the CIPF software of the KS2 class differs from the KS1 only by adding a certified APMDZ to the CIPF of the KS1 class. Differences of CIPF of class KS3 from class KS1 is the use of CIPF of class KS1 together with certified APMDZ and specialized software for creating and controlling a closed software environment. And also the difference between the CIPF of the KS3 class and the KS2 class is the use of the CIPF of the KS2 class together with specialized software for creating and controlling a closed software environment.

ViPNet SysLocker software (1.0 dated 03/28/2016) is a free specialized software for creating and controlling a closed software environment.

3. Measures to counter attacks

CIPF class KS2 does not apply measures to counter attacks, which are mandatory for the operation of CIPF class KS1, namely:

1. approved the list of persons entitled to access to the premises;
2. a list of persons entitled to access to the premises where the CIPF is located was approved;
3. approved the rules for access to the premises where the CIPF is located, during working and non-working hours, as well as in emergency situations;
4. access to the controlled area and the premises where the resources of personal data information systems (ISPD) and (or) CIPF are located, is provided in accordance with the access control regime;
5. information about the physical protection measures of the objects in which the ISPDs are located is available to a limited circle of employees;
6. documentation for CIPF is kept by the person responsible for CIPF in a metal safe (cabinet);
7. the premises where the documentation for CIPF, CIPF and SF components are located, are equipped with entrance doors with locks, ensuring that the doors of the premises are permanently locked and opened only for authorized passage;
8. representatives of technical, maintenance and other support services when working in the premises (racks) where the CIPF is located, and employees who are not users of the CIPF, are in these premises only in the presence of operating employees;
9. employees who are users of ISPD, but who are not users of CIPF, are informed about the rules of work in ISPD and responsibility for non-compliance with the rules for ensuring information security;
10. CIPF users are informed about the rules for working in ISPD, the rules for working with CIPF and responsibility for non-compliance with the rules for ensuring information security;
11. registration and accounting of user actions with personal data;
12. the integrity of information security tools is monitored.

Means of cryptographic protection of information, or CIPF for short, are used to provide comprehensive protection of data that is transmitted over communication lines. To do this, it is necessary to comply with the authorization and protection of the electronic signature, authentication of the communicating parties using the TLS and IPSec protocols, as well as protection of the communication channel itself, if necessary.

In Russia, the use cryptographic means information security is largely classified, so there is little publicly available information on this topic.

Methods used in CIPF

• Authorization of data and ensuring the safety of their legal significance during transmission or storage. To do this, algorithms for creating an electronic signature and its verification are used in accordance with the established RFC 4357 regulations and use certificates according to the X.509 standard.
• Protection of data confidentiality and control of their integrity. Asymmetric encryption and imitation protection are used, that is, counteraction to data spoofing. Complied with GOST R 34.12-2015.
• Protection of system and application software. Tracking unauthorized changes or malfunctions.
• Management of the most important elements of the system in strict accordance with the adopted regulations.
• Authentication of the parties exchanging data.
• Connection protection using the TLS protocol.
• Protection of IP connections using IKE, ESP, AH protocols.

The methods are described in detail in the following documents: RFC 4357, RFC 4490, RFC 4491.

CIPF mechanisms for information protection

1. The confidentiality of stored or transmitted information is protected by the use of encryption algorithms.
2. When establishing a connection, identification is provided by means of electronic signature when used during authentication (as recommended by X.509).
3. The digital document flow is also protected by means of an electronic signature together with protection against imposition or repetition, while the reliability of the keys used to verify electronic signatures is monitored.
4. The integrity of information is ensured by means of a digital signature.
5. Using asymmetric encryption features helps protect data. In addition, hashing functions or imitation protection algorithms can be used to check the integrity of the data. However, these methods do not support determining the authorship of a document.
6. Replay protection occurs cryptographic functions electronic signature for encryption or imitation protection. At the same time, a unique identifier is added to each network session, long enough to exclude its accidental coincidence, and validation is implemented by the receiving party.
7. Protection against imposition, that is, from penetration into communication from outside, is provided by means of electronic signature.
8. Other protection - against bookmarks, viruses, modifications operating system etc. - provided through various cryptographic tools, security protocols, anti-virus software and organizational measures.

As you can see, electronic signature algorithms are a fundamental part of the means of cryptographic information protection. They will be discussed below.

Requirements when using CIPF

CIPF is aimed at protecting (by verifying an electronic signature) open data in various public information systems and ensuring their confidentiality (by verifying an electronic signature, imitation protection, encryption, hash verification) in corporate networks.

A personal means of cryptographic information protection is used to protect the user's personal data. However, special attention should be given to information relating to state secrets. By law, CIPF cannot be used to work with it.

Important: before installing the CIPF, the first step is to check the CIPF software package itself. This is the first step. Typically, the integrity of the installation package is verified by comparing checksums received from the manufacturer.

After installation, you should determine the level of threat, on the basis of which you can determine the types of cryptographic information protection necessary for use: software, hardware and hardware-software. It should also be borne in mind that when organizing some CIPF, it is necessary to take into account the location of the system.

Protection classes

According to the order of the FSB of Russia dated July 10, 2014, number 378, which regulates the use of cryptographic means of protecting information and personal data, six classes are defined: KS1, KS2, KS3, KB1, KB2, KA1. The protection class for a particular system is determined from the analysis of data on the model of the intruder, that is, from the assessment possible ways system hacking. Protection in this case is built from software and hardware cryptographic information protection.

AC (actual threats), as can be seen from the table, there are 3 types:

1. Threats of the first type are associated with undocumented features in the system software used in information system.
2. Threats of the second type are associated with undocumented features in the application software used in the information system.
3. The threat of the third type is called all the rest.

Undocumented features are functions and features of the software that are not described in the official documentation or do not correspond to it. That is, their use may increase the risk of violating the confidentiality or integrity of information.

For clarity, consider the models of violators, for the interception of which one or another class of cryptographic information protection tools is needed:

• KS1 - the intruder acts from the outside, without helpers inside the system.
• KS2 is an insider, but does not have access to the CIPF.
• KS3 is an insider who is a user of the CIPF.
• KV1 - an intruder who attracts third party resources, such as CIPF specialists.
• KV2 is an intruder behind whose actions is an institute or laboratory working in the field of studying and developing cryptographic information protection tools.
• KA1 - special services of states.

Thus, KS1 can be called the basic protection class. Accordingly, the higher the protection class, the fewer specialists capable of providing it. For example, in Russia, according to data for 2013, there were only 6 organizations that had a certificate from the FSB and were able to provide class KA1 protection.

Used algorithms

Consider the main algorithms used in cryptographic information protection tools:

• GOST R 34.10-2001 and updated GOST R 34.10-2012 - algorithms for creating and verifying an electronic signature.
• GOST R 34.11-94 and latest GOST R 34.11-2012 - algorithms for creating hash functions.
• GOST 28147-89 and newer GOST R 34.12-2015 - implementation of data encryption and imitation protection algorithms.
• Additional cryptographic algorithms are in RFC 4357.

Electronic signature

The use of cryptographic information protection tools cannot be imagined without the use of electronic signature algorithms, which are gaining more and more popularity.

An electronic signature is a special part of a document created by cryptographic transformations. Its main task is to detect unauthorized changes and determine authorship.

An electronic signature certificate is a separate document that proves the authenticity and ownership of an electronic signature by its owner using a public key. The certificate is issued by certification authorities.

The owner of the electronic signature certificate is the person in whose name the certificate is registered. It is associated with two keys: public and private. The private key allows you to create an electronic signature. The public key is intended to verify the authenticity of the signature due to the cryptographic relationship with the private key.

Types of electronic signature

According to Federal Law No. 63, an electronic signature is divided into 3 types:

• regular electronic signature;
• unqualified electronic signature;
• qualified electronic signature.

A simple ES is created using passwords imposed on opening and viewing data, or similar means that indirectly confirm the owner.

An unqualified ES is created using cryptographic data transformations using a private key. This allows you to confirm the person who signed the document and to establish the fact that unauthorized changes have been made to the data.

Qualified and unqualified signatures differ only in that in the first case, the certificate for the ES must be issued by a certification center certified by the FSB.

Scope of electronic signature

The table below discusses the scope of EP.

ES technologies are most actively used in the exchange of documents. In the internal workflow, the ES acts as an approval of documents, that is, as a personal signature or seal. In the case of external document management, the presence of an ES is critical, as it is a legal confirmation. It is also worth noting that documents signed by ES can be stored indefinitely and not lose their legal significance due to factors such as erasable signatures, damaged paper, etc.

Reporting to regulatory authorities is another area in which electronic document management is growing. Many companies and organizations have already appreciated the convenience of working in this format.

According to the law of the Russian Federation, every citizen has the right to use ES when using public services (for example, signing an electronic application for authorities).

Online trading is another interesting area in which electronic signature is actively used. It is a confirmation of the fact that a real person is participating in the auction and his proposals can be considered reliable. It is also important that any contract concluded with the help of ES acquires legal force.

Electronic signature algorithms

• Full Domain Hash (FDH) and Public Key Cryptography Standards (PKCS). The latter is a whole group of standard algorithms for various situations.
• DSA and ECDSA are US digital signature standards.
• GOST R 34.10-2012 - the standard for creating electronic signatures in the Russian Federation. This standard replaced GOST R 34.10-2001, which was officially terminated after December 31, 2017.
• The Eurasian Union uses standards that are completely similar to those in Russia.
• STB 34.101.45-2013 - Belarusian standard for digital electronic signature.
• DSTU 4145-2002 - the standard for creating an electronic signature in Ukraine and many others.

It should also be noted that the algorithms for creating ES have various appointments and goals:

• Group electronic signature.
• Disposable digital signature.
• Trusted EP.
• Qualified and unqualified signature, etc.

In accordance with Part 5 of Article 8 of the Federal Law of April 6, 2011 N 63-FZ "On Electronic Signature" 1 order approve:

Requirements for electronic signature means (Appendix N 1);
Requirements for the means of a certification center (Appendix No. 2).

Director A. Bortnikov

1 Collection of Legislation of the Russian Federation, 2011, N 15, art. 2036; No. 27, art. 3880.

Requirements for electronic signature tools

I. General provisions

3) ES key - a unique sequence of characters designed to create an ES;

4) ES verification key - a unique sequence of characters uniquely associated with the ES key and intended for ES authentication (hereinafter referred to as ES verification);

5) ES tools - encryption (cryptographic) tools used to implement at least one of following functions- creation of an ES, verification of an ES, creation of an ES key and an ES verification key;

6) ES verification key certificate - an electronic document or a paper document issued by a CA or an authorized representative of the CA and confirming that the ES verification key belongs to the owner of the ES verification key certificate.

3. These Requirements establish the structure and content of the requirements for ES tools.

4. These Requirements are intended for customers and developers of the developed (upgraded) ES tools in their interaction with each other, with organizations conducting cryptographic, engineering-cryptographic and special studies of ES tools, the Federal Security Service of Russia, which confirms the compliance of ES tools with these Requirements.

5. These Requirements apply to ES funds intended for use on the territory of the Russian Federation, in institutions of the Russian Federation abroad and in separate subdivisions of legal entities located abroad, formed in accordance with the legislation of the Russian Federation.

6. EP tools in terms of their development, production, sale and operation are subject to requirements fixed by the Regulation on the development, production, sale and operation of encryption (cryptographic) information security tools (Regulation PKZ-2005), approved by order of the Federal Security Service of Russia dated February 9, 2005 No. 66 1 (as amended by order of the Federal Security Service of Russia dated April 12, 2010 No. 173 2) for encryption (cryptographic) means of protecting information with limited access that does not contain information constituting a state secret.

7. Requirements for technologies for creating (forming) and verifying ES using the ES tool are indicated in the tactical terms of reference or terms of reference for carrying out development work or an integral part of development work for the development (modernization) of the ES tool (hereinafter referred to as the TOR for the development (modernization) of the ES tool).

II. Requirements for EP tools

8. When creating an ES, the ES tools must:

Show the person signing the electronic document the content of the information he signs3;
- create ES only after the person signing the electronic document confirms the operation to create ES3;
- unequivocally show that the ES is created 3 .

9. When checking the ES, the ES tools must:

Show the contents of an electronic document signed by ES 3 ;
- show information about making changes to the signed ES electronic document 3 ;
- indicate the person using the ES key of which electronic documents were signed 3 .

10. The requirements of paragraphs 8 and 9 of these Requirements do not apply to ES tools used for automatic creation and (or) automatic check EP in the information system.
11. The ES tool must counter threats, which are targeted actions using hardware and (or) software to violate the security of information protected by the ES tool or to create conditions for this (hereinafter referred to as the attack).

12. Depending on the ability to resist attacks, ES means are divided into classes 4 .
13. ES class KS1 means resist attacks, when creating methods, preparing and carrying out which the following features are used:
13.1. Independent implementation of creating methods of attacks, preparing and conducting attacks.
13.2. Actions at various stages of the life cycle of the ES tool 5 .
13.3. Carrying out an attack only from outside the space within which control over the stay and actions of persons and (or) vehicles is carried out (hereinafter referred to as controlled zone 6).

13.4. Carrying out the following attacks at the stages of development, production, storage, transportation of ES tools and the stage of commissioning of ES tools (commissioning works):

Making unauthorized changes to the ES tool and (or) to the components of the SF, including with the use of malicious programs;
- making unauthorized changes to the documentation for the ES tool and the SF components.

13.5. Carrying out attacks on the following objects:

Documentation for the ES tool and for the SF components;

- key, authenticating and password information of the ES tool;
- ES tool and its software and hardware components;
- hardware included in the SF, including microcircuits with a recorded BIOS microcode that initializes these tools (hereinafter referred to as the hardware components of the SF);
- software components of the Federation Council;

- premises in which there is a set of software and technical elements of data processing systems capable of functioning independently or as part of other systems (hereinafter referred to as CVT) on which ES and SF tools are implemented;
- other objects of attacks, which, if necessary, are indicated in the TOR for the development (modernization) of the ES tool, taking into account the information technologies used in the information system, hardware (hereinafter referred to as AS) and software (hereinafter referred to as software).

13.6. Getting the following information:

General information about the information system in which the ES tool is used (purpose, composition, operator, objects in which the resources of the information system are located);
- information about information technology, databases, AS, software used in the information system together with the ES tool;
- information about the physical protection measures of the objects in which the ES means are located;
- information on measures to ensure the controlled area of ​​the objects of the information system in which the ES tool is used;
- information on measures to restrict access to the premises where the computer equipment is located, on which the means of ES and SF are implemented;
- the content of the freely available documentation for the hardware and software components of the ES and SF means;
- general information about the protected information used during the operation of the ES tool;

- information about the communication lines through which the information protected by the ES is transmitted;
- information about all violations of the rules for operating the ES and SF means that appear in communication channels that are not protected from unauthorized access to information by organizational and technical measures;
- information about all manifested in communication channels that are not protected from UA to information by organizational and technical measures, malfunctions and failures of the hardware components of the ES and SF means;
- information obtained as a result of the analysis of any signals from the hardware components of the ES and SF means, which can be intercepted by the intruder.

13.7. Usage:

Freely available or used outside the controlled area AS and software, including hardware and software components of the ES and SF;

13.8. Use as a transfer medium from the subject to the object (from the object to the subject) of the attack of the actions carried out during the preparation and (or) conduct of the attack (hereinafter referred to as the attack channel):

Communication channels not protected from unauthorized access to information by organizational and technical measures (both outside the controlled zone and within it), through which information protected by the ES is transmitted;
- distribution channels of signals accompanying the operation of the ES and SF means.

13.9. Carrying out an attack from information and telecommunication networks, access to which is not limited to a certain circle of people.

13.10. The use of AS and software from the information system tools used at the places of operation of the ES tool (hereinafter referred to as standard tools) and located outside the controlled area.

14. ES class KS2 means resist attacks, when creating methods, preparing and carrying out which, the capabilities listed in subparagraphs 13.1 - 13.10 of these Requirements are used, and the following additional features:

14.1. Carrying out an attack while both out of bounds and within the controlled zone.

14.2. The use of regular means, limited by measures implemented in the information system in which the ES tool is used, and aimed at preventing and suppressing unauthorized actions.

15. ES class KS3 means resist attacks, when creating methods, preparing and carrying out which, the capabilities listed in subparagraphs 13.1 - 13.10, 14.1, 14.2 of these Requirements are used, and the following additional features:

15.1. Access to SVT, on which the means of ES and SF are implemented.

15.2. Possibility to have the hardware components of the ES and SF tool in the amount depending on the measures aimed at preventing and suppressing unauthorized actions implemented in the information system in which the ES tool is used.

16. KV1 class ES means resist attacks, when creating methods, preparing and carrying out which, the capabilities listed in subparagraphs 13.1 - 13.10, 14.1, 14.2, 15.1, 15.2 of these Requirements are used, and the following additional features:

16.1. Creation of attack methods, preparation and implementation of attacks with the involvement of specialists with experience in the development and analysis of ES tools, including specialists in the field of signal analysis accompanying the operation of ES and SF tools.

16.2. Conducting laboratory studies of the ES tool used outside the controlled area, to the extent depending on the measures aimed at preventing and suppressing unauthorized actions implemented in the information system in which the ES tool is used.

17. KV2 class ES means resist attacks, when creating methods, preparing and carrying out which, the capabilities listed in subparagraphs 13.1 - 13.10, 14.1, 14.2, 15.1, 15.2, 16.1, 16.2 of these Requirements are used, and the following additional features:

17.1. Creation of methods of attacks, preparation and execution of attacks with the involvement of specialists with experience in the development and analysis of ES tools, including specialists in the field of using application software capabilities to implement attacks that are not described in the application software documentation.

17.2. Arrangement of work on the creation of methods and means of attacks in research centers specializing in the development and analysis of ES and SF tools.

17.3. The ability to have the source texts of the application software included in the SF.

18. EP class KA1 means resist attacks, when creating methods, preparing and carrying out which, the capabilities listed in subparagraphs 13.1 - 13.10, 14.1, 14.2, 15.1, 15.2, 16.1, 16.2, 17.1 - 17.3 of these Requirements are used, and the following additional features:

18.1. Creation of methods of attacks, preparation and execution of attacks with the involvement of specialists with experience in the development and analysis of ES tools, including specialists in the field of using system software capabilities to implement attacks that are not described in the system software documentation.

18.2. The ability to have all the documentation for hardware and software components of the SF.

18.3. The ability to have all the hardware components of the EP and SF.

19. If the ES tool implements the function of checking the ES of an electronic document using the ES verification key certificate, this implementation must exclude the possibility of checking the ES of an electronic document without checking the ES in the ES verification key certificate or without the presence of positive result ES verification in the ES verification key certificate.

20. When developing ES tools, cryptographic algorithms approved as state standards or having a positive opinion from the FSB of Russia based on the results of their expert cryptographic research 7 should be used.

21. Engineering and cryptographic protection of the ES means should exclude events leading to the possibility of carrying out successful attacks in conditions possible faults or failures of the hardware component of the ES tool or the hardware component of the CVT, on which the ES software tool is implemented.

22. In the ES tool, only the algorithms for the functioning of the ES tool specified in the ToR for the development (modernization) of the ES tool should be implemented.

23. The software component of the ES tool (if there is a software component of the ES tool) must meet the following requirements:

The object (boot) code of the software component of the ES tool must correspond to its source text;
- in the software component of the ES tool, only the functions of the software environment described in the documentation in which the ES tool operates should be used when implementing;
- in the source texts of the software component of the ES tool, there should be no possibility that allows modifying or distorting the algorithm of the ES tool in the process of using it, modifying or distorting information or control flows and processes associated with the operation of the ES tool, and gaining access to violators of the information stored in the clear key, identification and (or) authenticating information of the ES tool;
- values ​​of input and internal parameters, as well as the values ​​of the settings of the software component of the ES tool should not adversely affect its operation.

24. In the case of planning the placement of ES means in rooms where there is speech acoustic and visual information containing information constituting a state secret, and (or) installed speakers and systems for receiving, transmitting, processing, storing and displaying information containing information constituting state secret, foreign-made AS, which are part of the ES means, must be subjected to checks to identify devices intended for secretly obtaining information.

In the case of planning the placement of ES means in rooms where there is no speech acoustic and visual information containing information constituting a state secret, and no AS and systems for receiving, transmitting, processing, storing and displaying information containing information constituting a state secret are installed:

The decision to conduct inspections of foreign-made nuclear power plants that are part of the ES equipment of classes KS1, KS2, KS3, KB1 and KB2 is made by the organization that ensures the operation of these ES equipment;
- checks of foreign-made AS, which are part of the means of ES class KA1, are carried out without fail.

25. The ES tool must authenticate the subjects of access (persons, processes) to this tool, while:

When accessing the ES tool, the authentication of the access subject must be carried out before the execution of the first functional module of the ES tool;
- authentication mechanisms should block the access of these subjects to the functions of the ES tool in case of a negative authentication result.

26. The ES tool must authenticate persons providing local access to the ES tool.

27. The need for the ES tool to authenticate processes that provide local or remote (network) access to the ES tool is indicated in the TOR for the development (upgrade) of the ES tool.

28. For any authentication mechanism included in the ES tool, a mechanism must be implemented to limit the number of successive authentication attempts of one access subject, the number of which should not exceed 10. If the number of successive authentication attempts of one access subject exceeds the established limit value, access of this subject to the The ES must be blocked for the period of time specified in the ToR for the development (modernization) of the ES means.

29. In the ES tool, a mechanism (procedure) for monitoring the integrity of the ES tool and SF must be implemented.

Integrity control can be carried out:

At the beginning of work with the ES tool before the transition of the SVT, in which the ES tool is implemented, to the working state (for example, before loading the SVT operating system);
- in the course of routine checks of the ES equipment at the places of operation (regulatory control);
- in automatic mode during the operation of the ES means (dynamic control).

Integrity control should be carried out at the beginning of work with the ES tool.

The mechanism of routine integrity control should be part of the ES tools.

30. For ES tools of classes KS1 and KS2, the need to present requirements for access control and memory cleaning, as well as their content, is indicated in the TOR for the development (modernization) of the ES tool.

31. The composition of the ES of classes KS3, KB1, KB2 and KA1 or SF should include components that provide:

Managing access of subjects to various components and (or) target functions of the ES tool and SF based on the parameters set by the administrator or manufacturer of the ES tool (requirements for the specified component are determined and justified by the organization conducting research of the ES tool in order to assess the compliance of the ES tool with these Requirements);
- cleaning operational and external memory used by the ES tool for storing protected information when freeing (redistributing) memory by writing masking information (random or pseudo-random sequence of characters) into memory.

32. The composition of ES tools of classes KV2 and KA1 or SF should include components that provide emergency deletion of protected information of limited access. The requirements for the implementation and reliability of deletion are specified in the TOR for the development (modernization) of the ES tool.

33. For ES tools of classes KS1 and KS2, the need to present requirements for registering events and their content are indicated in the TOR for the development (modernization) of ES tools.

34. The composition of the ES tools of classes KSZ, KV1, KB2 and KA1 should include a module that records in the electronic log of events in the ES and SF tools related to the performance of the ES tools of their target functions.

Requirements to specified module and the list of recorded events are determined and substantiated by the organization conducting research of the ES tool in order to assess the compliance of the ES tool with these Requirements.

35. The event log should be available only to persons specified by the operator of the information system in which the ES tool is used, or persons authorized by him. In this case, the event log should be accessed only for viewing records and for moving the contents of the event log to archive media.

36. The validity period of the ES verification key must not exceed the validity period of the ES key by more than 15 years.

37. The requirements for the mechanism for monitoring the period of use of the ES key, blocking the operation of the ES tool in the event of an attempt to use the key longer than the specified period, are determined by the developer of the ES tool and justified by the organization conducting research of the ES tool in order to assess the compliance of the ES tool with these Requirements.

38. Cryptographic protocols that provide operations with key information of the ES tool must be implemented directly in the ES tool.

39. Studies of ES tools in order to assess the compliance of ES tools with these Requirements should be carried out using the numerical values ​​​​of the parameters and characteristics of the protection mechanisms implemented in the ES tools and hardware and software components of the SF 8 developed by the FSB of Russia.

1 Registered by the Russian Ministry of Justice on March 3, 2005, registration number 6382.

3 It is implemented, inter alia, using hardware and software tools, in conjunction with which the ES tools function normally and which can affect the fulfillment of the requirements for ES tools, which together represent the environment for the operation of ES tools (hereinafter - SF).
4 The required class of the developed (upgraded) ES tool is determined by the customer (developer) of the ES tool by determining the possibilities to create attack methods, prepare and conduct attacks based on paragraphs 13 - 18 of these Requirements and is indicated in T3 for the development (upgrade) of the ES tool.
5 The stages of the life cycle of the ES means include the development (modernization) of these tools, their production, storage, transportation, commissioning (commissioning), operation.
6 The boundary of the controlled zone may be: the perimeter of the protected territory of the enterprise (institution), the enclosing structures of the protected building, the protected part of the building, the allocated premises.
7 Subparagraph 25 of paragraph 9 of the Regulations on Federal Service security of the Russian Federation, approved by Decree of the President of the Russian Federation of August 11, 2003 No. 960 (Sobraniye Zakonodatelstva Rossiyskoy Federatsii, 2003, No. 33, Art. 3254; 2004, No. 28, Art. 2883; 2005, No. 36, Art. 3665; No. 49, article 5200; 2006, No. 25, article 2699; No. 31 (part I), article 3463; 2007, No. 1 (part I), article 205; No. 49, article 6133; No. 53, Article 6554; 2008, No. 36, Article 4087; No. 43, Article 4921; No. 47, Article 5431; 2010, No. 17, Article 2054; No. 20, Article 2435; 2011, No. 2, article 267; No. 9, article 1222) (hereinafter - the Regulations on the FSB of Russia).
8 Subparagraph 47 of paragraph 9 of the Regulations on the FSB of Russia.

Appendix No. 2

Requirements for certification authority tools

I. General provisions

1. These Requirements have been developed in accordance with federal law dated April 6, 2011 N 63-FZ "On Electronic Signature" (hereinafter referred to as the Federal Law).

2. These Requirements use the following basic concepts defined in Article 2 of the Federal Law:

1) electronic signature (hereinafter - ES) - information in electronic form, which is attached to other information in electronic form (signed information) or is otherwise associated with such information and which is used to identify the person signing the information;

3) ES tools - encryption (cryptographic) tools used to implement at least one of the following functions - creating an ES, checking an ES, creating an ES key and an ES verification key;

4) ES key - a unique sequence of characters designed to create an ES;

5) ES verification key - a unique sequence of characters uniquely associated with the ES key and intended for ES authentication (hereinafter referred to as ES verification);

6) ES verification key certificate - an electronic document or a paper document issued by a CA or an authorized representative of the CA and confirming that the ES verification key belongs to the owner of the ES verification key certificate;

7) a qualified ES verification key certificate (hereinafter referred to as a qualified certificate) - an ES verification key certificate issued by an accredited CA or an authorized representative of an accredited CA or a federal executive body authorized in the field of ES use (hereinafter referred to as an authorized federal body);

8) the owner of the ES verification key certificate - a person who, in accordance with the procedure established by the Federal Law, has been issued an ES verification key certificate;

9) accreditation of the CA - recognition by the authorized federal body of the compliance of the CA with the requirements of the Federal Law;

10) CA facilities - hardware and (or) software used to implement the functions of the CA;

11) participants in electronic interaction - state bodies, local government bodies, organizations, as well as citizens exchanging information in electronic form.

3. These Requirements establish the structure and content of the requirements for CA tools.

4. These Requirements are intended for customers and developers of the developed (upgraded) CA tools in their interaction with each other, with organizations conducting cryptographic, engineering-cryptographic and special studies of CA tools, the Federal Security Service of Russia, which confirms the compliance of CA tools with these Requirements.

5. These Requirements apply to CA funds intended for use on the territory of the Russian Federation.

6. The CA tools in terms of their development, production, sale and operation are subject to requirements fixed by the Regulations on the development, production, sale and operation of encryption (cryptographic) information security tools (Regulation PKZ-2005), approved by order of the Federal Security Service of Russia dated February 9, 2005 No. 66 1 (as amended by Order No. 173 2 of the FSB of Russia dated April 12, 2010), for encryption (cryptographic) means of protecting information (hereinafter referred to as CIPF) with limited access that does not contain information constituting a state secret.

II. Requirements for CA funds

7. CA tools must counter threats, which are targeted actions using hardware and (or) software tools in order to violate the engineering, technical and cryptographic security of CA tools or to create conditions for this (hereinafter referred to as the attack).

8. Depending on the ability to withstand attacks, CA tools are divided into classes 3 .

9. Tools of the CA class KS1 resist attacks, when creating methods, preparing and carrying out which the following features are used:

9.1. Preparation and conduct of attacks from outside the space within which the stay and actions of persons and (or) vehicles are monitored (hereinafter referred to as the controlled zone).
9.2. Preparing and conducting attacks without access to functionality software and hardware for interaction with the CA.

9.3. Independent implementation of creating methods of attacks, preparing and conducting attacks on the following objects:

Documentation for CA funds;
- protected electronic documents;
- key, authentication and password information;
- CA tools, their software and hardware components;
- data transmitted over communication channels;
- premises in which the hardware (hereinafter referred to as the AS) is located, on which the CA tools are implemented, as well as other protected resources of the information system.

9.4. Introduction at the stages of development, production, storage, transportation and commissioning of CA tools:

Negative functionality in the CA tools, including the use of malware;
- unauthorized changes to the documentation for CA funds.

9.5. Getting the following information:

General information about the information system in which the CA tools are used (purpose, composition, objects in which the resources of the information system are located);
- information about information technologies, databases, AS, software (hereinafter referred to as software) used in the information system together with CA tools;
- information about the physical protection measures of the facilities in which the CA facilities are located;
- information on measures to ensure the protection of the controlled zone of information system objects in which CA tools are used;
- information on measures to restrict access to the premises where CA facilities are located;
- content of freely available technical documentation for CA funds;
- information about the protected information used during the operation of the CA facilities (types of protected information: service information, password and authentication information, configuration information, control information, information in electronic registration logs; general information on the content of each type of protected information; security characteristics for each type of protected information);
- all possible data transmitted in open form via communication channels that are not protected from unauthorized access (hereinafter referred to as UA) to information by organizational and technical measures;
- information about the communication lines through which the information protected using the means of the CA is transmitted;
- information about all violations of the rules for the operation of CA facilities that appear in communication channels that are not protected from unauthorized access to information by organizational and technical measures;
- information about all manifested in communication channels that are not protected from unauthorized access to information by organizational and technical measures, malfunctions and failures of CA facilities;
- information obtained as a result of the analysis of any signals available for interception from the hardware components of the CA.

9.6. Usage:

Freely available or outside the controlled area of ​​AS and software, including software and hardware components of the CA;
- specially designed AS and software.

9.7. The use as attack channels of communication channels that are not protected from unauthorized access to information by organizational and technical measures (both outside the controlled zone and within it), through which information is transmitted, processed by means of the CA.

10. Tools of the CA class KS2 resist attacks, when creating methods, preparing and carrying out which the following features are used:

10.1. The possibilities listed in subparagraphs 9.3 - 9.7 of these Requirements.

10.2. Preparation and execution of attacks from the controlled zone.

10.3. Preparation and execution of attacks without using access to the AS on which CA tools are implemented.

10.4. Use of regular information system tools that use CA tools.

11. Tools of the CA of the KSZ class resist attacks, when creating methods, preparing and carrying out which the following features are used:

11.1. Opportunities listed in subparagraphs 10.1, 10.4 of these Requirements.

11.2. Preparation and execution of attacks from outside the controlled area using access to the functionality of the software and hardware tools for interaction with the CA based on the legal possession of authenticating information, or preparation and execution of attacks from the controlled area using access to the AS on which the CA components are implemented, with the rights of a person who is not a member of the group individuals authorized to install, configure and operate CA tools, configure the profile and parameters of the audit log (system administrator functions), archive, backup and restore information after failures (operator functions), create and revoke certificates of ES verification keys (certification administrator functions), viewing and maintaining the audit log (audit administrator functions) (hereinafter referred to as the CA tools administrator group) of any of the CA components.

11.3. Possession of AS CA in the amount depending on the implemented measures aimed at preventing and suppressing unauthorized actions.

12. CA class KV1 facilities resist attacks, when creating methods, preparing and carrying out which the following features are used:

12.1. The possibilities listed in subparagraphs 11.1 - 11.3 of these Requirements.

12.2. Implementation of the creation of methods and preparation of attacks with the involvement of specialists with experience in the development and analysis of the CIPF of the CA (including specialists in the field of analysis of linear transmission signals and side signals electromagnetic radiation and pickups of CIPF UTs).

12.3. Conducting laboratory studies of CA tools used outside the controlled area to the extent that depends on the implemented measures aimed at preventing and suppressing unauthorized actions.

13. CA class KV2 facilities resist attacks, when creating methods, preparing and carrying out which the following features are used:

13.1. The possibilities listed in subparagraphs 12.1 - 12.3 of these Requirements.

13.2. Implementation of the creation of methods and preparation of attacks with the involvement of specialists in the field of use for the implementation of attacks of undeclared capabilities of application and system software.

13.3. Arrangement of work on the creation of methods and means of attacks in research centers specializing in the development and analysis of CA tools.

13.4. Possession of the source texts of the application software used in the information system in which the CA tools are used, and the documentation that is in the public domain.

14. CA class KA1 tools resist attacks, when creating methods, preparing and carrying out which the following features are used:

14.1. The possibilities listed in subparagraphs 13.1 - 13.4 of these Requirements.

14.2. Implementation of the creation of methods and preparation of attacks with the involvement of research centers specializing in the development and analysis of cryptographic information protection and in the field of using undeclared capabilities of application and system software to implement attacks.

14.3. Possession of all documentation for the hardware and software components of the CA.

14.4. Possession of all hardware components of the CA.

15. The CA facilities must be operated in accordance with the operational documentation for the CA facilities. A set of organizational and technical measures to ensure the safe operation of the CA facilities must be indicated in the operational documentation for the CA facilities.

16. The class of ES tools used in CA tools must not be lower than the corresponding class of CA tools. The class of ES tools used in the CA tools must be specified in the operational documentation for the CA tools.

The class of CIPF used in the CA tools must not be lower than the corresponding class of the CA tools. The class of cryptographic information protection used in CA facilities must be indicated in the operational documentation for CA facilities.

17. Each requirement for CA facilities of any class other than CA1 is either imposed on CA facilities of the next class without changes (in this case, it is not indicated in the list of requirements for CA facilities of the next class), or is tightened (in this case, in the list of requirements for means of the CA of the next class, a tougher wording is given). Requirements for CA facilities of the next class may include Additional requirements, which are not included in the requirements for the CA facilities of the previous class.

18. Requirements for software of CA tools:

18.1. Requirements for CA class KS1 facilities:

The software of the CA tools should not contain tools that allow modifying or distorting the operation algorithm of the software tools and AS of the CA.

18.2. Requirements for CA class KS2:

The application software of the CA and CIPF tools used in the CA must use only the documented functions of the system software.

18.3. Requirements for CA class KS3 facilities:

The system and application software of the CA tools must provide access control for the system administrator of the CA tools, the administrator for certification of the CA tools and persons provided system administrator CA tools with identifying and authenticating information and not being the certification administrator of CA tools (hereinafter referred to as users of CA tools), to information processed by CA tools, based on the access control rules set by the system administrator of CA tools;
- system and application software of the CA tools must correspond to the 4th level of control of the absence of undeclared capabilities;
- system and application software of the CA tools should not contain known vulnerabilities published in public sources;
- the structure of the system and (or) application software of the CA tools should include a mechanism that ensures the cleaning of the RAM and external memory used to store information of limited access.

18.4. The requirements for CA facilities of class KB1 coincide with the requirements for CA facilities of class KS3.

18.5. Requirements for CA class KV2:

The source texts of the system and application software of the CA tools must be checked for the implementation in them of methods and means of protecting information that resists attacks, for the preparation and implementation of which the capabilities listed in paragraphs 9 - 13 of these Requirements are used;
- the source texts of the system and application software must be checked for the absence of undeclared features;
- system and application software must be resistant to computer attacks from external networks.

18.6. Requirements for CA class KA1:

The source texts of the system and application software of the CA tools must undergo a formal verification of the implementation in them of methods and means of protecting information that resists attacks, for the preparation and implementation of which the capabilities listed in paragraphs 9-14 of these Requirements are used, as well as the absence of undeclared capabilities in them.

19. Requirements for AS CA:

19.1. In the case of planning the placement of AS CA in rooms where there is speech acoustic and visual information containing information constituting a state secret, and (or) technical means and systems for receiving, transmitting, processing, storing and displaying information containing information constituting a state secret are installed secrecy, foreign-made technical means that are part of the CA tools must be subjected to checks to identify devices intended for secretly obtaining information, as well as to studies for compliance with the requirements for protection against information leakage through the channels of spurious electromagnetic radiation and interference in accordance with the category of allocated premises.

19.2. Requirements for CA class KS1 facilities:

Compliance with the implementation of the target functions of the CA is checked on the basis of a system of tests of the CA AS.

19.3. The requirements for CA facilities of classes KS2, KS3, KB1, KB2 coincide with the requirements for CA facilities of class KS1.

19.4. Requirements for CA class KA1:

Carrying out a special inspection of foreign-made technical means that are part of the AS CA, in order to identify devices intended for secretly obtaining information;
- carrying out a full verification of the AS (together with the analysis of the BIOS program code), on which the CA tools are implemented, in order to exclude negative functionality.

20. Requirements for role differentiation:

20.1. To ensure the performance of CA functions, CA tools must support the role differentiation of members of the CA tools administrators group.

20.2. Requirements for CA class KS1 facilities:

A list of roles and distribution of responsibilities between roles should be defined;
- the list of roles and the distribution of responsibilities between the roles should be specified in the operational documentation for the CA facilities.

20.3. The requirements for CA facilities of class CS2 are the same as those for CA facilities of class CA1.

20.4. Requirements for CA class KS3 facilities:

CA tools must support the following mandatory roles:

1) a system administrator with the main responsibilities of installing, configuring and maintaining the operation of CA tools, creating and maintaining profiles for members of the CA tools administrators group, configuring the profile and audit log parameters;

2) certification administrator with the main responsibilities: creation and cancellation of certificates of ES verification keys;

The CA tools must implement a mechanism that excludes the possibility of authorizing one member of the CA tools administrators group to perform various roles.

20.5. Requirements for CA class KB1:

The CA facilities should provide a mandatory operator role with primary backup and recovery responsibilities.

20.6. The requirements for CA facilities of class KB2 are the same as those for CA facilities of class KB1.

20.7. Requirements for CA class KA1:

The CA tools should provide the mandatory role of the audit administrator with the main responsibilities: viewing and maintaining the audit log;
- the system administrator should not be able to make changes to the audit log.

21. Requirements for the integrity of CA tools:

21.1. The CA tools must contain a mechanism for controlling unauthorized accidental and (or) deliberate distortion (change, modification) and (or) destruction of information, software and AS of the CA (hereinafter - the integrity control mechanism).

21.2. Requirements for CA class KS1 facilities:

The requirements for the integrity control mechanism should be specified in the TOR for the development (modernization) of CA tools;
- the period of control of the integrity of software tools and AS of the CA must be determined and indicated in the operational documentation for the CA tools;
- control of the integrity of software and AS CA should be performed every time the operating system (hereinafter referred to as OS) is rebooted;
- there must be means of restoring the integrity of the CA facilities.

21.3. The requirements for CA facilities of class CS2 are the same as those for CA facilities of class CA1.

21.4. Requirements for CA class KS3 facilities:
- Integrity control should be performed at least once a day.

21.5. Requirements for CA class KB1:
- Integrity control must be performed before the CA tools are loaded by the OS.

21.6. The requirements for CA facilities of class KB2 are the same as those for CA facilities of class KB1.

21.7. Requirements for CA class KA1:
- integrity control should be carried out dynamically during the functioning of the CA facilities.

22. Access control requirements:

22.1. CA facilities must provide access control.

22.2. Requirements for CA class KS1 facilities:
- requirements for access control should be defined and specified in the TOR for the development (modernization) of CA facilities.

22.3. The requirements for CA facilities of class CS2 are the same as those for CA facilities of class CA1.

22.4. Requirements for CA class KS3 facilities:
- the discretionary principle of access control should be ensured in the CA.

22.5. The requirements for CA facilities of class KB1 coincide with the requirements for CA facilities of class KS3.

22.6. Requirements for CA class KV2:
- the creation of a closed working environment 4 of the CA facilities should be ensured.

22.7. Requirements for CA class KA1:
- the CA must ensure the mandatory principle of access control; to enter the ES key of the certification administrator, at least two trusted persons are required 5 .

23. Requirements for identification and authentication:

23.1. Identification and authentication includes recognizing a CA tools user, a member of the CA tools administrators group, or a process, and verifying their identity. The authentication mechanism should block the access of these entities to the functions of the CA if the authentication result is negative.

23.2. In the CA tools, for any implemented authentication procedure, a mechanism should be applied to limit the number of consecutive attempts to authenticate one access subject, the number of which should not exceed three. If the number of consecutive attempts to authenticate one access subject exceeds the established limit value, the access of this access subject to the CA facilities must be blocked for a period of time, which is indicated in the ToR for the development (modernization) of the CA facilities.

23.3. Requirements for CA class KS1 facilities:

A description of the procedure for registering users of CA tools (entering data into the register of users of CA tools) should be contained in the operational documentation for CA tools;
- all persons accessing the CA funds must be authenticated. At the same time, it is allowed to limit the use of only a symbolic periodically changing password of at least 8 characters for authentication with an alphabet capacity of at least 36 characters. The password change period should not exceed 6 months.

23.4. Requirements for CA class KS2:

The need for the user to present the CA funds during his registration of identity documents should be reflected in the operational documentation for the CA funds;
- for all users of CA facilities, the use of remote authentication mechanisms is allowed. Special characteristics of remote authentication mechanisms must be confirmed as part of the verification of the compliance of CA tools and informatization objects using these tools with these Requirements;
- when implementing local access to CA tools, authentication of members of the CA tools administrators group must be performed before these CA tools become operational (for example, before the base OS is loaded).

23.5. Requirements for CA class KS3 facilities:

Authentication mechanism must be implemented in CA tools local users who have access to CA tools but are not members of the CA tools administrators group.

23.6. Requirements for CA class KB1:

When implementing remote access only a symbolic password is not allowed for CA tools, authentication mechanisms based on cryptographic protocols must be used.

23.7. The requirements for CA facilities of class KB2 are the same as those for CA facilities of class KB1.

23.8. Requirements for CA class KA1:

In the CA tools for any implemented authentication mechanism, it must be possible to set the limit allowable amount successive attempts to authenticate one subject of access and set the blocking time for access to CA facilities at the places of their operation.

24. Requirements for the protection of data incoming (exported) to (from) the CA:

24.1. The CA tools must provide trusted input of a self-signed certificate of the ES verification key.

24.2. Requirements for CA class KS1 facilities:

CA facilities must ensure the transfer of data containing restricted access information received by the CA and exported from the CA in a way protected from unauthorized access;
- in the means of the CA, a procedure should be implemented to protect against the imposition of false messages 6 ;
- requirements for the procedure for protection against the imposition of false messages are indicated in the TOR for the development (modernization) of CA tools.

24.3. Requirements for CA class KS2:

The means of the CA must ensure the protection of the initial request for a certificate of the ES verification key;
- CA tools should accept information critical for the functioning of the CA only if it is signed by an ES.

24.4. Requirements for CA class KS3 facilities:

The CA tools must implement a mechanism to protect against the imposition of false messages based on the use of ES tools that have received confirmation of compliance with the requirements for ES tools.

24.5. Requirements for CA class KB1:

The CA tools must implement a data protection mechanism when transferring them between physically separated components based on the use of CIPF.

24.6. The requirements for CA facilities of classes KB2 and KA1 are the same as those for CA facilities of class KB1.

25. Requirements for event registration:

25.1. The underlying OS of the CA tools must support system event audit logging.

25.2. Requirements for CA class KS1 facilities:

The CA tools must implement a mechanism that selectively registers events in the audit log related to the performance of the CA of its functions;
- the list of recorded events should be contained in the operational documentation for the CA facilities.

25.3. The requirements for CA facilities of class CS2 are the same as those for CA facilities of class CA1.

25.4. Requirements for CA class KS3 facilities:

Measures shall be taken to detect unauthorized changes to the audit log by users of CA tools who are not members of the CA Tools Administrators group.

25.5. The requirements for CA facilities of class KB1 coincide with the requirements for CA facilities of class KS3.

25.6. Requirements for CA class KV2:

Measures must be taken to detect unauthorized changes to each entry in the audit log.

25.7. Requirements for CA class KA1:

The audit log should only be accessible by the audit administrator, who can only view, copy, and complete cleaning. After cleaning, the first entry in the audit log should automatically record the fact of cleaning, indicating the date, time and information about the person who performed the operation.

26. Requirements for the reliability and stability of the functioning of the CA facilities:

26.1. The requirements for the reliability and stability of the functioning of the CA facilities should be determined and specified in the TOR for the development (modernization) of the CA facilities.

26.2. Requirements for CA class KS1 facilities:

The calculation of the probability of failures and malfunctions of the CA AS, leading to the failure of the CA to perform its functions, is carried out.

26.3. Requirements for CA class KS2:

Testing of the stability of the functioning of the CA facilities should be carried out.

26.4. Requirements for CA class KS3 facilities:

The requirements for the recovery time of the CA funds after a failure should be determined and indicated in the TOR for the development (modernization) of the CA facilities;

Measures and means of increasing the reliability and stability of the functioning of the CA funds should contain mechanisms for quoting the resources of the CA funds.

26.5. Requirements for CA class KB1:

The probability of failures and malfunctions of the AS CA, leading to the failure of the CA to perform its functions, during the day should not exceed the same probability for the used CIPF.

26.6. The requirements for CA facilities of classes KB2 and KA1 are the same as those for CA facilities of class KB1.

27. Requirements for key information:

27.1. The procedure for the creation, use, storage and destruction of key information is determined in accordance with the requirements of the operational documentation for ES and other CIPF used by the CA.

27.2. The validity period of the ES key of the ES tool used by the CA tools must comply with the requirements established for the ES tools.

27.3. Requirements for CA class KS1 facilities:

It is not allowed to copy the information of key documents (cryptographic keys, including ES keys) to media (for example, HDD) that are not key bearers, without its preliminary encryption (which should be carried out by the built-in function of the used CIPF). Copying of key documents should be carried out only in accordance with the operational documentation for the used CIPF;

ES keys used to sign certificates of ES verification keys and lists of unique numbers of ES verification keys certificates, the validity of which was terminated at a certain moment by the CA before their expiration (hereinafter referred to as the list of revoked certificates), should not be used for any other purposes;

The validity periods of all keys must be indicated in the operational documentation for the CA facilities.

27.4. The requirements for CA facilities of classes KS2 and KS3 coincide with the requirements for CA facilities of class KS1.

27.5. Requirements for CA class KB1:

Organizational and technical measures should be taken to exclude the possibility of compromising the ES key used to sign certificates of ES verification keys and lists of revoked certificates in case of compromise of key information available to one person.

27.6. Requirements for CA class KV2:

The ES key used to sign certificates of ES verification keys and lists of revoked certificates must be generated, stored, used and destroyed in the ES tool. It is allowed to use only ES tools that have received confirmation of compliance with the requirements for ES tools in accordance with the Federal Law;
- organizational and technical measures should be taken to exclude the possibility of compromising the ES key used to sign certificates of ES verification keys and lists of revoked certificates, when key information available to two persons is compromised.

27.7. Requirements for CA class KA1:

Organizational and technical measures should be taken to exclude the possibility of compromising the ES key used to sign certificates of ES verification keys and lists of revoked certificates, when key information available to three persons is compromised.

28. Requirements for backup and restoration of CA tools:

28.1. The CA tools must implement backup and recovery functions in case of damage to the AS and (or) information processed by the CA tools. During backup, the possibility of copying cryptographic keys should be excluded.

28.2. Requirements for CA class KS1 facilities:

Data saved when backup, should be sufficient to restore the functioning of the CA facilities to the state fixed at the time of copying.

28.3. The requirements for CA facilities of classes KS2 and KS3 coincide with the requirements for CA facilities of class KS1.

28.4. Requirements for CA class KB1:

Measures must be taken to detect unauthorized changes to stored data;
- requirements for recovery time should be determined and specified in the TOR for the development (modernization) of CA facilities and in the operational documentation for CA facilities.

28.5. Requirements for CA class KV2:

Protected information saved during backup should be stored only in encrypted form.

28.6. The requirements for CA class KA1 facilities are the same as those for CA class KB2 facilities.

29. Requirements for the creation and cancellation of certificates of ES verification keys:

29.1. The protocols for creating and revoking ES verification key certificates must be described in the operational documentation for the CA facilities.

29.2. The certificates of ES verification keys created by the CA and the lists of revoked certificates must comply with the international recommendations ITU-T X.509 7 (hereinafter referred to as recommendations X.509). All fields and additions included in the ES verification key certificate and the list of revoked certificates must be filled in in accordance with X.509 recommendations. When using alternative formats of ES verification keys certificates, the requirements for the protocols for creating and revoking ES verification keys certificates must be defined and specified in the ToR for the development (upgrading) of CA tools.

29.3. The CA tools must implement the ES verification key certificate revocation protocol using lists of revoked certificates.

29.4. It is allowed to implement revocation protocols without using lists of revoked certificates, the requirements for which must be specified in the TOR for the development (modernization) of CA tools.

29.5. Requirements for CA class KS1 facilities:

The CA tools must implement the function of producing an ES verification key certificate on paper. The procedure for issuing an ES verification key certificate on paper, as well as the procedure for monitoring the compliance of the ES verification key certificate in in electronic format and on paper must be indicated in the operational documentation for the CA facilities;

Mechanisms for checking the uniqueness of the ES verification key and the possession of the corresponding ES key must be implemented in the CA tools in relation to the owner of the ES verification key certificate.

29.6. The requirements for CA facilities of class CS2 are the same as those for CA facilities of class CA1.

29.7. Requirements for CA class KS3 facilities:

The error of time values ​​in certificates of ES verification keys and lists of revoked certificates should not exceed 10 minutes.

29.8. Requirements for CA class KB1:

The error of time values ​​in certificates of ES verification keys and lists of revoked certificates should not exceed 5 minutes.

29.9. The requirements for CA facilities of classes KB2 and CA1 are the same as the requirements for CA facilities of class KB 1.

30. Requirements for the structure of the ES verification key certificate and the list of revoked certificates:

30.1. Requirements for CA class KS1 facilities:

Valid structures of the certificate of the ES verification key and the list of revoked certificates must be listed in the operational documentation for the CA facilities;
- the CA tools should implement a mechanism for monitoring the compliance of the created certificates of the ES verification keys and the lists of revoked certificates with a given structure;
- the structure of the ES verification key certificate must contain a field containing information about the class of CA tools that were used to create this ES verification key certificate, and a field containing information about the class of the ES tool of the owner of the ES verification key certificate.

30.2. The requirements for CA facilities of classes KS2 and KS3 coincide with the requirements for CA facilities of class KS1.

30.3. Requirements for CA class KV1:

The CA tools must implement a mechanism for setting by the system administrator a set of valid additions to the certificate of the ES verification key and a list of revoked certificates.

30.4. The requirements for CA facilities of classes KB2 and KA1 are the same as those for CA facilities of class KB1.

31. Requirements for the register of certificates of ES verification keys and providing access to it:

31.1. Requirements for CA class KS1 facilities:

The CA tools must implement mechanisms for storing and searching for all created certificates of ES verification keys and lists of revoked certificates in the registry, as well as network access to the register.

31.2. The requirements for CA facilities of class CS2 are the same as those for CA facilities of class CA1.

31.3. Requirements for CA class KS3 facilities:

The CA tools must implement a mechanism for searching for certificates of ES verification keys and lists of revoked certificates in the register of certificates of ES verification keys by their various attributes;
- all changes in the register of certificates of ES verification keys must be recorded in the audit log.

31.4. The requirements for CA facilities of classes KB1, KB2 and CA1 are the same as the requirements for CA facilities of class KS3.
32. Requirements for verification of the ES in the certificate of the ES verification key:

32.1. The mechanism for verifying the signature in the ES verification key certificate at the request of the electronic interaction participant must be determined and specified in the operational documentation for the CA facilities.

32.2. The CA tools must implement the CA ES authentication mechanism in the ES verification key certificates issued by it.

32.3. ES verification in the ES verification key certificate is carried out in accordance with X.509 recommendations, including mandatory check all critical additions.

32.4. If, based on the specifics of the operation of the CA tools, it is allowed to use alternative formats of the ES verification key certificate, the mechanism for verifying the signature in the ES verification key certificate must be determined and specified in the ToR for the development (upgrading) of the CA tools.

33. To limit the possibilities for building channels of attacks on CA facilities using communication channels, firewalls should be used.

34. Requirements for the protection of CA tools from computer viruses and computer attacks should be defined and specified in the ToR for the development (modernization) of CA tools.

35. When connecting CA facilities to an information and telecommunications network, access to which is not limited to a certain circle of persons, these facilities must comply with the requirements for CA facilities of class KV2 or KA1.

36. Studies of the CA tools in order to confirm the compliance of the CA tools with these Requirements should be carried out using the numerical values ​​of the parameters and characteristics of the protection mechanisms implemented in the CA tools developed by the FSB of Russia 8 .

1 Registered by the Ministry of Justice of Russia on March 3, 2005, registration number 6382.
2 Registered by the Russian Ministry of Justice on May 25, 2010, registration number 17350.
3 The required class of the developed (upgraded) CA tools is determined by the customer (developer) of the CA tools by determining the possibilities to create attack methods, prepare and conduct attacks based on clauses 9-14 of these Requirements and is indicated in the tactical and technical assignment or the technical assignment for conducting experimental design work or an integral part of development work on the development (modernization) of CA facilities (hereinafter referred to as T3 for the development (modernization) of CA facilities).
4 Software environment, which allows the existence in it of only a fixed set of subjects (programs, processes).
5 Persons who are members of the group of administrators of CA tools and who are obviously not violators.
6 The imposition of a false message is an action perceived by the participants of electronic interaction or by means of the CA as the transmission of a true message in a way protected from unauthorized access.
7 ITU-T Recommendation X.509. Information technology - Open systems interconnection - The Directory: Public-key and attribute certificate frameworks. 2008. http://www.itu.int/rec/T-REC-X.509-200811-i.
8 Subparagraph 47 of paragraph 9 of the Regulations on the Federal Security Service of the Russian Federation, approved by Decree of the President of the Russian Federation of August 11, 2003 No. 960 (Sobraniye Zakonodatelstva Rossiyskoy Federatsii, 2003, No. 33, Art. 3254; 2004, No. 28, Art. 2883; 2005, No. 36, article 3665; No. 49, article 5200; 2006, No. 25, article 2699; No. 31 (part I), article 3463; 2007, No. 1 (part I), article 205 ; No. 49, item 6133; No. 53, item 6554; 2008, No. 36, item 4087; No. 43, item 4921; No. 47, item 5431; 2010, No. 17, item 2054; No. 20, 2435; 2011, No. 2, article 267; No. 9, article 1222).