Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Information protection in digital communication systems. Textbook
.pdf
161
Families within a class vary in the severity and other nuances of their
requirements.
A component is a minimum set of requirements that appears as a
whole.
An element is an indivisible requirement.
There may be dependencies between OK components. They occur
when a component by itself is insufficient to achieve a security goal. But
not all combinations of components make sense.
As mentioned above, with the help of libraries two types of regulatory
documents can be generated: a security profile and a security task.
A security profile (SP) is a typical set of requirements that must be met
by products and/or systems of a certain class (for example, operating
systems on computers in government organizations).
The security task contains a set of requirements for a specific
development, the implementation of which ensures the achievement of the
set security goals.
We noted above that CC does not have ready-made protection classes.
To formulate a classification in terms of the “Common Criteria” means to
define several hierarchically ordered (containing increasing requirements)
security profiles, using standard functional and security assurance
requirements to the maximum extent possible.
Selecting a certain subset from the entire set of protection profiles is
largely subjective. For a number of reasons (one of which is the desire to
adhere to an object-oriented approach), it is advisable, in our opinion, to first
form a starting point for the classification by identifying a basic (minimal)
SP, and compiling additional requirements into functional packages.
A function package is a reusable collection of components combined
to achieve specific security goals. The “Common Criteria” do not regulate
the structure of packages, verification procedures, registration, etc.,
assigning them the role of a technological means of generating a SP.
The basic security profile must include requirements for basic
(mandatory in any case) capabilities. Derived profiles are derived from a
162
base profile by adding the necessary extension packages, similar to how
derived classes are created in object-oriented programming languages.
Functional requirements
Functional requirements are grouped based on the role they perform
or the security objective they serve. In total, the “Common Criteria” presents
11 functional classes, 66 families, 135 components. This is, of course,
significantly more than the number of similar entities in the Orange Book.
Let us list the classes of functional requirements of CC:
1) identification and authentication;
2) protection of user data;
3) protection of security functions (requirements relate to the integrity
and control of these security services and the mechanisms that implement
them);
4) security management (the requirements of this class relate to the
management of security attributes and parameters);
5) security audit (identification, registration, storage, analysis of data
affecting the security of the object of assessment, response to a possible
security violation);
6) access to the object of assessment;
7) privacy (protecting the user from disclosure and unauthorized use
of his identification data);
8) use of resources (requirements for information availability);
9) cryptographic support (key management);
10) communication (authentication of parties involved in data
exchange);
11) trusted route/channel (for communication with security services).
Let us describe in more detail two classes that demonstrate the features
of the modern approach to information security.
The Privacy class contains four families of functional requirements.
Anonymity. Allows you to perform actions without revealing the user ID
to other users, subjects and/or objects. Anonymity can be complete or
163
selective. In the latter case, it may not apply to all transactions and/or not all
users (for example, the authorized user may still be able to determine user IDs).
Pseudonymity. Similar to anonymity, but using a pseudonym
maintains a link to the user’s ID for accountability or other purposes.
Impossibility of association. The family provides the possibility of
repeated use of information services, but does not allow cases of use to be
associated with each other and attributed to one person. Non-association
protects against the construction of profiles of user behavior (and, therefore,
from obtaining information based on such profiles).
Stealth. The requirements of this family are aimed at making it
possible to use an information service while concealing the fact of use. To
implement secrecy, for example, broadcast dissemination of information
without specifying a specific addressee can be used. Steganography
methods are also suitable for implementing secrecy, when not only the
content of a message is hidden (as in cryptography), but also the very fact
of its sending.
Another indicative (from our point of view) class of functional
requirements is “Resource Usage”, containing accessibility requirements.
It includes three families.
Fault tolerance. The requirements of this family are aimed at
maintaining the availability of information services even in the event of an
error or a failure. CC distinguishes between active and passive fault
tolerance. The active mechanism contains special functions that are
activated in the event of a failure. Passive fault tolerance implies the
presence of redundancy with the ability to neutralize errors.
Priority service. Meeting these requirements allows you to control the
use of resources so that low-priority operations cannot interfere with highpriority ones.
Resource distribution. The requirements are aimed at protecting
(through the use of a quota mechanism) from unauthorized monopolization
of resources.
The “Common Criteria” is a very thoughtful and comprehensive
document in terms of functional requirements. At the same time, we would
like to draw attention to some shortcomings.
164
The first is the lack of an object approach. Functional requirements are
not grouped into meaningful sets (object interfaces) to which inheritance
can be applied. This situation, as is known from programming technology,
is fraught with the appearance of too many combinations of functional
components that are incompatible with each other.
In modern programming, the key issue is the accumulation and reuse
of knowledge. Standards are one of the forms of knowledge accumulation.
Following a “library” rather than an object approach in CC narrows the
range of recorded knowledge and complicates its correct use.
Unfortunately, the “Common Criteria” lacks architectural requirements,
which is a natural consequence of the old-fashioned bottom-up
programming approach chosen. Sophisticated security features, adherence
to generally accepted guidelines for protocols and programming interfaces,
and proven architectural solutions such as manager/agent are essential
qualities of information technology products designed to support missioncritical functions, which of course include security functions. Without
consideration of interface aspects, systems end up unextensible and isolated.
Obviously, from a practical point of view this is unacceptable. At the same
time, ensuring the security of interfaces is an important task that it is
desirable to solve in a uniform manner.
Security Trust Requirements
Establishing security trust, according to the “Common Criteria”, is
based on active research into the object being assessed.
The form of presentation of assurance requirements is, in principle, the
same as for functional requirements. The specificity is that each element of
the trust requirements belongs to one of three types:
• actions of developers;
• presentation and content of evidence;
• actions of appraisers.
In total, CC has 10 classes, 44 families, 93 components of security
assurance requirements. Let’s list the classes:
165
1) development (requirements for step-by-step detailing of security
functions from brief specification to implementation);
2) life cycle support (requirements for the life cycle model, including
the procedure for eliminating deficiencies and protecting the development
environment);
3) testing;
4) vulnerability assessment (including assessment of the strength of
security functions);
5) supply and operation;
6) configuration management;
7) manuals (requirements for operational documentation);
8) trust support (to support post-certification life cycle stages);
9) assessment of the protection profile;
10) assessment of the safety task.
With regard to trust requirements, the “Common Criteria” did a very
useful thing, which, unfortunately, was not implemented for functional
requirements. Namely, the so-called evaluative confidence levels have been
introduced (there are seven of them), containing meaningful combinations
of components.
Confidence level 1 (initial) involves review of the functional
specification, interface specification, operational documentation, and
independent testing. The level is applicable when threats are not considered
serious.
Assessment level of trust 2, in addition to the first level, provides for
the presence of a top-level design of the object being assessed, selective
independent testing, analysis of the strength of security functions, and a
search by the developer for obvious vulnerabilities.
Level 3 controls the development environment and manages the
configuration of the assessment object.
Level 4 adds full interface specification, lower-level designs,
implementation subset analysis, application of an informal security policy
model, independent vulnerability analysis, and automation of configuration
166
management. This is probably the highest level that can be achieved with
existing programming technology and reasonable costs.
Level 5, in addition to the previous ones, involves the application of a
formal security policy model, a semi-formal functional specification and a
high-level design with a demonstration of the correspondence between
them. Covert channel analysis by developers and evaluators is required.
At level 6, the implementation must be presented in a structured
manner. Compliance analysis extends to the lower level design.
Evaluation level 7 (the highest) provides for formal verification of the
project of the object being assessed. It applies to extremely high risk
situations.
167
CHAPTER 6. MAIN STAGES OF BUILDING A SECURE
INFORMATION SYSTEM3
The purpose of information security activities is to protect the interests
of subjects of information relations. These interests are diverse, but they all
center around three main aspects: availability, integrity, confidentiality.
The importance of information security (IS) issues is explained by two
main reasons:
• the value of accumulated information resources;
• critical dependence on information technology.
Destruction of important information, theft of confidential data,
interruption of work due to failure — all this results in large material losses
and damages the reputation of the organization. Problems with control
systems or medical systems threaten people’s health and lives.
Modern information systems are complex and, therefore, dangerous in
themselves, even without taking into account the activity of attackers. New
vulnerabilities in software are constantly being discovered. An extremely
wide range of hardware and software and numerous connections between
components have to be taken into account.
The principles of building corporate information systems (IS) are
changing. Numerous external information services are used; own ones are
provided externally.
Confirmation of the complexity of the information security problem is
the parallel (and quite rapid) increase in the costs of protective measures and
the number of information security violations, combined with an increase in
the average damage from each violation.
Success in the field of information security can only be achieved by an
integrated approach that combines measures at four levels [10–12]:
1) legislative;
2) administrative;
3
All figures in this chapter are taken from « Защита информации в цифровых системах
связи».
168
3) procedural;
4) software and hardware.
The rapid development of global networks is attracting more and more
attention to the Internet from individuals and various organizations. Many
organizations integrate their networks into the global network, and also
install their service servers (www., FTP.) in global networks. The use of
global networks for commercial purposes, when transmitting information
containing commercial or state secrets, entails the need to build a qualified
information protection system.
When creating an information infrastructure for a corporate automated
system based on modern computer networks, the question inevitably arises
about the security of this structure from threats to information security. How
adequate are the security mechanisms implemented in the network to the
existing risks? Can this system be trusted to process (storage, transmit)
confidential information? Etc., this list is long.
Sooner or later, all specialists in information security departments and
other departments responsible for operating and maintaining networks ask
these questions. The answers to these questions are far from obvious.
Analyzing a network’s security against information security threats is a
complex job. The ability to assess and manage risks, knowledge of typical
threats and vulnerabilities, criteria and approaches to security analysis,
proficiency in analysis methods, knowledge of various software and
hardware platforms used in modern computer networks — all this is not a
complete list of qualities that specialists carrying out work to analyze
network security should have. Security analysis is the foundation on which
work is carried out to build a secure information network and audit (or
verify) the security of this network in the future.
The first section of the work provides a fairly detailed description of
each level (legislative, administrative, procedural, software and hardware)
of protecting the organization’s information assets separately. The section
ends with an example of building an automated enterprise network based on
computer equipment, and also provides a possible enterprise security policy
169
and a list of necessary rules and instructions for the organization’s
personnel.
The second section provides a classification of types of security audits
and some practical recommendations for planning and implementing an
authorized audit, as well as examples of active auditing of the security of an
organization’s information assets.
Information security means are divided into formal and informal. The
first include means that perform protective functions strictly according to a
predetermined procedure and without direct human participation. Informal
means include those that are either determined by the purposeful activities
of people or regulate (directly or indirectly) this activity (Fig. 6.1).
Средства защиты
информации
Формальные
Неформальные
Технические
Программные
Физические
Аппаратные
Законодательные
Административные
Процедурные
Организационные
Морально-этические
Fig. 6.1. Information security tools
6.1. LEGISLATIVE LEVEL
6.1.1. Federal Law “On Information, Information
Technologies and Information Protection”
Federal Law of July 26, 2006 No. 149-FZ “On Information,
Informatization and Information Protection” (hereinafter referred to as the
“Information Law”) is one of the main basic laws in the field of information
protection, which regulates the relations arising during the formation and
use information resources of the Russian Federation based on the collection,
accumulation, storage, distribution and provision of documented
information to consumers, as well as in the creation and use of information
170
technologies, in the protection of information and the rights of subjects
participating in information processes and informatization.
The main objectives of the information protection system, reflected
in the Information Law, are:
1) prevention of leakage, theft, loss, unauthorized destruction,
distortion, modification (counterfeiting), unauthorized copying, blocking of
information, interference in information and information systems, etc.;
2) maintaining the completeness, reliability, integrity of information,
its arrays and data processing programs established by the owner or his
authorized person;
3) maintaining the ability to manage the processing process and use
information in accordance with the conditions established by the owner of
the information;
4) ensuring the constitutional rights of citizens to maintain personal
secrets and confidentiality of personal information accumulated in data
banks;
5) maintaining the secrecy or confidentiality of information in
accordance with the rules established by current legislation and other
legislative or regulatory acts;
6) respect for the rights of authors of software and information
products used in information systems.
The law establishes the mandatory certification of means of processing
and protecting documented information with limited access, intended to
serve citizens and organizations, as well as the obligation to obtain licenses
for organizations engaged in the design and production of information
security means.
The Law also defines the main goals of information protection, in
particular:
1) prevention of leakage, theft, loss, distortion and falsification of
information;
2) preventing threats to the security of individuals, society and the
state;
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]