Information Technology Reference
In-Depth Information
each path should be stereotyped according to its type as either
LAN
or
encrypted
or
wire
or
Internet
.
4. The tag
stereotype should be as-
signed a value according to domain knowledge collected during requirements
analysis. For example, if shared phenomena exist indicating that data items
of a connection can be deleted, read, and inserted arbitrarily, then the
Internet
{
adversary
}
of the
secure links
should be applied, and the tag
{
adversary
}
should be as-
signed the value
default
(see [8] for details).
5. The tag
stereotype of the behav-
ioral views of the instantiated GSAs should be assigned the same value as
the value of the equally named tag of the
{
adversary
}
of the
data security
secure links
stereotype.
In the next section, we show how different GSA instances are combined yielding
global secure software architectures.
3.5
Composition of Different GSA Instances
Composing different GSA instances means that one must decide whether the
components contained in more than one GSA instance should appear only once
in the global architecture, i.e., whether they can be merged. Basically, three
different categories of components must be considered: application layer compo-
nents, GNC instances, and GSC instances.
Choppy et al. [2] developed for a set of
functional
subproblem classes a cor-
responding set of subarchitectures that solve these subproblems. Moreover, the
subarchitectures are composed based on dependencies between the subproblems
such as parallel, sequential, and alternative dependencies. We adopt the prin-
ciples by Choppy et al. [2] to merge application layer components and GNC
instances.
We now discuss the composition of GSA instances to obtain a global secure
software architecture that still fulfills the security requirements realized by the
corresponding GSA instances. Especially confidentiality requirements must be
treated carefully, since the composition of incompatible components can lead to
non-fulfillment of confidentiality requirements.
If two GSA instances contain GSC instances that serve the same purpose, then
these components cannot be merged in general. The question to be answered is
if the two GSC instances can use the same algorithm-specific configuration, e.g.,
a specific algorithm, key lengths, salt lengths, etc., to fulfill the different secu-
rity requirements. For example, a specific encryption algorithm and specific key
lengths might be sucient to solve one security subproblem, while the same con-
figuration would lead to a vulnerable system if applied to another subproblem.
The level of abstraction of GSC instances might not allow to decide whether
they can be merged or if they have to be kept separately. Then, it is necessary
to refine the GSC instances to platform-specific security components to come to
this decision. An approach to deal with the composition of GSC instances before
their refinement to platform-specific security components is to merge GSC in-
stances of the same type into one
configurable
GSC instance of this type. Here,
