Protection against unauthorized access to information Part 1. Information security software

Classification according to the level of control over the absence of undeclared capabilities

Approved by the decision of the Chairman of the State technical commission under the President Russian Federation dated June 4, 1999 N 114

Real Guidance document(RD) establishes classification software(software) (both domestic and imported) information security tools (ISIS), including those built into general system and application software, according to the level of control over the absence of undeclared capabilities in it.

The document does not apply to the software of the tools cryptographic protection information.

The level of control is determined by the fulfillment of the set of requirements specified by this RD, imposed by:
- to the composition and content of documentation, submitted by the applicant for testing the information protection software;
- to the content of the tests.

The guidance document has been developed to complement:
- RD "Means computer technology. Protection against unauthorized access to information. Indicators of security against unauthorized access to information”, M., Military Publishing House, 1992;
- RD “Automated systems. Protection against unauthorized access to information. Classification of automated systems and requirements for information protection”, M., Military Publishing House, 1992;
- RD “Computer facilities. Firewalls. Protection against unauthorized access to information. Indicators of security against unauthorized access to information", M., 1997.

The document is intended for specialists in testing laboratories, customers, and information security software developers when monitoring it in terms of the absence of undeclared capabilities.

1. GENERAL PROVISIONS

1.1. The classification applies to software designed to protect restricted information.

1.2. Four levels of control over the absence of undeclared capabilities are established. Each level is characterized by a certain minimum set of requirements.

1.3. For software used to protect information related to state secret, a level of control not lower than third must be ensured.

1.4. Most high level control - the first, is sufficient for software used to protect information classified as “OV”.

The second level of control is sufficient for software used to protect information marked “CC”.

The third level of control is sufficient for software used to protect information classified as “C”.

1.5 Most low level control - fourth, sufficient for software used in protection confidential information.

2. TERMS AND DEFINITIONS

2.1. Undeclared capabilities are software functionality that is not described or does not correspond to those described in the documentation, the use of which may violate the confidentiality, availability or integrity of the processed information.

The implementation of undeclared capabilities, in particular, are software bookmarks.

2.2. Software bookmarks are functional objects deliberately added to the software, which, under certain conditions (input data), initiate the execution of software functions not described in the documentation, leading to a violation of the confidentiality, availability or integrity of the processed information.

2.3. A functional object is a program element that carries out actions to implement a completed fragment of the program algorithm.

Functional objects can be procedures, functions, branches, operators, etc.

2.4. Information object- a program element containing fragments of information circulating in the program. Depending on the programming language as information objects can be variables, arrays, records, tables, files, fragments random access memory and so on.

2.5. The execution route of functional objects is a sequence of executed functional objects determined by the algorithm.

2.6. The actual execution route of functional objects is the sequence of functional objects that are actually executed when certain conditions(input data).

2.7. The critical route for the execution of functional objects is a route during which there is a possibility of uncontrolled violation established rules processing information objects.

2.8. Static analysis of program source codes - a set of methods for monitoring (in)conformity implemented and declared in the documentation functionality Software based on structural analysis and decomposition of program source codes.

2.9. Dynamic analysis of program source codes is a set of methods for monitoring (in)compliance of software functionality implemented and declared in the documentation, based on the identification of actual execution routes of functional objects with subsequent comparison with routes constructed in the process of static analysis.

3. REQUIREMENTS FOR THE LEVEL OF CONTROL
3.1. LIST OF REQUIREMENTS

Table 1

Designations
"-" - no requirements for this level;
"+" - new or Additional requirements;
"=" - the requirements are the same as the requirements of the previous level.

3.2. REQUIREMENTS FOR THE FOURTH LEVEL OF CONTROL

3.2.1. Control of the composition and content of documentation

The documentation submitted by the applicant must include:

Specification (GOST 19.202-78), containing information about the composition of the software and documentation for it;

Description of the program (GOST 19.402-78), containing basic information about the composition (indicating the checksums of the files included in the software), logical structure and the software operating environment, as well as a description of methods, techniques and rules for operating technological equipment when creating software;

Application description (GOST 19.502-78), containing information about the purpose of the software, scope of application, methods used, class of tasks to be solved, application restrictions, minimum configuration technical means, operating environment and operating procedure.

Source texts of programs (GOST 19.401-78) included in the software.

For imported software, the composition of the documentation may differ from the required one, but the content must comply with the requirements of the specified GOSTs.

3.2.2. Monitoring the initial state of the software

Control consists of recording the initial state of the software and comparing the results obtained with those given in the documentation.

The results of monitoring the initial state of the software should be calculated unique values ​​of checksums of load modules and source codes of programs included in the software.

Checksums must be calculated for each file included in the software.

3.2.3. Static analysis of program source codes

Static analysis of program source codes should include the following technological operations:
- control of completeness and lack of redundancy of software source texts at the file level;
- control of compliance of software source texts with its object (boot) code.

3.2.4. Reporting

Upon completion of the tests, a report (protocol) is drawn up containing the results:
- monitoring the initial state of the software;
- control of the completeness and absence of redundancy of the source texts of the controlled software at the file level;
- control of compliance of source texts with its object (boot) code.

3.3. REQUIREMENTS FOR THE THIRD LEVEL OF CONTROL

3.3.1. Control of the composition and content of documentation

The requirements fully include similar requirements for the fourth level of control.

In addition, an “Explanatory Note” (GOST 19.404-79) must be presented, containing basic information about the purpose of the components included in the software, the parameters of the processed data sets (database subschemas), generated return codes, a description of the variables used, operating algorithms and etc.

3.3.2. Monitoring the initial state of the software

The requirements fully include similar requirements for the fourth level of control.

3.3.3.Static analysis of program source codes

In addition to similar requirements for the fourth level of control, additional the following requirements:
- control of completeness and lack of redundancy of software source texts at the level of functional objects (procedures);
- control of connections of functional objects (modules, procedures, functions) for management;
- control of connections of functional objects (modules, procedures, functions) according to information;
- control of information objects various types(for example, local variables, global variables, external variables, etc.);
- formation of a list of routes for executing functional objects (procedures, functions).

3.3.4. Dynamic analysis of program source codes

Dynamic analysis of program source codes should include the following technological operations:
- control of the execution of functional objects (procedures, functions);
- comparison of actual execution routes of functional objects (procedures, functions) and routes constructed in the process of static analysis.

3.3.5. Reporting

In addition to similar requirements for the fourth level of control, the report (protocol) must additionally contain the results of:
- control of the completeness and lack of redundancy of the source texts of the controlled software at the level of functional objects (procedures);
- control of connections of functional objects (modules, procedures, functions) for management;
- control of connections of functional objects (modules, procedures, functions) according to information;
- control of information objects of various types (for example, local variables, global variables, external variables, etc.);
- generating a list of routes for executing functional objects (procedures, functions);
- monitoring the execution of functional objects (procedures, functions);
- comparison of actual execution routes of functional objects (procedures, functions) and routes constructed in the process of static analysis.

3.4. REQUIREMENTS FOR THE SECOND LEVEL OF CONTROL

3.4.1. Control of the composition and content of documentation

3.4.2. Monitoring the initial state of the software

The requirements fully include similar requirements for the third level of control.

3.4.3. Static analysis of program source codes

- control of the completeness and lack of redundancy of the source texts of the controlled software at the level of functional objects (functions);
- syntactic control of the presence of specified structures in the source texts of software from the list (base) of potentially dangerous ones program constructs;
- formation of a list of routes for the execution of functional objects (branches);
- analysis of critical routes for the execution of functional objects (procedures, functions) for lists of information objects specified by the expert;
- construction of block diagrams, diagrams, etc. from the source texts of the controlled software, and subsequent comparative analysis of the operation algorithm of functional objects (procedures, functions) and the operation algorithm given in the “Explanatory Note”.

3.4.4. Dynamic analysis of program source codes

In addition to similar requirements for the third level of control, the following requirements are additionally imposed:
- control of the execution of functional objects (branches);
- comparison of actual execution routes of functional objects (branches) and routes constructed in the process of static analysis

3.4.5 Reporting

In addition to similar requirements for the third level of control, the report (protocol) must additionally contain the results of:
- control of completeness and lack of redundancy of source texts of controlled software at the level of functional objects (functions);
- syntactic control of the presence of specified structures in the source texts of the software from the list (base) of potentially dangerous structures;
- generating a list of routes for executing functional objects (branches);
- analysis of critical routes for the execution of functional objects (procedures, functions) for lists of information objects specified by an expert;
- construction of block diagrams, diagrams, etc. from the source texts of the controlled software, and subsequent comparative analysis algorithm of operation of functional objects (procedures, functions) and the algorithm of operation given in the “Explanatory Note”;
- monitoring the execution of functional objects (branches);
- comparison of actual execution routes of functional objects (branches) and routes constructed in the process of static analysis.

3.5. REQUIREMENTS FOR THE FIRST LEVEL OF CONTROL

3.5.1. Control of the composition and content of documentation

3.5.2. Monitoring the initial state of the software

The requirements fully include similar requirements for the second level of control.

3.5.3. Static analysis of program source codes

In addition to similar requirements for the second level of control, the following requirements are additionally imposed:
- control of compliance of software source texts with its object (boot) code using certified compilers;
- semantic control of the presence of specified structures in the source texts of the software from the list (base) of potentially dangerous structures.

3.5.4. Dynamic analysis of program source codes

The requirements fully include similar requirements for the second level of control.

3.5.5. Reporting

In addition to similar requirements for the second level of control, the report (protocol) must additionally contain the results of:
- monitoring the compliance of software source texts with its object (boot) code using certified compilers;
- semantic control of the presence of specified structures in the source texts of the software from the list (base) of potentially dangerous structures.

I’ve been meaning to do two things for a long time - start writing articles about conducting certification tests according to "RD NDV" and post some of your projects on GitHub, converting it to open-source. The time has come to combine business with pleasure, and today I am opening a series of articles about software certification for compliance with requirements for levels of control over the absence of undeclared capabilities.

I’ll start, perhaps, from the middle - with a check called “Controlling the compliance of source texts with its object (boot) code”, this check is present at all levels of control and is the same for all levels, except for the first - on it the addition “using certified compilers” appears.

I am forced to omit the remaining checks for now because of the second condition - I have a small utility to automate this check, which I want to post in open access. I have a wide variety of other utilities, but this one is the simplest and I want to collect feedback on this topic - so do not forget about the comments.

So, monitoring the compliance of source texts with the object one. What is it? It's simple - the developer transfers the software source code and distribution to the testing laboratory, and the laboratory must make sure that the source code matches the distribution. It would seem that this is very simple to do - we compile the source texts, get object files, and compare them with the distribution kit. But in practice, everything turns out to be more complicated; different compilers and assemblers work differently.

Object files of executable modules obtained by compiling source codes during testing may differ from the executable software modules submitted for testing in terms of official information, generated by the development environment, and depending on the date, time and compilation conditions. Also, a number of compilers, when reassembling program source codes, make changes to the order of command blocks, which is why the binary files are the same in content and size, but differ in byte-by-byte checking.

What to do in this situation? There is a generally accepted method and there is mine alternative way. The generally accepted method is to compile source codes on the developer’s premises and accept the resulting distribution as a reference one, that is, the assembly of the reference distribution does not occur before the materials are transferred to the testing laboratory, but only after, under the direct supervision of laboratory specialists, who simultaneously collect reporting materials for test reports .

My method differs from the generally accepted one and is based on the following observation - most of the discrepancies between binary files obtained in laboratory conditions and those submitted by the developer differ only in the order of the blocks and the difference in header information. To verify this fact and perform tests, an adaptive comparison tool for binary files was developed, which compares by blocks, searching for them at a distance from each other.

The general methodology is as follows - control of the compliance of the source texts of the software with its object (boot) code is carried out using software package fixing and monitoring the initial state of FIX (or AK-VS, PIK, etc.) by selecting the “File comparison” operating mode with the “for *.exe” setting. If discrepancies are found when comparing files, these files are re-compared using the adaptive binary file comparison utility. This tool analyzes block offsets in binary files.

The tool is written in PHP and runs from command line with two parameters - paths to the compared object files. Example output (work results):

Comparing file1.exe to file2.exe .

272700/272700 errors: 0 , warnings: 0

Warnings: 0/272700

The “Forward deep” and “Backward deep” values ​​are configurable values, the block search range in bytes, the “Block size” value is the size of blocks. These values ​​are selected by an expert depending on the type of binary file and development environment and are changed in the code of the bindiff.php file using any text editor. The return value “Errors” is the number of different bytes, “Warnings” is the number of block movements.

Here we must add that faith in this utility should not be absolute; if the discrepancy is confirmed, the non-conforming blocks are analyzed by an expert for the significance and executability of the differing code. To do this, you can repeat the compilation several times on one or different computers, remember the structure of the PE format, ELF format and others (depending on the OS and type of program), and so on.

If the discrepancies concern service information of binary files and insignificant executable code (do not affect the execution process), these discrepancies are not a discrepancy and the test is considered passed.

The utility is available on GitHub, license - GNU GPL v.3. Forks, pull requests and comments are welcome.

As for the correctness of this verification method from the point of view of certification bodies and federal authorities, the question is open. I used these checks when conducting tests in the certification system of the Ministry of Defense and questions to this method from employees federal body certification and no experts were involved. But the FSTEC certification system differs from the Ministry of Defense; at a minimum, it also has ordinary certification bodies that check test results, so I cannot guarantee the passage of this test in this form.

Colleagues, please express your opinion on this test and the possibility of using it for certification in the FSTEC system.

This Guidance Document (RD) establishes the classification of software (both domestic and imported) information security tools (IS), including those built into general system and application software, according to the level of control over the absence of undeclared capabilities in it.

The document does not apply to software for cryptographic information protection tools.

The level of control is determined by the fulfillment of the set of requirements specified by this RD :

to the composition and content of documentation, submitted by the applicant for testing the information protection software

The guidance document was developed in addition to the RD “Computer facilities. Protection against unauthorized access to information. Indicators of security against unauthorized access to information", M., Military Publishing House, 1992,

RD “Automated systems. Protection against unauthorized access to information. Classification of automated systems and requirements for information protection", M., Military Publishing House,

1992 and RD “Computer facilities. Firewalls. Protection against unauthorized access to information. Indicators of security against unauthorized access to information,” M., 1997.

The document is intended for specialists of testing laboratories, customers, and information security software developers when monitoring it in terms of the absence of undeclared capabilities.

1. General Provisions

1.1. Classification applies to software designed to protect restricted information.

1.2. Installed four levels of control lack of undeclared capabilities. Each level is characterized by a certain minimum set of requirements.

1.3. For software used to protect information, classified as a state secret, a level of control must be ensured not lower than third.

1.4 . The highest level of control – first , sufficient for software used to protect information classified as “OV”.

Second level of control sufficient for software used to protect information marked “CC”.

Third level of control sufficient for software used to protect information marked “C”.

1.5 Lowest level of control - fourth , sufficient for software used for protection confidential information.

2. Terms and definitions

2.1. Undeclared capabilities - functionality of the software that is not described or does not correspond to those described in the documentation, the use of which may violate the confidentiality, availability or integrity of the processed information. The implementation of undeclared capabilities, in particular, are software bookmarks.

2.6. The actual execution route of functional objects is the sequence of functional objects that are actually executed under certain conditions (input data).

And, by the way, there is no “license for NDV”.

I'm not digging into it, I just want to figure it out.

The applicant may be one of the developers if the development is joint.

The applicant is simply - then why should he do this?

If for further production, then a license is needed.

If not, then you need a set of documents for certification, an agreement with the developer on the use of the development, or some other basis. IN in this case Why does he need a certificate if it is impossible to produce with subsequent sale.

> by the developer about the use of the development or other basis. In this case

> why does he need a certificate if it is impossible to produce with subsequent sale.

How to get FSTEC certification

Receiving the coveted certificate

On certification of non-cryptographic information and telecommunication systems according to the requirements of the FSB

I.G. Shaposhnikov, Director of LLC "Center for Certification Research", Ph.D.

V.A. Myltsev, Deputy Director for Licensing and Certification LLC "Center for Certification Research"

ONE of the areas of activity of the FSB (formerly FAPSI) is the certification of cryptographic information protection means. The certification studies themselves are carried out in accredited laboratories and centers. At the same time, product compliance with information security requirements is confirmed. LLC "Center for Certification Research" (CSR) was created as an organization engaged in the certification of cryptographic equipment. Therefore, with the first licenses received, the center acquired the status testing laboratory on certification of encryption technology in accordance with communication security requirements established by FAPSI. Certification of encryption technology is an area of ​​activity in which it is necessary for the certification customer to have a clear understanding of the procedure for its implementation. The latter, as a rule, are aware of what actions they need to take in order to successfully complete the certification procedure and what materials to submit. Specified order legally fixed in a number of regulatory documents(for example, PKZ-2005).

In accordance with new requirements

IN Lately area of ​​certified products according to requirements information security The FSB has expanded significantly. Nowadays, not only telecommunications equipment that includes cryptographic security measures is certified, but also those that do not have them.

Currently, in addition to encryption technology, the FSB certifies:

• digital PBX;
• firewalls;
• plesiochronous digital hierarchy equipment;
• software used in automated systems ITCS for special purposes;
• antiviral agents.

When carrying out certification studies, regulatory documents (requirements, methods) of the FSB are used. Currently, such documents exist for all types of the above telecommunications equipment that do not contain cryptographic information protection means. CRC became a pioneer in conducting certification studies in accordance with these new requirements, took part in the creation of regulatory methodological documents and works in strict accordance with them.

The purpose of this article is to give some idea of ​​the existing difficulties in certifying equipment that does not contain encryption technology. It is also necessary to dwell on the requirements that are presented to the creators of this technology.

IN last years Many new non-state development companies have appeared, usually unfamiliar with this procedure. Deficiency of widespread drugs plays a negative role (for example, like PKZ-99 and PKZ-2005) state documents regulating the development and certification of safety requirements. In their absence, the order of conduct is determined existing practice. Below we will try to reflect the most important points of the procedure, based on the experience of the CRC.

From application to certificate

So, certification includes the following necessary steps:

• submitting an application for certification to the FSB - indicating the certification scheme and the names of standards and other regulatory documents for compliance with the requirements of which certification must be carried out;
• coordination of the level of certification requirements;
• development of technical specifications and conclusion of an agreement with a testing laboratory;
• presentation of samples of certified products and all necessary documentation for testing;
• conducting certification tests;
• modification (if necessary) of products according to safety requirements with subsequent verification;
• preparing a report and sending it to the FSB; » preparation of a report to the FSB and issuance of a certificate.

The level of requirements for certified products, as a rule, is determined by the certification customer together with the FSB and the customer of the system where the certified equipment will be installed. In this case, the functionality of the equipment is also limited - only the functions used in this application, others are deleted or blocked at the software or hardware level. The highest level of information protection requirements is associated with the processing of information containing information that constitutes a state secret. Accordingly, when certifying technical means intended for their processing, maximum amount types of tests, and each one is held to the most stringent standards. This, naturally, entails longer and more labor-intensive research. And the equipment developer (applicant) is required to provide the most detailed and complete materials(documentation) on certified equipment.

List of submitted documentation for certified equipment

1. A detailed diagram of the architecture of the certified object, in which all function blocks and connections between them.

2. Description of the operation of the entire product.

3. For each board (subunit) the following must be provided:

• technical description;
• setup instructions;
• user manual;
• electrical circuit diagram;
• list of elements;
• functional diagram.

4. Detailed description Software that must contain:

• software architecture;
• functional diagram;
• algorithms are the most significant procedures and functions;
• a list of all modules and their meaning;
• a list of all procedures, functions, constants and variables and their purpose;
• all source texts with comments;
• development tools for working with software source codes;
• configuration files for development tools;
• compilation tools, methods and order of assembly of the final software project;
• testing schemes for certified equipment and all declared functionality on the certified equipment.

Standards do not change

It is necessary to especially emphasize the fact that certification involves “freezing” the process of equipment development at a certain stage, corresponding to the needs of the customer of a special telecommunication system. Therefore, all of the above documentation must refer to this one “frozen” modification. The latter will undergo a full range of tests, receive a certificate and become a model. It will be used to produce equipment that will be covered by the concept of “certified.”

Developers of telecommunications equipment regularly change the software of the equipment in order to correct errors, expand the functions performed, or to track the transforming hardware (for example, the element base), that is, continuous modernization of the equipment occurs. However, extending the certificate to equipment with any transformations requires additional research. This is where, as a rule, misunderstanding arises between the developer and the certifying organization. First, the first one submits documentation, different parts of which relate to different stages“development” of the equipment, and after certification considers it possible to make minor, from his point of view, changes, which does not meet high requirements requirements for certified equipment.

Such strict security criteria information security in telecommunications equipment according to the requirements of the FSB are determined by the area of ​​its use. The FSB certificate provides the opportunity to operate equipment in higher authorities authorities. Therefore, the hardware developer should consider whether certification is necessary before pursuing certification. It is possible that it will be enough to get FSTEC certificate, which allows the equipment to be used in government agencies. If the decision on certification according to the FSB requirements has been made, then you should begin working with specialists from the certification laboratory to draw up technical specifications, determine the level of protection, and compile a list of documentation and equipment for certification. In the Center for Contemporary Art, for example, such preparation is carried out even before concluding an agreement with organizations.

An important point further collaboration The certifying organization and the customer determine the scope of research and, accordingly, the cost of work. Due to the complexity of the equipment being examined, it is sometimes difficult to establish this volume without conducting preliminary studies. Then, at first, a contract is concluded only for the first stage of work, when preliminary analysis documentation, a program and test methods are being developed, which are consistent with the relevant division of the FSB. The agreed research program becomes the objective document on the basis of which the volume of future research, the timing of its implementation and the cost of work are determined.

One more thing worth noting important point implementation of certification studies - examination of submitted reports in expert organization(unit of the 8th FSB Center). This stage is not included in the certification agreement (since the FSB cannot be a party to the agreement), but its implementation usually takes up to two months. The result of the examination is the conclusion of the 8th FSB Center on compliance with security requirements. Of course, the positive conclusions of the certification laboratory's reports do not guarantee the same positive assessments of the conclusion. However, the practice of our testing laboratory shows that the coincidence of conclusions is almost one hundred percent. A positive conclusion entitles you to receive a certificate.

Discussion

Do they require certification? If required, then on the basis of what documents?

I don’t understand since when the professional term for encryption technology began with the letter “O9” inside.

Previously, only “LOBERS” wrote this way.

No prices, no clear requirements.

Where were you certifiers?

Please note that certification said technology recognized as necessary, since this guarantees a certain level of stability in the operation of information and telecommunication systems against computer attacks, unauthorized access to information resources, illegal or erroneous actions service personnel. That is why certified equipment, as a rule, is in demand by government customers, which is important for its developers.

What is this even about?

What has been done in this direction?

Did you just blow bubbles?

The intern wrote (first bottom photo) - and both censors (top photos) were apparently asleep.

"ONE of the areas of activity of the FSB (formerly FAPSI)"

as if the FSB used to be called FAPSI :)

The personnel of the 8th Main Directorate of the KGB were divided between the KGB and the SVR

then from the KGB they were called FSK and somewhere there, FAPSI was formed from the same ones.

And when Putin divided FAPSI between the FSO, FSB and SVR, he already confused everyone.

So they call themselves whatever they want, assuming that the name of the head of the department (department) says something to the initiates.

In a word, don’t load - it’s all one mess.

It’s just that previously this area was under the jurisdiction of FAPSI. When FAPSI was divided, it went to the FSB

Did you study the subject from the encyclopedia?

Or did you intentionally introduce this error there (into the encyclopedia)?

As far as I can tell in a professional (NOT Amateur) environment, the term

CIPHER "o9TEHNIKA" has been written since ancient times without the connective "O9".

O - this is for clickers of the Shchechelev level and other “JOURNALISTS9-” specialists9.

Guidance document

Protection against unauthorized access to information

Information security software

Classification according to the level of control over the absence of undeclared capabilities

Approved by the decision of the Chairman of the State Technical Commission under the President of the Russian Federation dated June 4, 1999 No. 114

1. GENERAL PROVISIONS

2.TERMS AND DEFINITIONS

This Guidance Document (RD) establishes the classification of software (both domestic and imported) information security tools (IS), including those built into general system and application software, according to the level of control over the absence of undeclared capabilities in it.

The document does not apply to software for cryptographic information protection tools.

The level of control is determined by the fulfillment of the set of requirements specified by this RD, imposed by:

To the composition and content of the documentation submitted by the applicant for testing the information protection software;

The guidance document has been developed to complement:

RD “Computer facilities. Protection against unauthorized access to information. Indicators of security against unauthorized access to information”, M., Military Publishing House, 1992;

RD “Automated systems. Protection against unauthorized access to information. Classification of automated systems and requirements for information protection”, M., Military Publishing House, 1992;

RD “Computer facilities. Firewalls. Protection against unauthorized access to information. Indicators of security against unauthorized access to information", M., 1997.

The document is intended for specialists of testing laboratories, customers, and information security software developers when monitoring it in terms of the absence of undeclared capabilities.

1. GENERAL PROVISIONS

1.1. The classification applies to software designed to protect restricted information.

1.2. Four levels of control over the absence of undeclared capabilities are established. Each level is characterized by a certain minimum set of requirements.

1.3. For software used to protect information classified as state secrets, a control level of at least third must be ensured.

1.4. The highest level of control is the first, sufficient for software used to protect information classified as “OV”.

The second level of control is sufficient for software used to protect information marked “CC”.

The third level of control is sufficient for software used to protect information classified as “C”.

1.5 The lowest level of control is the fourth, sufficient for software used to protect confidential information .

2. TERMS AND DEFINITIONS

2.1. Undeclared capabilities are software functionality that is not described or does not correspond to those described in the documentation, the use of which may violate the confidentiality, availability or integrity of the processed information.

Implementation undeclared features, in particular, are software bookmarks.

2.2. Software bookmarks are functional objects deliberately added to the software, which, under certain conditions (input data), initiate the execution of software functions not described in the documentation, leading to a violation of the confidentiality, availability or integrity of the processed information.

2.3. A functional object is a program element that carries out actions to implement a completed fragment of the program algorithm.

Functional objects can be procedures, functions, branches, operators, etc.

2.4. Information object is a program element containing fragments of information circulating in the program. Depending on the programming language, variables, arrays, records, tables, files, fragments of RAM, etc. can serve as information objects.

2.5. The execution route of functional objects is a sequence of executed functional objects determined by the algorithm.

2.6. The actual execution route of functional objects is the sequence of functional objects that are actually executed under certain conditions (input data).

2.7. A critical route for the execution of functional objects is a route during which there is the possibility of an uncontrolled violation of the established rules for processing information objects.

2.8. Static analysis of program source codes is a set of methods for monitoring the (in)conformity of software functionality implemented and declared in the documentation, based on structural analysis and decomposition of program source codes.

2.9. Dynamic analysis of program source codes is a set of methods for monitoring (in)compliance of software functionality implemented and declared in the documentation, based on the identification of actual execution routes of functional objects with subsequent comparison with routes constructed in the process of static analysis.

3. REQUIREMENTS FOR THE LEVEL OF CONTROL

3.1. LIST OF REQUIREMENTS

Table 1.

Designations

"-" - there are no requirements for this level;

"+" - new or additional requirements;

"=" - the requirements are the same as the requirements of the previous level.

3.2. REQUIREMENTS FOR THE FOURTH LEVEL OF CONTROL

3.2.1. Control of the composition and content of documentation

The documentation submitted by the applicant must include:

Specification (GOST 19.202-78), containing information about the composition of the software and documentation for it;

Description of the program (GOST 19.402-78), containing basic information about the composition (indicating the checksums of the files included in the software), logical structure and operating environment of the software, as well as a description of methods, techniques and rules for operating technological equipment when creating software;

Application description (GOST 19.502-78), containing information about the purpose of the software, scope of application, methods used, class of tasks to be solved, application restrictions, minimum configuration of hardware, operating environment and operating procedure.

Source texts of programs (GOST 19.401-78) included in the software.

For imported software, the composition of the documentation may differ from the required one, but the content must comply with the requirements of the specified GOSTs.

3.2.2. Monitoring the initial state of the software

Control consists of recording the initial state of the software and comparing the results obtained with those given in the documentation.

The results of monitoring the initial state of the software should be calculated unique values ​​of checksums of load modules and source codes of programs included in the software.

Checksums must be calculated for each file included in the software.

3.2.3. Static analysis of program source codes

Static analysis of program source codes should include the following technological operations:

Control of completeness and lack of redundancy of software source texts at the file level;

Monitoring the compliance of software source texts with its object (boot) code.

3.2.4. Reporting

Upon completion of the tests, a report (protocol) is drawn up containing the results:

Monitoring the initial state of the software;

Controlling the completeness and lack of redundancy of the source texts of the controlled software at the file level;

Monitoring the compliance of software source texts with its object (boot) code.

3.3. REQUIREMENTS FOR THE THIRD LEVEL OF CONTROL

3.3.1. Control of the composition and content of documentation

The requirements fully include similar requirements for the fourth level of control.

In addition, an “Explanatory Note” (GOST 19.404-79) must be presented, containing basic information about the purpose of the components included in the software, the parameters of the processed data sets (database subschemas), generated return codes, a description of the variables used, operating algorithms and etc.

3.3.2. Monitoring the initial state of the software

The requirements fully include similar requirements for the fourth level of control.

3.3.3.Static analysis of program source codes

In addition to similar requirements for the fourth level of control, the following requirements are additionally imposed:

Control of completeness and lack of redundancy of software source codes at the level of functional objects (procedures);

Control of connections of functional objects (modules, procedures, functions) for management;

Monitoring connections of functional objects (modules, procedures, functions) based on information;

Control of information objects of various types (for example, local variables, global variables, external variables, etc.);

Formation of a list of routes for executing functional objects (procedures, functions).

3.3.4. Dynamic analysis of program source codes

Dynamic analysis of program source codes should include the following technological operations:

Monitoring the execution of functional objects (procedures, functions);

Comparison of actual execution routes of functional objects (procedures, functions) and routes constructed in the process of static analysis.

3.3.5. Reporting

In addition to similar requirements for the fourth level of control, the report (protocol) must additionally contain the results of:

Monitoring the completeness and lack of redundancy of the source texts of the controlled software at the level of functional objects (procedures);

Controlling connections of functional objects (modules, procedures, functions) for management;

Controlling connections of functional objects (modules, procedures, functions) based on information;

Control of information objects of various types (for example, local variables, global variables, external variables, etc.);

Generating a list of routes for executing functional objects (procedures, functions);

Monitoring the execution of functional objects (procedures, functions);

Comparison of actual execution routes of functional objects (procedures, functions) and routes constructed in the process of static analysis.

3.4. REQUIREMENTS FOR THE SECOND LEVEL OF CONTROL

3.4.1. Control of the composition and content of documentation

3.4.2. Monitoring the initial state of the software

The requirements fully include similar requirements for the third level of control.

3.4.3. Static analysis of program source codes

Control of completeness and lack of redundancy of source texts of controlled software at the level of functional objects (functions);

Syntactic control of the presence of specified structures in software source codes from the list (base) of potentially dangerous software constructs;

Formation of a list of routes for executing functional objects (branches);

Analysis of critical routes for the execution of functional objects (procedures, functions) for lists of information objects specified by an expert;

Construction of block diagrams, diagrams, etc. from the source texts of the controlled software, and subsequent comparative analysis of the operation algorithm of functional objects (procedures, functions) and the operation algorithm given in the “Explanatory Note”.

3.4.4. Dynamic analysis of program source codes

In addition to similar requirements for the third level of control, the following requirements are additionally imposed:

Monitoring the execution of functional objects (branches);

Comparison of actual execution routes of functional objects (branches) and routes constructed in the process of static analysis

3.4.5 Reporting

In addition to similar requirements for the third level of control, the report (protocol) must additionally contain the results of:

Monitoring the completeness and lack of redundancy of the source texts of the controlled software at the level of functional objects (functions);

Syntactic control of the presence of specified constructs in software source codes from the list (database) of potentially dangerous structures;

Generating a list of routes for executing functional objects (branches);

Analysis of critical routes for the execution of functional objects (procedures, functions) for lists of information objects specified by an expert;

Construction of flowcharts, diagrams, etc. from the source texts of the controlled software, and subsequent comparative analysis of the operation algorithm of functional objects (procedures, functions) and the operation algorithm given in the “Explanatory Note”;

Controlling the execution of functional objects (branches);

Comparisons of actual execution routes of functional objects (branches) and routes constructed during the process of static analysis.

3.5. REQUIREMENTS FOR THE FIRST LEVEL OF CONTROL

3.5.1. Control of the composition and content of documentation

3.5.2. Monitoring the initial state of the software

The requirements fully include similar requirements for the second level of control.

3.5.3. Static analysis of program source codes

In addition to similar requirements for the second level of control, the following requirements are additionally imposed:

Monitoring the compliance of software source texts with its object (boot) code using certified compilers;

Semantic control of the presence of specified structures in software source codes

3.5.4. Dynamic analysis of program source codes

The requirements fully include similar requirements for the second level of control.

3.5.5. Reporting

In addition to similar requirements for the second level of control, the report (protocol) must additionally contain the results of:

Monitoring the compliance of software source texts with its object (boot) code using certified compilers;

Semantic control of the presence of specified structures in software source codes from the list (database) of potentially dangerous structures.