Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Information protection in digital communication systems. Textbook
.pdf
51
Methods to counteract debuggers are more specialized. These can be
various ways of modifying code during program operation (combining a
stack segment with a code segment, encrypting code, etc.), active
counteraction by periodically checking and changing interrupt vectors,
including in incorrect ways, blocking the keyboard and screen output,
control of the execution time of individual program blocks, use of specific
features of microprocessors, etc.
2.5. METHODOLOGY FOR BUILDING SECURED DCS
Let’s consider methods for constructing protected AS. These methods
can be divided into two groups:
1) related to arbitrary DCS software:
• hierarchical development method;
• correctness research and verification;
2) specific only to protection systems (the theory of safe systems).
Hierarchical method for developing DCS software. In accordance
with the principle of abstraction, when designing an AS, developers can take
at least two paths: from the hardware “up” to the virtual machine
representing the DCS, or from the virtual machine “down” to the real
equipment. These are the two main design methods — the bottom-up
method and the top-down method. The remaining methods essentially boil
down to these two or are a combination of them.
The first method is quite simple, requires much less capital investment,
but also has fewer capabilities. It is based on the well-known scheme: “You
are an attacker. Your actions?”. That is, the information security service,
based on data on all known types of attacks, tries to apply them in practice
in order to check whether such an attack is possible from a real attacker.
The bottom-up method involves starting the design from the core
hardware of the system. During design, modules are divided into a number
of layers, and the zero layer of the virtual system is formed by hardware.
Layers that implement one or more of the required properties are added
52
sequentially until the desired virtual machine is obtained. The
disadvantages of the bottom-up design method include:
• the need to make a decision from the very beginning about the choice
of method for implementing the components of the DCS hardware, firmware
or programs, which is very difficult to do;
• the possibility of designing AS only after the development of
equipment;
• discrepancy between the real AS and the one defined in the technical
specifications.
The top-down method, on the contrary, is a detailed analysis of the
entire existing scheme for storing and processing information. The first step
in this method is, as always, to determine which information objects and
flows need to be protected. What follows is a study of the current state of
the information security system in order to determine which of the classical
information security techniques has already been implemented, to what
extent and at what level. At the third stage, all information objects are
classified into classes in accordance with its confidentiality, availability and
integrity (immutability) requirements.
This is followed by finding out how serious damage a disclosure or
other attack on each specific information object can cause to the company.
This stage is called “risk calculation”. To a first approximation, risk is the
product of “possible damage from an attack” and “the probability of such
an attack.” There are many schemes for calculating risks; let’s focus on one
of the simplest.
The damage from an attack can be represented by a non-negative
number, approximately as shown in the following Table 2.1.
The probability of an attack is represented by a non-negative number,
approximately in accordance with the following Table 2.2.
It should be noted that the classification of damage caused by an attack
must be assessed by the owner of the information or the personnel working
with it. But it is better to trust the technical staff of the company to assess
the likelihood of an attack.
53
Table 2.1
Attack Damage
Amount
of damage
Description
0
Disclosure of information will cause negligible moral and financial
damage to the company
1
There is damage from the attack, but it is insignificant; the company’s
main financial operations and market position are not affected
2
Financial transactions are not carried out for some time, during which
time the company suffers losses, but its market position and the
number of clients change minimally
3
Significant losses in the market and in profits. A significant portion of
clients leave the company
4
The losses are very significant; the company loses its position in the
market for a period of up to a year. Large financial loans are required
to restore the situation
5
The company ceases to exist
Table 2.2
Chance of attack
Probability
Average occurrence frequency
0
This type of attack is not available
1
less than once a year
2
about once a year
3
about 1 time per month
4
about 1 time per week
5
almost daily
The next step is to compile a Table 2.3 — table of enterprise risks.
54
Table 2.3
Risk table
Description of the attack
Damage
Probability
Risk
(= Damage * Probability)
Spam (mailbox full)
1
4
4
Copying a hard drive from
the central office
3
1
3
...
...
...
2
Total:
9
At the analysis stage, risk tables are set to some maximum acceptable
risk, for example, the value 7. First, each row of the table is checked to
ensure that the risk does not exceed this value. If such an excess occurs, then
this line is one of the primary goals of developing a security policy. Then
the double value (in our case 7 * 2 = 14) is compared with the integral risk
(cell “Total”). If the integral risk exceeds the permissible value, it means
that the system has accumulated many small errors in the safety system,
which in total will not allow the enterprise to operate effectively. In this
case, those that make the most significant contribution to the value of the
integral risk are selected from the lines, and an attempt is made to reduce
them or eliminate them completely.
At the most critical stage, the actual development of an enterprise
security policy is carried out, which will ensure appropriate levels of both
individual risks and integral risk. When developing it, it is necessary,
however, to take into account objective problems that may interfere with the
implementation of the security policy. Such problems can be the laws of the
country and the international community, the internal requirements of the
corporation, and the ethical standards of society.
After describing all the technical and administrative measures planned
for implementation, the economic cost of this program is calculated. In the
event that the financial investment in a security program is unacceptable or
55
simply not economically viable compared to the potential damage from
attacks, we return to the level where we set the maximum acceptable risk of
7 and increase it by one or two points.
The development of a security policy is completed with its approval
by the company management and detailed documentation. This should be
followed by active implementation of all components identified in the plan.
Recalculation of the risk table and, as a result, modification of the
company’s security policy are most often carried out every two years.
The structural principle is fundamental and forms the basis of most
implementations. According to this principle, only three basic constructs are
required to build software:
1) functional block;
2) construction of a generalized cycle;
3) construction of a binary decision.
A function block can be thought of as a single computational statement
or as any other real sequence of computations with a single input and a single
output, as in a subroutine. Cycle organization is often referred to in the
literature as an element of DO-WHILE. The binary decision construct is
called IF-THEN-ELSE.
These structures can themselves be considered as functional blocks,
since they have only one input and one output. Thus, one can introduce a
transformation of a loop operation into a function block and subsequently
consider each such loop statement to be the equivalent of a (somewhat more
complex) function block. Similarly, you can introduce a transformation of a
decision-making construct to a functional block. Finally, any sequence of
functional elements can be reduced to a single functional element. At the
same time, the reverse sequence of transformations can be used in the
process of designing a program using a top-down scheme, i.e., based on a
single functional block, which is gradually expanded into a complex
structure of basic elements.
The principle of modular design is to divide programs into functionally
independent parts (modules) that ensure interchangeability, codification,
deletion and addition of components.
56
The advantages of using the modular principle are as follows:
• debugging of programs is simplified, since limited access to the
module and the unambiguity of its external manifestation exclude the
influence of errors in other related modules on its functioning;
• provides the ability to organize collaboration between large teams of
developers, since each programmer deals with a part of the program
independent of the others;
• the quality of the program increases, since the relatively small size
of the modules and, as a consequence, their low complexity allow for a more
complete check of the program.
Investigation of the correctness of implementation and
verification of AS. The concept of correctness or correctness implies
compliance of the object being checked with some reference object or a set
of formalized reference characteristics and rules. The correctness of
software during development is most fully determined by the degree of
compliance with the formalized requirements of the software specification.
The specifications reflect a set of reference characteristics, properties and
conditions that the program must meet. The main part of the specification
consists of functional criteria and characteristics. The initial software
specification that the program must comply with is the technical
specification.
In the absence of a fully formalized specification of requirements, nonformalized proposals from the developer, user or customer of the programs
are sometimes used as technical specifications to which the AS and the
results of its operation must comply. However, the concept of program
correctness in relation to user or customer requests is associated with the
uncertainty of the standard itself, which the DСS must comply with. For
complex programs, there is always a risk of discovering their incorrectness
(in the opinion of the user or customer) despite being formally correct with
respect to the specifications due to the inaccuracy of the specifications
themselves. The traditional view of a requirements specification is that it is
a natural language document that is the interface between the customer and
the manufacturer. Although some interaction may precede the preparation
57
of the document, it is the document that largely serves as the “starting point”
for the software manufacturer.
Thus, we can conclude that the creation of a set of interrelated,
consistent specifications is a necessary basis for ensuring the correctness of
the designed program. In this case, the specifications must:
• be formal;
• allow checking the consistency and completeness of customer
requirements;
• serve as a basis for further formalized OS design.
There are several approaches to defining requirements specifications.
Specification as description. The customer issues a specification so
that manufacturers can supply him with the product he wants, so the
customer sees this document primarily as a description of the system he
would like to have. In principle, the description should state what the system
should and should not do. In practice, the default assumption is usually that
the system should do what is specified in the specification and should do
nothing more. This is the main problem with the descriptive side of the
specification. It is assumed that the customer always knows exactly what
the system should and should not do. Moreover, in the future it is assumed
that the customer has completely transferred this knowledge into the
specified document.
Specification as prescription. The manufacturer views the
specification document as a set of parts to be assembled to solve the
customer’s problem. This prescriptive view is driven not only by the
difficulties of creating a descriptive document (as discussed above), but also
by information that intentionally or unintentionally expands or limits the
freedom of the manufacturer.
Contract methodology. In the “customer’s description —
manufacturer’s prescription” framework, the specification is considered as
a formal division between the parties. As for the customer, he stipulates the
acceptable minimum, while the manufacturer specifies the required
maximum. The contract is proposed and accepted at the inception of the
system and ends at the completion of the system, when the customer accepts
58
the system as meeting its minimum requirements. During the production of
a system, in principle, no interactions are expected, even if the manufacturer
suspects that what is prescribed does not exactly correspond to what the
customer wants to see in reality.
Specification as a model. Modern, more rigorous views of the
specification treat it as a model of the system. Provided that the underlying
semantics of the model are sufficiently justified, such a specification
provides a clear statement of requirements.
The corresponding models are also suitable for automated integrity
monitoring and other predictive analysis, which, in particular, will ensure
that the development of a system that is fundamentally unable to meet
requirements is stopped.
Models as a description of a system have the following distinctive
features compared to other methods of formal description:
1) a good combination of top-down and bottom-up approaches to their
development with the ability to choose an abstract description;
2) the ability to describe parallel, distributed and cyclic work;
3) the ability to select various formalized devices for describing
systems.
The main advantage of using a formal model is the ability to study
with its help the features of the modeled system. By basing a formal design
method on a mathematical model and then examining the model, it is
possible to reveal facets of system behavior that would not otherwise be
apparent until later stages.
Since the target design object is the DСS, the model can describe either
the DСS itself or its behavior, i.e., the external manifestations of the
functioning of the DСS. The model describing the behavior of the AS,
compared to the DСS model, has one important advantage — it can be tested
and evaluated by both performers and customers, since customers do not
know how the DСS should work, but they have an idea of what it should do.
As a result of such modeling, the correctness of the specifications relative
to the original formulation of the problem, i.e., the technical specifications,
can be verified. In addition, the correctness criteria are considered sufficient
59
provided that the specification represents an exhaustive description of the
“external” behavior of the object under all possible (or planned) situations
of its use.
As noted above, when developing a DCS, especially its components
representing an information security system, formal approaches to its design
are used to provide high guarantees of the absence of faults and subsequent
proof that the system functions in accordance with the requirements of the
technical specifications.
The formal design of algorithms is based mainly on languages of
algorithmic logic, which include a statement of the form Q{S}R, read as
follows: if before the execution of the operator S condition Q was satisfied,
then after it there will be R'. Here Q is called precondition and R is called
postcondition. These languages were invented almost simultaneously by
R.W. Floyd (1967), S.A.R. Hoar (1969) and scientists of the Polish logical
school (A. Salwicki et al., 1970). Both precondition and postcondition are
predicates.
The advantage of representing an algorithm as a predicate
transformer is that it allows you to:
• analyze algorithms as mathematical objects;
• present a formal description of the algorithm that allows you to
intellectually grasp the algorithm;
• synthesize algorithms according to the presented specifications;
• carry out formal verification of the algorithm, i.e. prove the
correctness of its implementation.
The methodology for formal development and proof of the correctness
of algorithms is currently well developed and outlined in a number of works.
Briefly, the essence of these methods comes down to the following:
1. The development of the algorithm is carried out by the method of
sequential decomposition, with the breakdown of the general problem
solved by the algorithm into a number of smaller subtasks.
2. The criterion for detailing subtasks is the possibility of their
implementation using one branching or loop construction.
60
3. Dividing the general problem into subtasks involves the formulation
of pre- and postconditions for each subtask for the purpose of their correct
design and further verification.
To prove the correctness of the algorithm (verification), a
mathematical theorem Q{S}R is formulated, which is then proven. The
proof of the theorem correctness is usually divided into two parts. One part
serves to prove that the algorithm in question can complete its work at all
(all loops are analyzed). In another part, the correctness of the postcondition
is proved under the assumption that the algorithm terminates.
Theory of Secure Systems (TCB). The concept of a “trusted
computing base” (TCB) appeared in foreign information security practice
quite a long time ago. The meaning of the “trusted” characteristic can be
explained as follows.
The discrete nature of the characteristic “safe” (in the sense that
something is either safe if it fully satisfies a set of requirements, or it is not
if one or more requirements are not met), combined with the statement
“nothing is one hundred percent safe,” encourages in order to introduce a
more flexible term that allows assessing the extent to which the developed
protected AS meets customer expectations. In this regard, the characteristic
“trusted” more adequately reflects a situation where the assessment
expressed by this characteristic (safe or trusted) is based not on the opinion
of developers, but on a combination of factors, including the opinion of
independent experts, experience of previous cooperation with developers,
and ultimately is the prerogative of the customer, not the developer.
A trusted computing environment (TCB) includes all components and
mechanisms of a secure automated system that are responsible for
implementing a security policy — a set of preventive measures to protect
confidential data and information processes in an enterprise. The security
policy includes requirements for personnel, managers and technical
services. Main directions for developing a security policy:
1) determining what data and how seriously needs to be protected;
2) determining who and what damage can cause to the company in the
information aspect;
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]