Vulnerabilities Detection in the Configurations of MS Windows Operating System - Computer Network Security - page 342

state. We consider the security configuration of the given state as a complex of
subjects (the active system entities, e.g. users), objects (passive containers of
information, that need a protection, e.g. files), and their security attributes (e.g. access
rights). We add to this schema the term of constraints like a set of access restrictions
given for the 'subject-object-attributes' triple. We call the system to be safe in the
given state, i.e. " something bad never happens in the given state ". In other words,
there is no critical OSCV in the given state. In real-life systems, the constraints are
imposed upon the system state through the scope of the system-related security
configuration. Breaking the security configuration produces the OSCV. Criteria, that
help us to delimit the secure and insecure states for the OSCVs checking, we will call
as OSCV-criteria .
If security system has a problem in its security configuration, it means that the
OSCV exists and secret information is leaked by unauthorized access. Assurance that
system exploitation or the administrator's behavior does not result in the unauthorized
access is fundamental for ensuring the system security. An important feature of an
access control in the operating system is an ability to verify the correctness of security
configuration. If the security configuration is set properly, then there is no OSCV in
the system, and the system is thus secure in terms of the given vulnerabilities.
As we see, the OSCVs detection may be accomplished as checking of the security
requirements fulfillment or, in opposite side, as checking of the definite insecure
settings. Consequently, the criteria could be formulated either in terms of positive
(required or "desirable") situation, or in form of negative (denied or "undesirable")
situation. Verbally, in case of positive statement, the criterion specification starts with
the words: " System is secure, if ... [ security requirements that need to be in the
system ] ... ". In case of negative criteria, the specification of criterion starts with
" System is vulnerable, if ... [ vulnerability conditions that need not to be in the
system ] ... ".
To make the OSCVs detection a comfortable routine we need both specifications,
because transformation from one mode to another is obvious mathematically but not
trivial for complex computer systems. Let us demonstrate the example of 'negative-to-
positive' transformation hardness. We have the following OSCV-criterion: "System is
vulnerable, if user U obtains right "w" for file F " (fig. 1). We mathematically could
use just a positive specification instead of both modes. To do this, we ought to
transform negative description of OSCV to positive one. Thus, we need to specify
four different positive situations.
The theory of security supplies us with the following basics of OSCVs detection.
R all defines a set of all possible access rights that the user can obtain for the given
type of securable object. R PA denotes the "required" access rights, that user should
have. If she or he has the "required" rights, the system will be thus secure. R PD is a set
of the "denied" rights, i.e. the access rights that should be forbidden to user. If those
rights are banned to user, the system is considered to be secure. To take into account
the system security settings, we need to introduce the set R S , the number of access
rights, range of which is allowed by the system security settings, R S

R all .
R excess denotes the "excess" rights, i.e. a subset of rights which are not "necessary"
but allowed by the security settings; and R miss marks the "missed" rights, i.e. a subset
of rights which are not enough for user to obtain all of the system-defined rights.

⊆