SEKE 2012 Proceedings - Knowledge Systems Institute

It is worth to point out that in recent years, there has been
a new emphasis on applying formal testing to check local
security policies [3, 11].
It has been argued, usually with very good arguments,
both that formal methods are very appropriate to guide the
development of systems and that, in practice, they are useless
since software development teams are usually not very
knowledgeable of formal methods in general, and have no
knowledge at all of what academia is currently developing
(see, for example, [9, 1] among many others). To solve
this, in this paper we present our formal testing methodology
[11] in an informal way. We present the modeling of
the specification, the test architecture, and the test case generation
using our experiences obtained from the application
of our methodology in real systems. Moreover, we present
a complete case study where the net of two hospitals organizations
is tested.
The rest of the paper is structured as follows. In Section
2 we present the environment where we apply the testing
task. In Section 3 our methodology to test virtual organizations
is introduced. Next, in Section 4 a complete
case study where our methodology is applied is presented.
Finally, in Section 5 we present the conclusions and some
lines of future work.
2. Testing Hypothesis in a Organization to Organization
Environment
In this Section we present the Organization to Organization,
in short O2O, environment that we are going to test in
order to list a set of assumptions that we can assume during
the testing task. We introduce the basic principles of O2O
presenting our running example. This example is depicted
in Figure 1. There are represented two organizations A and
B that might share resources. Each organization has its local
set of security policies that defines the roles and the access
for its employees. This fact is graphically represented by
“orgA” and “orgB” respectively. When there is an exchange
of information between different organizations, the notion
of local policies must be extended.
According to O2O, each organization defines its own Virtual
Private Organization, in short VPO. A VPO is associated
with an interoperability security policy that administrate
the access of external users to the organization resources.
In Figure 1 we represent these VPOs as “VPO A2B ”
and “VPO B2A ” respectively. In particular, VPO A2B is associated
with a security policy that manages how employees
from organization A, called O-grantee in O2O, may have an
access to the resources of organization B, called O-grantor
in O2O.
An important notion in O2O is the concept of authority
sphere. This sphere restricts the scope of every security rule
to the organization in which the rule is applied. Each organization
has its own sphere, as we can observe in Figure 1.
Figure 1. Interaction in O2O.
Thus, in this paper we focus in testing each authority sphere.
In each authority sphere O2O uses context [7] to express different
types of extra conditions or constraints that control
the activation of rules expressed in the access control policy.
There are several types of context defined for O2O. For
instance the temporal context that depends on the time at
which the subject is requesting for an access to the system
or the special context that depends on the subject location.
Taking into account the information provided by the contexts
of the security rules, we can assume the following
testing hypothesis. We are provided with a global clock to
check the temporal contexts. This fact allow us to describe
the scenarios for the tests using time restrictions in an easy
way. We can monitor into logs at most this information: the
software and the hardware architecture, the subject purpose,
the system database, and the historical interactions.
Each organization that belongs to a net O2O has associated
a set of security policies for local employees and several
VPOs, one for each organization that belongs to the net.
Finally, the interoperability security policies of the VPOs are
considered provided by experts in a formal way. Moreover,
security policy properties such as completeness and consistency
are considered verified. In particular, we say that a
security policy is complete if it computes at least one decision
for every incoming request, and it is consistent if for
any request the policy computes at most one decision.
3. Testing Approach
In this Section we present our testing approach. Our
main goal is to generate test cases to stimulate the O-grantee
to send specific requests to the O-grantor. These requests
target the security rules to be tested. We assume that we
have only access to the O-grantee system. For each request
sent from the O-grantor one and only one security rule
can be involved 1 . After applying the test case, we check
that the set of received outputs conforms with the test case
1 Let us remark that the interoperability security policy is consistent and
decision complete.
465