Computer equipment. Protection from unauthorized access to information.

logo11d 4 1

Computer equipment. Protection against unauthorized access to information. Indicators of protection against unauthorized access to information. Guidance document.

This Guidance document establishes the classification of computer equipment by the level of protection against unauthorized access to information based on a list of security indicators and a set of requirements describing them.

Computer equipment is understood as a set of software and technical elements of data processing systems that can function independently or as part of other systems.

Abbreviations used

AC — automated system
KD— design documentation
KPS — set of security tools
NSD — unauthorized access
PRD — access control rules
CST — computing equipment

1. GENERAL PROVISIONS

1.1. These indicators contain requirements for the protection of CST from unauthorized access to information.

1.2. The security indicators of the computer equipment apply to general-system software and operating systems (taking into account the computer architecture).

Specific lists of indicators define the security classes of the computer equipment.

Reducing or changing the list of indicators corresponding to a specific security class of the computer equipment is not allowed.

Each indicator is described by a set of requirements.

Additional requirements for the security indicator of the computer equipment and compliance with these additional requirements are discussed separately.

1.3. The requirements for the indicators are implemented using software and hardware.

The totality of all means of protection constitutes a set of means of protection.

The documentation of the security system must be an integral part of the design documentation for the computer equipment.

1.4. Seven classes of computer equipment protection against unauthorized access to information are established. The lowest class is the seventh, the highest is the first.

The classes are divided into four groups, differing in the qualitative level of protection:

  • the first group contains only one seventh class;

  • the second group is characterized by discretionary protection and contains the sixth and fifth classes;

  • the third group is characterized by mandatory protection and contains the fourth, third and second classes;

  • the fourth group is characterized by verified protection and contains only the first class.

1.5. The choice of the security class of the computer equipment for automated systems created on the basis of protected computer equipment depends on the security classification of the information processed in the AS, the operating conditions and the location of the system objects.

1.6. The use of cryptographic information protection tools in the computer equipment set in accordance with GOST 28147-89 can be used to increase the guarantees of the quality of protection.

2. REQUIREMENTS TO SECURITY INDICATORS

2.1. Security indicators

2.1.1. The list of indicators for the computer equipment protection classes is given in the table.

Designations:

« — » — no requirements for this class;
« + » — new or additional requirements,
« = » — the requirements coincide with the requirements for the computer equipment of the previous class.

Indicator name Security class
6 5 4 3 2 1
Discretionary access control principle + + + = + =
Mandatory principle of access control + = = =
Memory clearing + + + = =
Module insulation + = + =
Document marking + = = =
Protection of input and output to alienated physical media + = = =
User to device mapping + = = =
Identification and authentication + = + = = =
Design guarantees + + + + +
Registration + + + = =
User interaction with KSZ + = =
Reliable recovery + = =
CSZ integrity + + + = =
Modification control + =
Distribution control + =
Architecture Guarantees +
Testing + + + + + +
User Guide + = = = = =
Guide to KSZ + + = + + =
Test documentation + + + + + =
Design (design)
documentation
+ + + + + +

2.1.2. The sets of requirements for the indicators of each class given in this section are the minimum necessary.

2.1.3. The seventh class is assigned to computer equipment for which requirements for protection against unauthorized access to information were imposed, but during the assessment the security of the computer equipment turned out to be lower than the requirements of the sixth class.

2.2. Requirements for the indicators of security of the sixth class.

2.2.1. Discretionary principle of access control.

The access control system must control the access of named subjects (users) to named objects (files, programs, volumes, etc.).

For each pair (subject — object) in the STS, an explicit and unambiguous list of permissible access types (read, write, etc.) must be specified, i.e., those types of access that are authorized for a given subject (individual or group of individuals) to a given STS resource (object).

The STS must contain a mechanism that implements discretionary access control rules.

Access control must be applicable to each object and each subject (individual or group of equal individuals).

The mechanism implementing the discretionary principle of access control must provide for the possibility of authorized modification of the access control rules, including the possibility of authorized modification of the list of computer system users and the list of protected objects.

The rights to modify the access control rules must be granted to designated subjects (administration, security service, etc.).

2.2.2. Identification and authentication.

The ISS should require users to identify themselves when requesting access. The ISS should verify the authenticity of identification — perform authentication. The ISS should have the necessary data for identification and authentication. The ISS should prevent unidentified users and users whose authenticity of identification was not confirmed during authentication from accessing protected resources.

2.2.3. Testing.

The sixth-class SBT should test:

implementation of discretionary access control mechanisms (interception of explicit and hidden requests, correct recognition of authorized and unauthorized access requests, means of protecting the access control mechanism, authorized changes to the access control mechanism);

successful implementation of identification and authentication, as well as their means of protection.

2.2.4. User Guide.

The documentation for the STS should include a brief user guide describing how to use the STS and its interface with the user.

2.2.5. STS Guide.

This document is addressed to the security administrator and should contain:

  • description of the controlled functions;

  • guide to generating the STS;

  • description of the STS start and procedures for checking the correctness of the start.

2.2.6. Test documentation.

A description of the tests and trials to which the computer system was subjected (in accordance with clause 2.2.3.) and the test results must be provided.

2.2.7. Design (project) documentation.

Must contain a general description of the operating principles of the computer system, a general diagram of the computer system, a description of the computer system interfaces with the user and the interfaces of the computer system parts with each other, a description of the identification and authentication mechanisms.

2.3. Requirements for the fifth security class indicators.

2.3.1. Discretionary access control principle.

These requirements include similar requirements of the sixth class (p.2.2.1).

Additionally, control tools must be provided to limit the distribution of access rights.

2.3.2. Memory cleaning.

At the initial assignment or during the redistribution of external memory, the security system must prevent the subject from accessing residual information.

2.3.3. Identification and authentication.

These requirements are fully consistent with similar requirements of the sixth class (p. 2.2.2).

2.3.4. Design guarantees.

At the initial stage of the design of the computer system, a security model must be built. The model must include the PRD for objects and consistent rules for changing the PRD.

2.3.5. Registration.

The security system must be able to register the following events:

  • use of the identification and authentication mechanism;

  • request for access to a protected resource (opening a file, running a program, etc.);

  • creation and destruction of an object;

  • actions to change the PDD.

The following information must be registered for each of these events:

  • date and time;

  • the subject performing the action being registered;

  • the event type (if an access request is registered, the object and type of access should be noted);

  • whether the event was successful (whether the access request was serviced or not).

The ISS should contain means for selective familiarization with registration information.

2.3.6. ISS Integrity.

In the fifth security class computer equipment, there must be means for periodic monitoring of the integrity of the software and information part of the security system.

2.3.7. Testing.

In the fifth security class computer equipment, the following must be tested:

  • implementation of the access control system (interception of explicit and hidden access requests, correct recognition of authorized and unauthorized requests, means of protecting the access control mechanism, authorized changes to the access control system);

  • successful implementation of identification and authentication, as well as their protection means;

  • memory clearing in accordance with clause 2.3.2;

  • registration of events in accordance with clause 2.3.5, means of protecting registration information and the possibility of authorized familiarization with it;

  • operation of the mechanism that monitors the integrity of the KSS.

2.3.8. User Manual.

This requirement coincides with the similar requirement of the sixth class (clause 2.2.4).

2.3.9. Security System Guide.

This document is addressed to the security administrator and must contain:

  • description of controlled functions;

  • guide to security system generation;

  • descriptions of the start of the security system, procedures for checking the correctness of the start, procedures for working with registration tools.

2.3.10. Test documentation.

A description of the tests and trials to which the computer system was subjected (in accordance with the requirements of clause 2.3.7) and the test results shall be provided.

2.3.11. Design and project documentation.

Should contain:

  • a description of the operating principles of the computer system;

  • a general diagram of the computer system;

  • a description of the computer system interfaces with the user and the computer system module interfaces;

  • protection model;

  • description of the mechanisms for monitoring the integrity of the security system, clearing memory, identification and authentication.

2.4. Requirements for indicators of the fourth security class.

2.4.1. Discretionary principle of access control.

These requirements include similar requirements of the fifth class (clause 2.3.1).

Additionally, the KPS must contain a mechanism that implements discretionary PRDs for both explicit and hidden user actions, thereby ensuring protection of objects from unauthorized access (i.e. from access that is not permitted from the point of view of the specified PRD). By «explicit» here we mean actions performed using system tools — system macros, high-level language instructions, etc., and by «hidden» — other actions, including using proprietary programs for working with devices.

Discretionary access control rules for systems of this class are an addition to mandatory access control rules.

2.4.2. Mandatory access control principle.

To implement this principle, classification labels of each subject and each object must be compared, reflecting their place in the corresponding hierarchy. By means of these labels, classification levels (vulnerability levels, secrecy categories, etc.) must be assigned to subjects and objects, which are combinations of hierarchical and non-hierarchical categories. These labels must serve as the basis for the mandatory principle of access control.

When new data is entered into the system, the ISS must request and receive classification labels for this data from the authorized user. When a new subject is authorized to be added to the user list, its classification labels must be compared. External classification labels (of subjects, objects) must exactly correspond to internal labels (within the ISS).

The ISC must implement the mandatory access control principle with respect to all objects with explicit and hidden access from any of the subjects:

A subject may read an object only if the hierarchical classification in the subject's classification level is not less than the hierarchical classification in the object's classification level, and the non-hierarchical categories in the subject's classification level include all hierarchical categories in the object's classification level;

the subject writes to the object only if the classification level of the subject in the hierarchical classification is not greater than the classification level of the object in the hierarchical classification, and all hierarchical categories in the classification level of the subject are included in the non-hierarchical categories in the classification level of the object.

The implementation of mandatory PRDs must provide for the possibility of support: changing the classification levels of subjects and objects by specially designated subjects.

The access control system must implement an access manager, i.e. a means of intercepting all requests from subjects to objects, as well as access control in accordance with a given access control principle. In this case, the decision on the authorization of an access request must be made only if it is simultaneously permitted by both discretionary and mandatory access control methods. Thus, not only a single access act must be controlled, but also information flows.

2.4.3. Memory Clearing.

Upon initial assignment or when external memory is redistributed, the KPS must make it difficult for the subject to access residual information. When RAM is redistributed, the KPS must clear it.

2.4.4. Module Isolation.

If the computer system has multiprogramming, the security system must have a software and hardware mechanism that isolates the software modules of one process (one subject) from the software modules of other processes (other subjects) — i.e., in the computer's RAM, programs of different users must be protected from each other.

2.4.5. Document marking.

When outputting protected information to a document, stamp No. 1 is placed at the beginning and end and its details are filled in in accordance with Instruction No. 0126-87 (clause 577).

2.4.6. Protection of input and output to an alienable physical information carrier.

The I/O system must distinguish each input/output device and each communication channel as arbitrarily used or identified («marked»). When input from a «marked» device (output to a «marked» device), the I/O system must ensure a correspondence between the label of the input (output) object (classification level) and the label of the device. The same correspondence must be ensured when working with a «marked» communication channel.

Changes in the assignment and marking of devices and channels should be carried out only under the control of the ISS.

2.4.7. Mapping a user to a device.

The ISS should ensure that information is output to the device requested by the user for both arbitrarily used devices and for identified devices (if the markings match).

The identified ISS should include a mechanism by which an authorized user is reliably mapped to a dedicated device.

2.4.8. Identification and authentication.

The ISS must require users to identify themselves when requesting access, must verify the authenticity of the subject identifier — perform authentication. The ISS must have the necessary data for identification and authentication and prevent an unidentified user or a user whose authenticity was not confirmed during authentication from entering the ISS.

The security system must be able to reliably associate the received identification with all actions of the given user.

2.4.9. Design guarantees.

The design of the security system must begin with the construction of a security model containing:

consistent traffic rules;

consistent traffic rules modification;

rules for working with information input and output devices and communication channels.

2.4.10. Registration.

These requirements include similar requirements of the fifth security class (p. 2.3.5). Additionally, registration of all access attempts, all actions of the operator and designated users (security administrators, etc.) must be provided.

2.4.11. Integrity of the security system.

Periodic monitoring of the integrity of the security system must be carried out in the fourth security class computer equipment.

The security system programs must be executed in a separate part of the RAM.

2.4.12. Testing.

The fourth security class should test:

implementation of access control (interception of access requests, correct recognition of authorized and unauthorized requests in accordance with discretionary and mandatory rules, correct comparison of subject and object labels, request for labels of newly entered information, means of protecting the access control mechanism, authorized modification of access control);

the impossibility for a subject to assign new rights to himself;

clearing RAM and external memory;

operation of the process isolation mechanism in RAM;

document marking;

protection of input and output of information to an alienable physical medium and matching the user with the device;

identification and authentication, as well as their protection means;

prohibition of access by an unauthorized user;

operation of the mechanism that monitors the integrity of the computer hardware;

registration of events described in paragraph 2.4.10, means of protecting registration information and the possibility of authorized familiarization with this information.

2.4.13. User Guide.

This requirement coincides with the similar requirement of the sixth (paragraph 2.2.4) and fifth (paragraph 2.3.8) classes.

2.4.14. Guide to the KSS.

These requirements fully coincide with the similar requirements of the fifth class (paragraph 2.3.9).

2.4.15. Test documentation.

Shall contain a description of the tests and trials to which the computer equipment was subjected (in accordance with clause 2.4.12) and the test results.

2.4.16. Design (project) documentation.

Shall contain:

general description of the operating principles of the computer equipment;

general diagram of the security system;

description of the external interfaces of the security system and the interfaces of the security system modules;

description of the protection model;

description of the access manager;

description of the integrity control mechanism of the KSS;

description of the memory cleaning mechanism;

description of the mechanism for isolating programs in RAM;

description of the means of protecting input and output to the alienable physical storage medium and matching the user with the device;

description of the identification and authentication mechanism;

description of the registration tools.

2.5. Requirements for indicators of the third security class.

2.5.1. Discretionary access control principle.

These requirements are completely consistent with the requirements of the fifth (clause 2.3.1) and fourth (clause 2.4.1) classes.

2.5.2. Mandatory access control principle.

These requirements are completely consistent with the similar requirement of the fourth class (clause 2.4.2).

2.5.3. Memory cleaning.

For the third class of protection of the computer equipment, the security system must clear the operational and external memory. Clearing must be done by writing masking information to the memory when it is released (redistributed).

2.5.4. Isolation of modules.

These requirements are completely consistent with the similar requirement of the fourth class (clause 2.4.4).

2.5.5. Marking of documents.

These requirements are completely consistent with the similar requirement of the fourth class (clause 2.4.5).

2.5.6. Protection of input and output to an alienable physical information carrier.

These requirements are completely consistent with the similar requirement of the fourth class (clause 2.4.6).

2.5.7. Mapping the user to the device.

These requirements are completely consistent with the similar requirement of the fourth class (clause 2.4.7).

2.5.8. Identification and authentication.

These requirements are fully consistent with the similar requirement of the fourth class (clause 2.4.8).

2.5.9. Design guarantees.

At the initial stage of the design of the security system, a security model must be built that specifies the principle of access control and the access control mechanism. This model must contain:

consistent rules for changing the PRD;

rules for working with input and output devices;

a formal model of the access control mechanism.

A high-level specification of the part of the ISS that implements the access control mechanism and its interfaces must be proposed. This specification must be verified for compliance with the specified access control principles.

2.5.10. Registration.

These requirements are completely consistent with the similar requirement of the fourth class (clause 2.4.10).

2.5.11. User interaction with the ISS.

To ensure the possibility of studying, analyzing, verifying and modifying the ISS, it must be well structured, its structure must be modular and clearly defined. The user and ISS interface must be defined (login, user and ISS requests, etc.). The reliability of such an interface must be ensured. Each user and ISS interface must be logically isolated from other such interfaces.

2.5.12. Reliable Recovery

Recovery procedures after equipment failures and malfunctions must ensure full restoration of the properties of the computer system.

2.5.13. Integrity of the computer system.

It is necessary to periodically monitor the integrity of the computer system.

Programs must be executed in a separate part of the RAM. This requirement must be verified.

2.5.14. Testing.

The computer system must be subject to the same testing as the fourth class computer system (clause 2.4.12).

The following must also be tested:

memory clearing (section 2.5.3);

operation of the reliable recovery mechanism.

2.5.15. User Guide.

These requirements are completely consistent with the similar requirement of the fourth class (section 2.4.13).

2.5.16. KPS Guide.

The document is addressed to the security administrator and must contain:

description of the controlled functions;

guide to generating KPS;

description of the computer equipment start-up, procedures for checking the correctness of the start-up, procedures for working with the registration tools;

guide to reliable recovery tools.

2.5.17. Test documentation

The documentation must provide a description of the tests and trials to which the computer equipment was subjected (clause 2.5.14), as well as the test results.

2.5.18. Design (project) documentation.

The same documentation is required as for the fourth class of SVT (p. 2.4.16). Additionally required:

high-level specification of the SVT and its interfaces;

verification of compliance of the high-level specification of the SVT with the protection model.

2.6. Requirements for the indicators of the second class of protection.

2.6.1. Discretionary principle of access control.

These requirements include similar requirements of the third class (p. 2.5.1).

Additionally, it is required that discretionary access control rules be equivalent to mandatory rules (i.e., every access request must be simultaneously authorized or unauthorized by both discretionary rules and mandatory access control rules).

2.6.2. Mandatory access control principle.

These requirements are completely consistent with the similar requirement of the third class (clause 2.5.2).

2.6.3. Memory cleanup.

These requirements are completely consistent with the similar requirement of the third class (clause 2.5.3).

2.6.4. Isolation of modules.

If the computer system has multiprogramming, the computer security system must have a software and hardware mechanism that isolates the software modules of one process (one subject) from the software modules of other processes (other subjects) — i.e. in the computer's RAM, programs of different users must be isolated from each other. Isolation guarantees must be based on the computer system architecture.

2.6.5. Document marking.

These requirements are completely consistent with the similar requirement of the fourth class (clause 2.5.5).

2.6.6. Protection of input and output to an alienable physical information carrier.

These requirements are completely consistent with the similar requirement of the third class (clause 2.5.6).

2.6.7. User-device mapping.

These requirements fully coincide with the similar requirement of the fourth (clause 2.4.7) and third (clause 2.5.7) classes.

2.6.8. Identification and authentication.

The requirement fully coincides with the similar requirement of the fourth (clause 2.4.8) and third (clause 2.5.8) classes.

2.6.9. Design guarantees.

These requirements include similar requirements of the third class (clause 2.5.9).

Additionally, it is required that high-level specifications of the security protection system be mapped sequentially into specifications of one or more lower levels, down to the implementation of the high-level specification of the security protection system in a high-level programming language. In this case, verification methods must be used to prove the conformity of each such mapping with the specifications of the high (upper for this mapping) level. This process may include either a single mapping (high-level specification — programming language) or a sequence of mappings into intermediate specifications with a decrease in level, down to the programming language. As a result of verification of the conformity of each level with the previous one, conformity of the implementation of the high-level specification of the security protection model shown in the drawing (see Fig. Protection Model Diagram) must be achieved.

2.6.10. Registration.

These requirements are completely consistent with the similar requirement of the fourth (clause 2.4.10) and third (clause 2.5.10) classes.

2.6.11. User interaction with the KPS.

These requirements are completely identical to the similar requirement of the third class (clause 2.5.11).

2.6.12. Reliable recovery.

These requirements are completely identical to the similar requirement of the third class (clause 2.5.12).

2.6.13. Integrity of the KPS.

These requirements are completely identical to the similar requirement of the third class (clause 2.5.13).

2.6.14. Modification control.

When designing, building and maintaining a computer system, configuration management of the computer system must be provided, i.e. control of changes in the formal model, specifications (of different levels), documentation, source text, and version in object code. Correspondence between the documentation and program texts must be ensured. Comparability of generated versions must be carried out. Original programs must be protected.

2.6.15. Distribution control.

The accuracy of copying in the computer equipment must be controlled when making copies from a sample. The copy being made must be guaranteed to repeat the sample.

2.6.16. Testing.

The second class computer equipment must be tested in the same way as the third class computer equipment (p. 2.5.14).

Distribution control must be tested additionally.

2.6.17. User Manual.

These requirements are fully consistent with the similar requirement of the fourth (clause 2.4.13) and third (clause 2.5.15) classes.

2.6.18. Guide to the KPS.

These requirements include similar requirements of the third class (clause 2.5.16).

Guidelines for reliable recovery, for working with modification and distribution control tools must also be provided.

2.6.19. Test documentation.

A description of the tests and trials to which the computer equipment was subjected (clause 2.6.16), as well as the test results, shall be provided.

2.6.20. Design (project) documentation.

The same documentation is required as for class 3 computer equipment (clause 2.5.18).

In addition, the guarantees of the design process and the equivalence of discretionary (clause 2.6.1) and mandatory (clause 2.6.2) PRPs shall be described.

2.7. Requirements for first class security indicators.

2.7.1. Discretionary access control principle.

These requirements fully coincide with the similar requirement of the second class (clause 2.6.1).

2.7.2. Mandatory principle of access control.

These requirements fully coincide with the similar requirement of the second class (clause 2.6.2).

2.7.3. Memory cleaning.

These requirements fully coincide with the similar requirement of the second class (clause 2.6.3).

2.7.4. Isolation of modules.

These requirements are fully consistent with the similar requirement of the second class (clause 2.6.4).

2.7.5. Document marking.

These requirements are fully consistent with the similar requirement of the second class (clause 2.6.5).

2.7.6. Input and output protection on an alienable physical information carrier.

These requirements are fully consistent with the similar requirement of the second class (clause 2.6.6).

2.7.7. User-device mapping.

These requirements fully coincide with the similar requirement of the second class (clause 2.6.7).

2.7.8. Identification and authentication.

These requirements fully coincide with the similar requirement of the second class (clause 2.6.8).

2.7.9. Design guarantees.

These requirements include similar requirements of the second class (clause 2.6.9).

In addition, verification of the conformity of the object code to the text of the KSS in a high-level language is required.

2.7.10. Registration.

These requirements are completely identical to the similar requirement of the second class (clause 2.6.10).

2.7.11. User interaction with the KPS.

These requirements are completely identical to the similar requirement of the second class (clause 2.6.11).

2.7.12. Reliable recovery.

These requirements are completely identical to the similar requirement of the second class (clause 2.6.12).

2.7.13. Integrity of the KPS.

These requirements are fully consistent with the similar requirement of the second class (p.2.6.13).

2.7.14. Modification control.

These requirements are fully consistent with the similar requirement of the second class (p.2.6.14).

2.7.15. Distribution control.

These requirements are fully consistent with the similar requirement of the second class (p.2.6.15).

2.7.16. Architectural guarantees.

The ISS must have a mechanism that guarantees that the access manager intercepts all requests from subjects to objects.

2.7.17. Testing.

These requirements are completely consistent with the similar requirement of the second class (clause 2.6.16).

2.7.18. User Guide.

These requirements are completely consistent with the similar requirement of the second class (clause 2.6.17).

2.7.19. ISS Guide

These requirements are fully consistent with the similar requirement of the second class (clause 2.6.18).

2.7.20. Test documentation

These requirements are fully consistent with the similar requirements of the second class (clause 2.6.19).

2.7.21. Design (project) documentation

The same documentation is required as for the second class computer equipment (clause 2.6.20).

A description of the design process guarantees is additionally developed (clause 2.7.9).

3. ASSESSMENT OF THE SECURITY CLASS OF COMPUTER SYSTEMS (CERTIFICATION OF COMPUTER SYSTEMS)

Assessment of the security class of computer systems is carried out in accordance with the Regulation on the certification of means and systems of computer equipment and communications according to the requirements of information security, the Temporary Regulation on the organization of the development, manufacture and operation of software and hardware means of protecting information from unauthorized access in automated systems and computer systems and other documents.

 

Мы используем cookie-файлы для наилучшего представления нашего сайта. Продолжая использовать этот сайт, вы соглашаетесь с использованием cookie-файлов.
Принять