Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Information protection in digital communication systems. Textbook
.pdf
151
structured into elements that are safety-critical and non-critical. The TCB
interface must be well defined and its design and final product must be fully
verified and tested. The audit mechanism must be strengthened and control
over the system configuration must be introduced. The system must be
resistant to external penetration.
Security policy. In addition to B1, all system resources that are directly
or indirectly accessible to subjects must be marked. A trusted computing
base should immediately notify the terminal user when its security label
changes. The user can request information about their tag. A trusted
computing foundation must support assigning minimum and maximum
privacy levels to all connected physical devices. These levels should be used
when enforcing constraints imposed by the physical configuration of the
system (e.g. device placement).
All system resources (including ROM, I/O devices) must have security
labels and be subject to enforced access control.
Accountability. A trusted computing base must maintain a reliable
communication path to itself for the user performing initial identification
and authentication operations. The initiative in communication along this
path should come exclusively from the user. In addition to B1, it should be
possible to record events related to the organization of secret memory
channels.
Guarantees. In addition to B1, a robust computing base must be
internally structured into well-defined, relatively independent modules. A
robust computing foundation must effectively use existing hardware to
separate security-critical elements from other system components. Base
modules should be designed taking into account the principle of minimizing
privileges. Hardware measures such as segmentation must be used to protect
logically separate stored objects. The user interface to the reliable
computing base and all base elements must be fully defined.
The system architect must carefully analyze the possibilities for
organizing secret memory channels and evaluate the maximum throughput
of each identified channel.
152
The system must support separation of operator and administrator
functions.
In addition to B1, the relative resistance of the trusted computing base
to intrusion attempts must be demonstrated. The security policy model must
be formal. For a reliable computing base to exist, there must be top-level
descriptive specifications that accurately and completely define its interface.
In the process of developing and maintaining a reliable computing
base, a configuration management system should be used to provide control
over changes in top-level descriptive specifications, other architectural data,
implementation documentation, source code, running version of object
code, test data and documentation. Configuration management must ensure
that all aspects of the current version of the trusted computing base are
consistent with each other. There should be a means of generating new
versions of the database from source code and a means of comparing
versions to ensure that only the intended changes have been made.
Documentation. In addition to B1, modules of a reliable computing
base containing mechanisms for checking requests must be specified. The
procedure for safely generating a new version of the database after making
changes to the source texts must be described.
In addition to C1, tests must confirm the effectiveness of measures to
reduce the capacity of secret information transmission channels.
The security policy model must be formal and evidence-based. The
top-level descriptive specifications must be shown to accurately reflect the
interface of the trusted computing base. It should be shown how the database
implements the concept of a call monitor, why it is resistant to attempts to
monitor its operation, why it cannot be bypassed, and why it is implemented
correctly. The structure of the database should be described to facilitate its
testing and verification of compliance with the principle of minimizing
privileges. The documentation should contain the results of the analysis of
secret information transmission channels and a description of logging
measures that help identify channels with memory.
153
Class B3. Security domains. In class B3 systems, TCB must satisfy all
the requirements of the previous class and additionally the requirements of
a link monitor, which:
• must be protected from unauthorized modification or damage;
• must process all requests;
• must be easy to analyze and test.
The TCB must be structured in such a way as to exclude code that is
not relevant to the security of the system. Additionally the following must
be provided:
• security administrator support;
• expansion of the audit mechanism to signal any security-related
events;
• support for system recovery procedures.
Security policy. In addition to C2, access control lists indicating the
allowed modes must be used. It must be possible to explicitly specify users
or their groups whose access to an object is prohibited.
Accountability. In addition to B2, a reliable communication path can
be formed based on a request coming from both the user and the base itself.
The trusted path can be used for initial identification and authentication, to
change the user’s current security label, etc. Communication over the trusted
path must be logically separated and isolated from other information flows.
It must be possible to record the occurrence or accumulation of events that
pose a threat to the system’s security policy.
The security administrator must be notified immediately of attempts
to violate the security policy. And the system, if attempts continue, should
stop them in the least painful way.
Guarantees. In addition to B2, a trusted computing framework must
be designed and structured to use a complete and conceptually simple
security mechanism with well-defined semantics. This mechanism must
play a central role in the internal structuring of the reliable computing base
and the entire system. The database must actively use layering, abstraction,
and data encapsulation. Significant engineering effort must be devoted to
154
reducing the complexity of the trusted computing base and removing
modules that are not security critical.
The Security Administrator role must be specified. You can obtain
security administrator rights only after performing explicit, logged actions.
Non-security activities of the security administrator should be limited as
much as possible.
Procedures and/or mechanisms must be in place to allow recovery
from a failure or other disruption without compromising security.
The robust computing base must be demonstrated to be resilient to
intrusion attempts. No architectural deficiencies should be identified. Only
a small number of correctable implementation deficiencies may be
identified. There must be reasonable confidence that few deficiencies
remain undetected.
Documentation. The Administrator’s Security Guidance, in addition
to B2, should describe a procedure to ensure that the system is initially
started safely and can be resumed after a failure. The correspondence
between the top-level descriptive specifications and the implementation of
a robust computing framework must be informally demonstrated.
Group A. Verified protection.
This group is characterized by the use of formal methods of
verification and the correct operation of access control mechanisms
(discretionary and mandatory). It is required that the compliance of the TCB
architecture and implementation with security requirements be formally
demonstrated.
Class A1. Formal verification. The A1 class protection criterion does
not define additional requirements for the architecture or security policy of
a computer system compared to class ВЗ. An additional feature of systems
classified as Class A1 is the analysis of the TSV for compliance with formal
high-level specifications and the use of verification technologies in order to
obtain high guarantees that the TCB is functioning correctly.
The most important requirements for class A1 can be grouped into
five groups:
155
1. The formal model of the security policy must be clearly defined and
documented, and mathematical proof must be given that the model meets its
axioms and that they are sufficient to support the specified security policy.
2. The formal high-level specification must include an abstract
definition of the functions performed by the TCB and a hardware and/or
embedded software mechanism to ensure domain separation.
3. The formal high-level specification of the TCB must demonstrate
compliance with the security policy model, using formal technology where
possible (for example, where verification tools are available) and informal
technology in all other cases.
4. The opposite should also be informally shown — the
correspondence of TCB elements to the formal high-level specification. The
formal high-level specification should be a generic security mechanism that
implements the security policy. The elements of this mechanism must be
mapped to the elements of the TCB.
5. Formal technologies should be used to identify and analyze covert
channels. Informal technology can be used to analyze hidden time channels.
The existence of hidden channels remaining in the system must be justified.
More stringent requirements are imposed on system configuration
management and the specific location (deployment) of the system.
The listed requirements do not affect the Security Policy and
Accountability groups and are concentrated in the Guarantees group with a
corresponding description in the Documentation group.
5.2. CONCEPTS OF PROTECTION OF DCS AND COMPUTING
EQUIPMENT ACCORDING TO GUIDANCE DOCUMENTS
OF THE RUSSIAN FEDERATION’S STATE TECHNICAL COMMISSION
In 1992, the State Technical Commission (STC) under the President
of the Russian Federation developed and published five guidance
documents [9] devoted to the issues of information protection in automated
systems (AS) for its processing. The basis of these documents is the concept
156
of protecting computer equipment (CE) and AS from unauthorized access
to information, containing the State Customs Committee’s system of views
on the problem of information security and the basic principles of protecting
computer systems. From the point of view of the developers of these
documents, the main task of security tools is to provide protection against
unauthorized access to information. A certain bias towards maintaining the
secrecy of information is explained by the fact that these documents were
developed with the expectation of being used in the information systems of
law enforcement agencies of the Russian Federation.
Security requirements structure
The governing documents of the State Customs Committee consist of
five parts:
1. Protection against unauthorized access to information. Terms and
Definitions.
2. The concept of protecting CE and AS from unauthorized access to
information.
3. Automated systems. Protection against unauthorized access to
information. Classification of automated systems and requirements for
information protection.
4. Computer facilities. Protection against unauthorized access to
information. Indicators of security from unauthorized access to information.
5. Temporary regulations on organizing the development, production
and operation of software and hardware for protecting information from
unauthorized access in automated systems and computer equipment.
The second, third and fourth parts are of greatest interest. The second
part sets out a system of views and basic principles that form the basis of the
problem of protecting information from unauthorized access. The governing
documents of the State Customs Committee propose two groups of security
requirements — indicators of the security of electronic equipment from
unauthorized access and criteria for the security of data processing systems.
The first group makes it possible to assess the degree of security of the AS
157
components separately supplied to the consumer and is discussed in the
fourth part, and the second is designed for more complex complexes,
including several units of electronic equipment, and is presented in the third
part of the guidance documents.
AS protection classes
The third part of the governing documents of the State Customs
Committee provides a classification of AS and requirements for information
protection in AS of various classes. This determines:
1. Main stages of classification of AS:
• development and analysis of initial data;
• identification of the main signs of AS necessary for classification;
• comparison of identified signs of AS with classified ones;
• assignment of the appropriate class of information protection against
unauthorized access to the AS.
2. Necessary initial data for classifying a specific AS:
• list of protected AS information resources and their level of
confidentiality;
• list of persons who have access to standard AS facilities, indicating
their level of authority;
• matrix of access or powers of access subjects in relation to the
protected information resources of the AS;
• data processing mode in the AS.
3. Signs by which AS are grouped into various classes:
• availability of information of various levels of confidentiality in the AS;
• level of authority of AS access subjects to access confidential
information;
• data processing mode in the AS: collective or individual.
The State Customs Committee documents establish nine classes of UA
protection of systems, distributed into three groups. Each class is
characterized by a certain set of requirements for protective equipment.
Within each group, a hierarchy of AS security classes is observed. The class
158
corresponding to the highest degree of security for a given group is
designated by the index NA, where N is the group number (from 1 to 3).
The next class is designated NB, etc.
The third group includes systems in which one user operates and has
access to all information in the system located on media of the same
confidentiality level. The group contains two classes — 3B and 3A.
The second group includes systems in which users have the same
access rights to all information processed and stored in the system on media
with varying levels of confidentiality. The group contains two classes — 2B
and 2A.
The first group includes multi-user systems in which information of
different levels of confidentiality is simultaneously processed and stored.
Not all users have equal access rights. The group contains five classes —
1D, 1 G, 1 B, 1B and 1A.
The development of these documents was most influenced by the
TCSEC criterion (Orange Book), but this influence is mainly reflected in
the focus of these documents on the protected systems of law enforcement
agencies and in the use of a single universal scale for assessing the degree
of security.
The shortcomings of the State Customs Committee’s governing
documents include: a focus on counteracting illegal activities and the lack
of requirements for the adequacy of the implementation of the security
policy. The concept of “security policy” is interpreted exclusively as
maintaining a regime of secrecy and the absence of unauthorized access.
Because of this, security measures are focused only on countering external
threats, and there are no clear requirements for the structure of the system
itself and its functioning. The ranking of requirements by security classes in
comparison with other information security standards is simplified as much
as possible and is reduced to determining the presence or absence of a given
set of protection mechanisms, which significantly reduces the flexibility of
the requirements and the possibility of their practical application. Despite
these shortcomings, the State Customs Committee documents filled the
“legal vacuum” in the field of information security standards in Russia and
159
quickly solved the problem of designing and assessing the quality of
protected systems.
5.3. CRITERIA FOR ASSESSING THE SECURITY
OF INFORMATION TECHNOLOGY (COMMON CRITERIA)
Basic Concepts
“Criteria for assessing the security of information technology” [10]
(published December 1, 1999) is the most comprehensive and modern
among the assessment standards. This international standard was the result
of almost ten years of work by specialists from several countries; it absorbed
the experience of documents that existed at that time on a national and
international scale.
For historical reasons, this standard is often called “Common Criteria”
(or even CC). We will also use this abbreviation.
“Common Criteria” is actually a meta-standard that defines
information system (IS) security assessment tools and how to use them.
Unlike the Orange Book, CC do not contain predefined “security classes”.
Such classes can be built based on the security requirements that exist for a
specific organization and/or a specific information system.
From a programmer’s point of view, CC can be considered a set of
libraries that help write meaningful “programs” — security tasks, standard
security profiles, etc. Programmers know how a good library simplifies the
development of programs and improves their quality. Without libraries,
“from scratch,” programs have not been written for a very long time; safety
assessment has also reached a comparable level of complexity, and the
“Common Criteria” provided the appropriate tools.
Like the Orange Book, CC contain two main types of security
requirements:
• functional, corresponding to the active aspect of protection,
requirements for security functions and the mechanisms that implement them;
160
• trust requirements corresponding to the passive aspect, imposed on
the technology and the development and operation process.
Security requirements are presented, and their implementation is
verified for a specific assessment object — a hardware and software product
or an information system.
It is very important that safety in CC is not considered statically, but
in relation to the life cycle of the object being assessed. The following stages
are distinguished:
1) determination of purpose, conditions of use, goals and safety
requirements;
2) design and development;
3) testing, evaluation and certification;
4) implementation and operation.
In CC, the object of assessment is considered in the context of the
security environment, which is characterized by certain conditions and
threats.
In turn, threats are characterized by the following parameters:
• source of threat;
• method of influence;
• vulnerabilities that can be exploited;
• resources (assets) that may be damaged.
Vulnerabilities may arise due to deficiencies in:
• safety requirements;
• design;
• operation.
Weaknesses should, if possible, be eliminated, minimized, or at least
try to limit the possible damage from their intentional use or accidental
activation.
To structure the requirements space, the “Common Criteria”
introduced the class — family — component — element hierarchy.
Classes define the most general, “subject matter” grouping of
requirements (for example, functional accountability requirements).
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]