December 30, 2015 at 13:08Lost art of proof of security. Part 2 of 2
Yuri Pashkov, Kuzma Pashkov - Lead InfoSec , EMC , VMWare trainer @ training.muk.ua
Lost art of proof of security. Part 1 of 2.
The first part of the article discusses the possibilities of an evidence-based approach to building secure automated systems.
The cornerstone of the evidence-based approach is the concepts of security policy, security models and evidence of security. Special attention is paid to the concept of safe policy. The security property is not interpreted as quantitative, but as qualitative - a policy in terms of a specific model can be either safe or not.
At an intuitive level, the logic of reasoning is as follows: if the formal policy for the model is safe, then an adequate real policy in the conditions of real automated processing will also be safe.
The sequence of actions when applying the evidence-based approach is as follows:
- for a subject area with a well-known valuable information processing algorithm, several statements in a natural language are formulated that determine the “correct” order of processing information values from the owner’s point of view; in other words, a security policy is formulated which, if implemented, is safe (without prejudice to the owner of information value);
- The policy obtained at the previous stage is formalized in terms of one of the well-studied security models;
- formal proof of the feasibility of security policy statements is performed. In this case, the necessary and sufficient conditions for the implementation of the policy are identified in terms of the security policy used; as a result of the evidence, the conditions for the processing of valuable information are identified under which the requirements of the security policy are feasible;
- These conditions for the implementation of the policy are interpreted for a real automated system and are implemented in the form of settings of built-in mechanisms and means of protection.
Thus, when applying the evidence-based approach, the interpretation is performed twice - first, in terms of the formal model of protection, the security policy is expressed, then in terms of the mechanisms and services of the automated system the security conditions of the policy obtained during the proof of security are described.
5. Interpretation of assumptions and security conditions The
functional purpose of most modern automated systems is multi-user access from workstations to large amounts of information (databases). As a rule, the interaction between components in such AS is carried out according to the principles of the client-server architecture. The following logical structure is typical for a client-server AS:
1) the OS of the workstation for which the AS user is working;
2) a DBMS client application running on a workstation and interacting with the server part of the DBMS;
3) OS server OS, which stores the database and (or) shared files;
4) the server part of the DBMS, which is the 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 of the workstation OS; database server communication drivers.
At the same time, the following hardware components can be distinguished for speakers of this type:
1) a group of personal computers 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 the following types of equipment: communication channels, unmanaged network equipment, managed network equipment;
4) storage of information media: backup copies of databases and software. It should store a reference copy of the information protection tool (hereinafter referred to as SZI), a database management system (hereinafter referred to as the DBMS), server OS, workstation OS, as well as utilities for checking integrity and checksums calculated using them. It should also store the logs of registration of SZI.
Interpretation of assumptions and safety conditions involves 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 the equipment and configuring software, it is necessary to understand how the model parameters relate to the features of the automated processing system.
Assumption 1. The assumption that each entity has only one parent is implemented in most operating systems in the form of a process generation mechanism. In this case, the OS must support the concept of the subject as a process.
Assumption 2. The assumption that it is possible to simulate the functioning of the system by the sequence of accesses of the activated subjects of the system to the objects of the system means that the operating system supports, starting from a certain level of interfaces, the concepts of objects, subjects and accesses. It is clear that these interfaces arise in the process of loading the OS and the processes that occur in real systems during the initial boot before the protection mechanisms are launched fall out of consideration.
Assumption 3. The assumption of the presence of a single administrator and the refusal to transfer the rights to other users can be transformed into organizational measures, which must be included in the duties of the administrator.
Assumption 4. The absence of a leak 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. An assumption about the system’s operation when trying to contact a subject, activated on behalf of a user, to a system object can be implemented by the processor equipment and the operating system security kernel using the so-called link monitor.
So, if the assumptions are correct and the security policy is followed, then unauthorized access is impossible. Consider the conditions under which a security policy can be followed. It turns out that it can be fulfilled if the following conditions are met :
■ condition 1 - identification and authentication;
■ condition 2 — permitting subsystem;
■ Condition 3 — No workarounds.
We now interpret the security requirements that we obtained during the simulation, as applied to an automated system built on the principles of a client-server architecture.
1. Identification and authentication of users. The operating systems of the AS server and workstations should provide user identification by a unique user identifier of at least 6 characters. For authentication of users, a password of conditionally permanent action must be used with a length of at least 6 characters. The password must be set by the administrator of the AS server in such a way that its easy guessing is excluded.
When establishing a user session from the workstation OS, the user ID and password must be requested. When establishing a user session with the AS server, the user ID and password should be requested. When establishing a user session with the database server, the user ID and password must be requested. The user password should not be stored in a file on the workstation. It must be protected against disclosure when transmitting over a network.
2. The permission subsystem. Servers, network equipment and workstations of the system must have an access control system for access to information enabled, not allowing NSD to access information to which this user does not have access rights, and allowing access to information to which the user should have access.
3. Lack of workarounds. All access to information should be through the licensing subsystem. To ensure compliance with this condition, the use of audit trails and periodic monitoring of the integrity of system components are recommended. The AS server OS must register the establishment and termination of the user session with the OS in files accessible only to the server administrator (it is better to appoint a system auditor for this purpose, and the administrator should not be allowed access to audit logs). The operating system of the workstation must register the establishment and termination of a user session with the workstation.
The operating system of the AU server should register the establishment and termination of a user session with the AU server. The server part of the DBMS must register the establishment and termination of the user session with the database in files accessible only to the server administrator. The registration parameters indicate: the time and date of entry / exit of the subject of access to the system (from the system) or loading of the system shutdown; the result of the login attempt: successful or unsuccessful - unauthorized; the identifier (code or surname) of the subject presented upon access.
All protected media must be accounted for using any labeling. Accounting for protected media should be carried out in a journal (card index) with the registration of their issuance / reception. The system should not have the ability to gain ordinary user access to means of modifying the program code of system components. Differentiation of access to the premises where the funds of the system are located should be carried out.
6. Implementation of security policies by means of OS information protection
However, the presence of OS mechanisms that implement conditions conducive to the implementation of security policies does not guarantee that these mechanisms will be correctly configured by the administrator. Therefore, the important issue is the practical implementation of the interpretation of specific policies and rules for access control. Only after completing all the configuration steps is the main idea for building a secure automated system realized. Thus, one more interpretation of the rules of access control established by the organization is now performed by the security tools built into the OS.
7. Conclusions
Recently, much attention has been paid to the problems of building automated systems in a secure execution. There are several conceptual approaches to solving these problems. The first was an approach based on risk analysis of the processing of valuable data. Then the development received a normative 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 to creating secure automated systems. The disadvantage of the evidence-based approach is the need to model a specific AS and information security policies adopted by the organization. However, the properties of the model are such that with a more detailed simulation of the operating system than the above, it turns out that the conditions for the fulfillment 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 the Americans in 1983, when they published a draft standard for information security in the ESOD (Orange Book), which formulated the requirements for guaranteed support for two classes of policies - discretionary and MLS. Then they used 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 normative approach to the construction of information protection systems was created.
The model presented in the article is training nature and can be used to explain the features of the construction of 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
The information security training courses taught by the author of the article (CC MUK - Kiev)
The nearest information security courses in the CC MUK (Kiev)
January 18 - 22, 2016 MUK-S0101 SecurityPlus
February 1 - 5, 2016 CIS MUK-S0102
February 22-26, 2016 MUK -S0105 CISSP / CISM 2015
Lost art of proof of security. Part 1 of 2.
The first part of the article discusses the possibilities of an evidence-based approach to building secure automated systems.
The cornerstone of the evidence-based approach is the concepts of security policy, security models and evidence of security. Special attention is paid to the concept of safe policy. The security property is not interpreted as quantitative, but as qualitative - a policy in terms of a specific model can be either safe or not.
At an intuitive level, the logic of reasoning is as follows: if the formal policy for the model is safe, then an adequate real policy in the conditions of real automated processing will also be safe.
The sequence of actions when applying the evidence-based approach is as follows:
- for a subject area with a well-known valuable information processing algorithm, several statements in a natural language are formulated that determine the “correct” order of processing information values from the owner’s point of view; in other words, a security policy is formulated which, if implemented, is safe (without prejudice to the owner of information value);
- The policy obtained at the previous stage is formalized in terms of one of the well-studied security models;
- formal proof of the feasibility of security policy statements is performed. In this case, the necessary and sufficient conditions for the implementation of the policy are identified in terms of the security policy used; as a result of the evidence, the conditions for the processing of valuable information are identified under which the requirements of the security policy are feasible;
- These conditions for the implementation of the policy are interpreted for a real automated system and are implemented in the form of settings of built-in mechanisms and means of protection.
Thus, when applying the evidence-based approach, the interpretation is performed twice - first, in terms of the formal model of protection, the security policy is expressed, then in terms of the mechanisms and services of the automated system the security conditions of the policy obtained during the proof of security are described.
5. Interpretation of assumptions and security conditions The
functional purpose of most modern automated systems is multi-user access from workstations to large amounts of information (databases). As a rule, the interaction between components in such AS is carried out according to the principles of the client-server architecture. The following logical structure is typical for a client-server AS:
1) the OS of the workstation for which the AS user is working;
2) a DBMS client application running on a workstation and interacting with the server part of the DBMS;
3) OS server OS, which stores the database and (or) shared files;
4) the server part of the DBMS, which is the 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 of the workstation OS; database server communication drivers.
At the same time, the following hardware components can be distinguished for speakers of this type:
1) a group of personal computers 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 the following types of equipment: communication channels, unmanaged network equipment, managed network equipment;
4) storage of information media: backup copies of databases and software. It should store a reference copy of the information protection tool (hereinafter referred to as SZI), a database management system (hereinafter referred to as the DBMS), server OS, workstation OS, as well as utilities for checking integrity and checksums calculated using them. It should also store the logs of registration of SZI.
Interpretation of assumptions and safety conditions involves 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 the equipment and configuring software, it is necessary to understand how the model parameters relate to the features of the automated processing system.
Assumption 1. The assumption that each entity has only one parent is implemented in most operating systems in the form of a process generation mechanism. In this case, the OS must support the concept of the subject as a process.
Assumption 2. The assumption that it is possible to simulate the functioning of the system by the sequence of accesses of the activated subjects of the system to the objects of the system means that the operating system supports, starting from a certain level of interfaces, the concepts of objects, subjects and accesses. It is clear that these interfaces arise in the process of loading the OS and the processes that occur in real systems during the initial boot before the protection mechanisms are launched fall out of consideration.
Assumption 3. The assumption of the presence of a single administrator and the refusal to transfer the rights to other users can be transformed into organizational measures, which must be included in the duties of the administrator.
Assumption 4. The absence of a leak 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. An assumption about the system’s operation when trying to contact a subject, activated on behalf of a user, to a system object can be implemented by the processor equipment and the operating system security kernel using the so-called link monitor.
So, if the assumptions are correct and the security policy is followed, then unauthorized access is impossible. Consider the conditions under which a security policy can be followed. It turns out that it can be fulfilled if the following conditions are met :
■ condition 1 - identification and authentication;
■ condition 2 — permitting subsystem;
■ Condition 3 — No workarounds.
We now interpret the security requirements that we obtained during the simulation, as applied to an automated system built on the principles of a client-server architecture.
1. Identification and authentication of users. The operating systems of the AS server and workstations should provide user identification by a unique user identifier of at least 6 characters. For authentication of users, a password of conditionally permanent action must be used with a length of at least 6 characters. The password must be set by the administrator of the AS server in such a way that its easy guessing is excluded.
When establishing a user session from the workstation OS, the user ID and password must be requested. When establishing a user session with the AS server, the user ID and password should be requested. When establishing a user session with the database server, the user ID and password must be requested. The user password should not be stored in a file on the workstation. It must be protected against disclosure when transmitting over a network.
2. The permission subsystem. Servers, network equipment and workstations of the system must have an access control system for access to information enabled, not allowing NSD to access information to which this user does not have access rights, and allowing access to information to which the user should have access.
3. Lack of workarounds. All access to information should be through the licensing subsystem. To ensure compliance with this condition, the use of audit trails and periodic monitoring of the integrity of system components are recommended. The AS server OS must register the establishment and termination of the user session with the OS in files accessible only to the server administrator (it is better to appoint a system auditor for this purpose, and the administrator should not be allowed access to audit logs). The operating system of the workstation must register the establishment and termination of a user session with the workstation.
The operating system of the AU server should register the establishment and termination of a user session with the AU server. The server part of the DBMS must register the establishment and termination of the user session with the database in files accessible only to the server administrator. The registration parameters indicate: the time and date of entry / exit of the subject of access to the system (from the system) or loading of the system shutdown; the result of the login attempt: successful or unsuccessful - unauthorized; the identifier (code or surname) of the subject presented upon access.
All protected media must be accounted for using any labeling. Accounting for protected media should be carried out in a journal (card index) with the registration of their issuance / reception. The system should not have the ability to gain ordinary user access to means of modifying the program code of system components. Differentiation of access to the premises where the funds of the system are located should be carried out.
6. Implementation of security policies by means of OS information protection
However, the presence of OS mechanisms that implement conditions conducive to the implementation of security policies does not guarantee that these mechanisms will be correctly configured by the administrator. Therefore, the important issue is the practical implementation of the interpretation of specific policies and rules for access control. Only after completing all the configuration steps is the main idea for building a secure automated system realized. Thus, one more interpretation of the rules of access control established by the organization is now performed by the security tools built into the OS.
7. Conclusions
Recently, much attention has been paid to the problems of building automated systems in a secure execution. There are several conceptual approaches to solving these problems. The first was an approach based on risk analysis of the processing of valuable data. Then the development received a normative 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 to creating secure automated systems. The disadvantage of the evidence-based approach is the need to model a specific AS and information security policies adopted by the organization. However, the properties of the model are such that with a more detailed simulation of the operating system than the above, it turns out that the conditions for the fulfillment 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 the Americans in 1983, when they published a draft standard for information security in the ESOD (Orange Book), which formulated the requirements for guaranteed support for two classes of policies - discretionary and MLS. Then they used 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 normative approach to the construction of information protection systems was created.
The model presented in the article is training nature and can be used to explain the features of the construction of 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
The information security training courses taught by the author of the article (CC MUK - Kiev)
The nearest information security courses in the CC MUK (Kiev)
January 18 - 22, 2016 MUK-S0101 SecurityPlus
February 1 - 5, 2016 CIS MUK-S0102
February 22-26, 2016 MUK -S0105 CISSP / CISM 2015