SEKE 2012 Proceedings - Knowledge Systems Institute

hospital had its local security policy to manage the privileges
of its local users. We also assumed that the following
roles existed in the two hospitals: doctor, nurser, aduser
(an user in the administrative staff), and ITuser (a user in
the information technology staff), and that in both hospitals
a patient had a medical report, data related for payment
and sensitive data which was related to personal information
such as previous medical report, insurance company,
etc.
In this case study we only focus on one interaction way:
from hospital A to hospital B. Therefore, the resources to
be accessed are located in hospital B and the VPO will be
VPO A2B .
Figure 3. Architecture of TestGen-IF.
4.1. Modeling the System Under Test
is mandatory to instantiate them. The instantiation of an
abstract test case is composed of two sub-processes: the
concretization (addition of details) and the translation to executable
scripts. The final test case is a script that contains
details of the implementation such as the real values of variables
and the signals of the test case. This script will be
executed in the O-grantee system to stimulate this system
generating specific request to the O-grantor.
Regarding the verdict, when we apply the inputs of the
test case on the O-grantor system, the generated set of outputs
has to be conform with respect to the test. However, a
rule can be only checked when the rule holds. Thus, in the
case where the security rule is constrained by a context, an
additional information that gives the state of this context is
needed in the tests.
The test verdict is built based on the information on the
security rule context and the behavior related to the execution
of the test case. Following we present the test verdict
after executing a test case.
Verdict = ¬(Test case ⊕ context) (1)
Remark that the global verdict, that is the verdict after
performing all the test cases, has the form of a conjunction
of the verdicts produced for each test case. Therefore if the
verdict of one test case is false the global verdict is also
false.
4. Case Study
In this Section we present our testing methodology approach
through a hospital network case study. A hospital
network is a network or group of hospitals that work together
to coordinate and deliver a broad spectrum of services
to their community in an O2O scenario. We considered
the case where the hospital network consists of two hospitals,
hospital A and hospital B. It was assumed that each
Next we introduce the interoperability security policy
objectives that describe the privileges of employees of the
hospital A in B and belong to VPO A2B . These interoperability
security policies represent a set of objectives that hospital
B must respect when it is accessed by the employees
of hospital A. The complete interoperability security policy
is composed of 11 objectives. Due to space limitations
following we only describe 3 of them.
The first one focus on the following situation. A doctor
from Hospital A has accessed to restricted and sensitive
information of a patient of Hospital B after filling a non
release form. The second one represents that the system
must notify to any doctor when one of his/her patient’s medical
reports is edited by another doctor. In particular if it is
edited by a doctor of a different hospital. Finally, the last
one focus on the nurse role. A nurse from hospital A is not
allowed to create, drop or edit any data of a medical report.
After defining the objectives, the interoperability security
policy objectives are modeled according to the O2O
model. As a result we got in this case study 53 different
security rules.
Next, both hospitals were modeled within extended automata
using the IF language. Note that these models, do
not specify the complete behavior of the hospitals but a partial
one which is related to the interoperability security policy
that we have to test.
We integrated the O2O rules in the automata applying the
methodology described in [11]. This integration process increase
the number of states and transitions of the original
automata. Following we present some metrics of the integration
process.
# States # Transitions # Signals
Before int. 3 10 15
After int. 4 12 17
467