Information Technology Reference
In-Depth Information
Rights mask
R
bits r w x
Negative specification (spec. of OSCV):
•
bit "w" is set
Positive specification (spec. of security requirement):
•
bit "r" is set;
•
bit "x" is set;
•
bits "rx" are set;
•
∅
— no bits are set
Fig. 1.
Criteria Enhancement in Specification Transformation
For positive specification of OSCV-criteria, we have declared three conditions of
the system security.
Condition P1. Positive Equity.
System is secure (according to the given
criterion), if the set
R
S
of the system-provided rights coincides with the set
R
PA
of the
"required" rights
, R
S
=R
PA
(fig. 2).
Condition P2. Positive Secrecy.
System is secure (according to the given
criterion), if the set
R
S
of the system-provided rights not exceeds the set
R
PA
of the
"required" rights,
R
S
⊆
R
PA
(fig. 3).
Condition P3. Positive Availability.
System is secure (according to the given
criterion), if the system allows the user to obtain all of the "required" access rights,
R
PA
⊆
R
S
(fig. 4).
To detect the OSCV in positive case, we need to make the following calculus.
, the system is vulnerable, because the
current security configuration allows the user to hold the unauthorized access rights
(fig. 5).
Test P1.
R
excess
=
R
S
- R
PA
. If
R
excess
≠
∅
, the system is vulnerable, because the current
security configuration denies the user to possess the required access rights (fig. 5).
To explain the reasons of OSCV given in the form of 'Positive Equity', we need to
make both tests. Thus, we will define inconsistency between the access rights
completely. To check the 'Positive Secrecy', we need to make the Test P1. And to
make 'Positive Availability', we need to accomplish the Test P2.
If
R
excess
is not empty, we can conclude that the system is vulnerable, because the
system presents the user rights from
R
excess
. If
R
miss
is not empty, we can also show the
vulnerable rights, because the user has no the required rights from
R
miss
.
Test P2.
R
miss
=
R
PA
- R
S
. If
R
miss
≠
∅
