![](bg2.png)
new technologies (e.g. 'naked' scanner) and
processes.
Using of domain expert knowledge in order to
verify and validate the system architecture
3 APPROACH
In order to reach the above described objectives we
developed a generic engineering approach (Fig. 1)
which is implemented in six subsequent steps using
an EADS-tailored tool chain. The following
paragraphs will explain the steps in detail.
Step 1: Analysis of As-is System. A fundamental
precondition of all engineering approaches is a deep
knowledge about the system or object of
investigation. For this reason the first step of the
engineering approach is a system analysis in order to
understand the system itself and its functioning. In a
data gathering phase of this analysis all relevant
elements and parameters are identified which
describe and influence the object of investigation
(e.g. airport, border control, etc.). Further more, it is
analysed how these parameters correlate and
influence each other. The direction of a correlation is
defined and also a qualitative assessment is applied
which allows to describe the degree of correlation of
the parameters (no, medium, strong correlation). The
influence analysis can be done by using either
correlation tables or matrices.
Another aspect of the system analysis
concentrates on the business processes. They
describe the activities and their sequence of
execution in order to produce a specific service or
product on a very fine-grained level. For every
process step it has to be determined e.g. who
performs this step, who is responsible, what are the
input and output parameters, how long does this step
take and what systems and tools are used to
implement this process activity.
The step of analysing the target system is crucial
and the analysis results define the basis for creating
threat scenarios which is done in step 2.
Step 2: Scenario Generation. In our work we
pursue a scenario-driven approach because we
believe that only a real-life scenario can show the
actual benefit and practical relevance of the method.
Further we need a real-life reference in order to
demonstrate how the knowledge of domain experts
is incorporated in our work. Finally the added value
of our method can be measured and compared more
easily when it is based on a real-life example and it
is more comprehensible to any stakeholder.
A scenario is used to describe a potential threat
respectively a potential attack that can be carried out
against the security system. The scenario description
is made up of the system elements that have been
specified in the previous step. The important point is
the ability to create self-consistent scenarios. This is
because of the correlations between the system
elements that have been specified in step 1. For
example, it makes no sense to use a knife in order to
attack an armoured vehicle. In that case, we would
have defined a negative correlation value between
knife and armoured vehicle.
Another very important aspect of the scenario-
driven approach is that the business processes which
are affected by the scenario can be derived
automatically. Regarding business processes, we act
on the assumption that there are just a few roles that
can be taken on in the system, e.g. the system
"airport" offers for example the roles of a passenger,
an employee, a visitor and a supplier. Further we
assume that an attacker tries to remain undetected
until the actual attack on the target starts by slipping
into at least one of the roles the system provides.
Just in the moment the attacker performs the attack
or the attacker's cover has been compromised, the
attacker's original role becomes obvious.
Business processes describe the intended
behaviour of a system and our goal is to create a
system architecture which on the one hand provides
a functionality that complies with the real-life
behaviour and on the other hand allows to assess and
optimize the systems security mechanisms. Our
main conclusion in this regard is that the system
architecture has to have a high degree of structural
similarity to the systems business processes. The
next section describes how such a system
architecture can be achieved. The result of this step
are self-consistent scenarios.
Step3: Design of the Solution Architecture. After
the as-is system is analysed and threat scenarios are
defined, the goal of the third step in the system
engineering approach is the design of the desired to-
be system architecture. In this architecture we
consider two different views (
Figure 1):
Operational View
System View
The operational view describes how the roles,
organizations and activities have to operate in order
to react on the given threat. This description provide
the operational guidelines which are noted in a
CONOPS (concept of operations). The system view
specifies the technical framework for the
implementation of the CONOPS. This system view
MODEL - AND SIMULATION DRIVEN SYSTEMS - ENGINEERING FOR CRITICAL INFRASTRUCTURE
SECURITY ARCHITECTURES
425