Lost art proof security. Part 2 of 2
Yuri Pashkov, Kuzma Pashkov - Lead InfoSec , EMC , VMWare trainer @ training.muk.ua
Lost art proof security. Part 1 of 2.
In the first part of the article, the possibilities of an evidence-based approach to the construction of secure automated systems are considered.
')
The cornerstone of an evidence-based approach is the notions of security policy, models of protection, and evidence of security. At the same time, special attention is paid to the concept of a safe policy. The security property is interpreted not as a quantitative, but as a qualitative one — a policy in terms of a specific model can be either safe or not so.
At the intuitive level, the logic of reasoning is as follows: if the formal policy for a model is safe, then the real policy adequate to it will be safe in the conditions of real automated processing.
The sequence of actions in applying the evidence based approach is as follows:
- for the subject area with a known algorithm for processing valuable information, several statements in natural language are formulated, defining the “correct” from the owner’s point of view, the order of processing information values; in other words, a security policy is formulated which, if implemented, is safe (not detrimental to the owner of the information value);
- the policy obtained at the previous stage is formalized in terms of one of the well-studied security models;
- a formal proof of the validity of the assertions of the security policy is carried out. At the same time, necessary and sufficient conditions for executing the policy in terms of the security policy used are identified; as a result of the evidence, the conditions for processing valuable information are revealed under which the requirements of the security policy are fulfilled;
- these policy execution conditions are interpreted for a real automated system and implemented as settings of built-in mechanisms and means of protection.
Thus, when applying the evidence-based approach, interpretation is performed twice - first, the security policy is expressed in terms of the formal protection model, then the security policy conditions obtained during the proof of security are described in terms of the mechanisms and services of the automated system.
5. Interpretation of assumptions and safety conditions
The functional purpose of the majority of modern automated systems is multi-user access from workplaces to large volumes of information (databases). As a rule, the interaction between the components in such speakers is carried out according to the principles of the client-server architecture. For the "client - server" speaker systems, the following logical structure is characteristic:
1) OS of the workstation at which the user works;
2) the client DBMS application running on the workstation and interacting with the server part of the DBMS;
3) AU server OS on which the database and / or shared files are stored;
4) the server part of the DBMS, which is an application running on the server. It performs centralized database processing in accordance with requests from workstations;
5) a communication component that transfers information between the client and server parts of the DBMS. It, in turn, consists of three parts: a communication network that transfers information between the workstation and the database server; communication drivers OS workstation; database server communication drivers.
At the same time, the following hardware components can be distinguished for speakers of this type:
1) a group of PCs that are workstations;
2) a group of computers that are database servers and (or) file servers;
3) a communication network connecting servers and workstations, consisting of equipment of the following types: communication channels, unmanaged network equipment, managed network equipment;
4) storage media: backup copies of databases and software. It should store the reference copy of the information protection tool (hereinafter referred to as GIS), database management systems (hereinafter referred to as DBMS), server OS, workstation OS, and utilities for checking integrity and the checksums calculated with their help. It should also store logs of GIS.
Interpretation of assumptions and safety conditions implies the reinforcement in practice with the help of organizational measures, equipment and software of assumptions 1-5 and conditions 1-3, made in the previous paragraph. However, before installing hardware and configuring software, it is necessary to understand how the model parameters and the features of the automated processing system correlate.
Assumption 1. The assumption that each subject has only one parent is implemented in most operating systems as a process-generation mechanism. At the same time, the OS should support the notion of a subject as a process.
Assumption 2. The assumption that it is possible to model the functioning of the system by a sequence of accesses of the activated subjects of the system to the objects of the system means that the operating system supports, from a certain level of interfaces, the concepts of objects, subjects and accesses. It is clear that these interfaces arise in the process of booting the OS and the processes occurring in real systems during the initial boot before the protection mechanisms are launched fall out of consideration.
Assumption 3. Assumption about the presence of a single administrator and about refusing to transfer their rights to other users can be transformed into organizational measures that should be included in the duties of the administrator.
Assumption 4. No leakage channel of valuable information through shared facilities. This assumption can be implemented by means of the operating system under the control of the administrator.
Assumption 5. Assumption about the order of the system when trying to contact a subject activated on behalf of a certain user to the system object can be implemented by the processor equipment and the operating system security kernel using the so-called reference monitor.
So, if the assumptions are correct and the security policy is respected, unauthorized access is impossible. Consider the conditions under which the security policy can be respected. It turns out that it can be performed under the following conditions:
â– Condition 1 - identification and authentication;
■Condition 2 — the resolving subsystem;
â– Condition 3 - no workarounds.
We now interpret the requirements for security obtained by us in modeling, as applied to an automated system built on the principles of the client-server architecture.
1. Identification and authentication of users. The operating systems of the AU server and workstations must provide identification of users by a unique user identifier of at least 6 characters. For user authentication, a conditional-permanent password of at least 6 characters must be used. The password should be set by the administrator of the AC server in such a way that its easy guessing is excluded.
When establishing a user session with the operating system OS, the user ID and password should be requested. When establishing a user session with the server, the user ID and password should be requested. When establishing a user session with the database server, the user ID and password should be requested. User password should not be stored in a file on the workstation. It must be protected from disclosure during transmission over the network.
2. Permissive subsystem. The servers, network equipment and workstations of the system must have the access control system enabled, preventing the unauthorized access to the information to which this user does not have access rights, and allowing access to the information to which the user should have access.
3. Lack of detours. All access to information must be conducted through the permitting subsystem. To ensure that this condition is met, the use of audit trails and periodic monitoring of the integrity of system components is recommended. The server OS of the AS should register the establishment and termination of a user session with the OS in files accessible only by the server administrator (it is better to appoint a system auditor for these purposes, and the administrator should not allow access to audit logs). The operating system of the workstation must perform the registration of the establishment and termination of the user's session with the workstation.
The operating system of the AU server must register the establishment and termination of the user's session with the AU server. The server part of the DBMS must register the establishment and termination of the user's session with the database in files accessible only to the server administrator. The registration parameters shall include: the time and date of entry / exit of the subject of access to the system (from the system) or the system shutdown load; the result of an attempt to enter: successful or unsuccessful - unauthorized; The identifier (code or surname) of the subject presented when attempting to access.
All protected media should be counted by any marking. Accounting for protected media should be carried out in a journal (card file) with the registration of their issue / reception. The system should not be able to access a standard user to the means of modifying the program code of the system components. Access control should be provided to the premises where the system funds are located.
6. Implementation of the security policy of the OS information security tools
However, the presence of OS mechanisms that implement conditions conducive to the implementation of a security policy does not guarantee that these mechanisms will be properly configured by the administrator. Therefore, it is important to question the practical implementation of the interpretation of specific policies and rules of access control. Only after all the configuration steps have been completed, the main idea of ​​building a secure automated system is implemented. Thus, another interpretation of the access control rules established in the organization is performed now with the security features built into the OS.
7. Conclusions
Recently, much attention has been paid to the problems of building automated systems in a protected version. There are several conceptual approaches to solving these problems. The first was an approach based on risk analysis of processing valuable data. Then the development received a regulatory approach to building information security systems. The evidence-based approach is intermediate between the risk-based approach and the normative one.
This article has demonstrated the capabilities of an evidence-based approach for creating secure automated systems. The disadvantage of the evidence-based approach is the need to model a specific AS and the information protection policy adopted by the organization. However, the properties of the model are such that in more detailed than the above modeling of the operating system, it will turn out that the conditions for the enforceability of security policies for different organizations will be the same.
In other words, the conditions of theorems proving support for a security policy (including the corresponding policy) can be formulated without proof in the form of a standard. This approach was first used by Americans in 1983 by publishing a draft standard for information security in the EESOD (“Orange Book”), which formulated the requirements of guaranteed support for two classes of policies - discretionary and MLS policies. They then applied this method in 1987 to describe guaranteed secure distributed networks that support the same policies, and in 1991 to describe the requirements of guaranteed secure databases. Based on this method, a regulatory approach to building information security systems was created.
The model presented in the article is educational in nature and can be used to explain the features of building modern information protection systems.
To be continued. We are waiting for questions on training and certification of CISSP / CISM / CISA / Security + at PashkovK@muk.com.ua
Training courses on information security, which is conducted by the author of the article (TC MUK - Kiev)
Nearest information security courses at TC MUK (Kiev)
January 18 - 22, 2016 MUK-S0101 SecurityPlus
February 1 - 5, 2016 MUK-S0102 CISA
February 22-26, 2016 MUK-S0105 CISSP / CISM 2015
Lost art proof security. Part 1 of 2.
In the first part of the article, the possibilities of an evidence-based approach to the construction of secure automated systems are considered.
')
The cornerstone of an evidence-based approach is the notions of security policy, models of protection, and evidence of security. At the same time, special attention is paid to the concept of a safe policy. The security property is interpreted not as a quantitative, but as a qualitative one — a policy in terms of a specific model can be either safe or not so.
At the intuitive level, the logic of reasoning is as follows: if the formal policy for a model is safe, then the real policy adequate to it will be safe in the conditions of real automated processing.
The sequence of actions in applying the evidence based approach is as follows:
- for the subject area with a known algorithm for processing valuable information, several statements in natural language are formulated, defining the “correct” from the owner’s point of view, the order of processing information values; in other words, a security policy is formulated which, if implemented, is safe (not detrimental to the owner of the information value);
- the policy obtained at the previous stage is formalized in terms of one of the well-studied security models;
- a formal proof of the validity of the assertions of the security policy is carried out. At the same time, necessary and sufficient conditions for executing the policy in terms of the security policy used are identified; as a result of the evidence, the conditions for processing valuable information are revealed under which the requirements of the security policy are fulfilled;
- these policy execution conditions are interpreted for a real automated system and implemented as settings of built-in mechanisms and means of protection.
Thus, when applying the evidence-based approach, interpretation is performed twice - first, the security policy is expressed in terms of the formal protection model, then the security policy conditions obtained during the proof of security are described in terms of the mechanisms and services of the automated system.
5. Interpretation of assumptions and safety conditions
The functional purpose of the majority of modern automated systems is multi-user access from workplaces to large volumes of information (databases). As a rule, the interaction between the components in such speakers is carried out according to the principles of the client-server architecture. For the "client - server" speaker systems, the following logical structure is characteristic:
1) OS of the workstation at which the user works;
2) the client DBMS application running on the workstation and interacting with the server part of the DBMS;
3) AU server OS on which the database and / or shared files are stored;
4) the server part of the DBMS, which is an application running on the server. It performs centralized database processing in accordance with requests from workstations;
5) a communication component that transfers information between the client and server parts of the DBMS. It, in turn, consists of three parts: a communication network that transfers information between the workstation and the database server; communication drivers OS workstation; database server communication drivers.
At the same time, the following hardware components can be distinguished for speakers of this type:
1) a group of PCs that are workstations;
2) a group of computers that are database servers and (or) file servers;
3) a communication network connecting servers and workstations, consisting of equipment of the following types: communication channels, unmanaged network equipment, managed network equipment;
4) storage media: backup copies of databases and software. It should store the reference copy of the information protection tool (hereinafter referred to as GIS), database management systems (hereinafter referred to as DBMS), server OS, workstation OS, and utilities for checking integrity and the checksums calculated with their help. It should also store logs of GIS.
Interpretation of assumptions and safety conditions implies the reinforcement in practice with the help of organizational measures, equipment and software of assumptions 1-5 and conditions 1-3, made in the previous paragraph. However, before installing hardware and configuring software, it is necessary to understand how the model parameters and the features of the automated processing system correlate.
Assumption 1. The assumption that each subject has only one parent is implemented in most operating systems as a process-generation mechanism. At the same time, the OS should support the notion of a subject as a process.
Assumption 2. The assumption that it is possible to model the functioning of the system by a sequence of accesses of the activated subjects of the system to the objects of the system means that the operating system supports, from a certain level of interfaces, the concepts of objects, subjects and accesses. It is clear that these interfaces arise in the process of booting the OS and the processes occurring in real systems during the initial boot before the protection mechanisms are launched fall out of consideration.
Assumption 3. Assumption about the presence of a single administrator and about refusing to transfer their rights to other users can be transformed into organizational measures that should be included in the duties of the administrator.
Assumption 4. No leakage channel of valuable information through shared facilities. This assumption can be implemented by means of the operating system under the control of the administrator.
Assumption 5. Assumption about the order of the system when trying to contact a subject activated on behalf of a certain user to the system object can be implemented by the processor equipment and the operating system security kernel using the so-called reference monitor.
So, if the assumptions are correct and the security policy is respected, unauthorized access is impossible. Consider the conditions under which the security policy can be respected. It turns out that it can be performed under the following conditions:
â– Condition 1 - identification and authentication;
■Condition 2 — the resolving subsystem;
â– Condition 3 - no workarounds.
We now interpret the requirements for security obtained by us in modeling, as applied to an automated system built on the principles of the client-server architecture.
1. Identification and authentication of users. The operating systems of the AU server and workstations must provide identification of users by a unique user identifier of at least 6 characters. For user authentication, a conditional-permanent password of at least 6 characters must be used. The password should be set by the administrator of the AC server in such a way that its easy guessing is excluded.
When establishing a user session with the operating system OS, the user ID and password should be requested. When establishing a user session with the server, the user ID and password should be requested. When establishing a user session with the database server, the user ID and password should be requested. User password should not be stored in a file on the workstation. It must be protected from disclosure during transmission over the network.
2. Permissive subsystem. The servers, network equipment and workstations of the system must have the access control system enabled, preventing the unauthorized access to the information to which this user does not have access rights, and allowing access to the information to which the user should have access.
3. Lack of detours. All access to information must be conducted through the permitting subsystem. To ensure that this condition is met, the use of audit trails and periodic monitoring of the integrity of system components is recommended. The server OS of the AS should register the establishment and termination of a user session with the OS in files accessible only by the server administrator (it is better to appoint a system auditor for these purposes, and the administrator should not allow access to audit logs). The operating system of the workstation must perform the registration of the establishment and termination of the user's session with the workstation.
The operating system of the AU server must register the establishment and termination of the user's session with the AU server. The server part of the DBMS must register the establishment and termination of the user's session with the database in files accessible only to the server administrator. The registration parameters shall include: the time and date of entry / exit of the subject of access to the system (from the system) or the system shutdown load; the result of an attempt to enter: successful or unsuccessful - unauthorized; The identifier (code or surname) of the subject presented when attempting to access.
All protected media should be counted by any marking. Accounting for protected media should be carried out in a journal (card file) with the registration of their issue / reception. The system should not be able to access a standard user to the means of modifying the program code of the system components. Access control should be provided to the premises where the system funds are located.
6. Implementation of the security policy of the OS information security tools
However, the presence of OS mechanisms that implement conditions conducive to the implementation of a security policy does not guarantee that these mechanisms will be properly configured by the administrator. Therefore, it is important to question the practical implementation of the interpretation of specific policies and rules of access control. Only after all the configuration steps have been completed, the main idea of ​​building a secure automated system is implemented. Thus, another interpretation of the access control rules established in the organization is performed now with the security features built into the OS.
7. Conclusions
Recently, much attention has been paid to the problems of building automated systems in a protected version. There are several conceptual approaches to solving these problems. The first was an approach based on risk analysis of processing valuable data. Then the development received a regulatory approach to building information security systems. The evidence-based approach is intermediate between the risk-based approach and the normative one.
This article has demonstrated the capabilities of an evidence-based approach for creating secure automated systems. The disadvantage of the evidence-based approach is the need to model a specific AS and the information protection policy adopted by the organization. However, the properties of the model are such that in more detailed than the above modeling of the operating system, it will turn out that the conditions for the enforceability of security policies for different organizations will be the same.
In other words, the conditions of theorems proving support for a security policy (including the corresponding policy) can be formulated without proof in the form of a standard. This approach was first used by Americans in 1983 by publishing a draft standard for information security in the EESOD (“Orange Book”), which formulated the requirements of guaranteed support for two classes of policies - discretionary and MLS policies. They then applied this method in 1987 to describe guaranteed secure distributed networks that support the same policies, and in 1991 to describe the requirements of guaranteed secure databases. Based on this method, a regulatory approach to building information security systems was created.
The model presented in the article is educational in nature and can be used to explain the features of building modern information protection systems.
To be continued. We are waiting for questions on training and certification of CISSP / CISM / CISA / Security + at PashkovK@muk.com.ua
Training courses on information security, which is conducted by the author of the article (TC MUK - Kiev)
Nearest information security courses at TC MUK (Kiev)
January 18 - 22, 2016 MUK-S0101 SecurityPlus
February 1 - 5, 2016 MUK-S0102 CISA
February 22-26, 2016 MUK-S0105 CISSP / CISM 2015
Source: https://habr.com/ru/post/273977/
All Articles