Information Technology Reference
In-Depth Information
The foundational attributes are an abstract representation of SOA. Moreover,
the same abstract representation applies to all technical services and web services,
not only SOA. This abstract representation of services and service relationships
facilitates the discovery of IA requirements. The IA architect may ask questions
regarding risks to services, risks of introducing services, and risks of service rela-
tionships, interfaces, data flows, data, and metadata. How can SP advertise itself to
ensure it is discoverable by would-be service requestors? How can the SP be sure the
SR is allowed to request SP's service (trust relationship)? How can the SR be sure
the results it receives from the SP are valid (actually sent by SP)? How can the SR
be sure the results sent by SP arrive unchanged (integrity)? How can SR ensure the
metadata actually belongs to the data it arrives with? Table 6.1 presents examples of
SOA security considerations in context of the nine IA core principles.
Process decomposition requirements engineering is a way to identify security
requirements by identifying and understanding the business components and their
interactions. The business components may include technical aspects, but the focus
in this method is on the process more than the technical mechanisms. The follow-
ing requirements engineering process, systemic decomposition, provides a method
to delve deeper into the technology.
6.4.2
Systemic Decomposition
Systemic decomposition uses the hierarchical categories of the WBS framework—
system
,
subsystem
,
components
,
subcomponents
,
assemblies
, and
subassemblies
—to the
degree of granularity that befits the situation. Albert Einstein said, “Make things as
simple as possible, but not simpler.” Likewise, decompose systems to a manageable
point, but not further. Too granular a decomposition adds complexity, which is the
very thing you are trying to reduce through decomposition. Figure 6.4 shows an
example of intrasystemic relations where the system (S
0
) consists of subsystems (S
1
and S
2
) that in turn consist of components (C
x
).
Systemic decomposition decomposes each system into various layers of constitu-
ent parts. Upon completing the decomposition, consider the discrete requirements
for each component. Additionally, consider the requirements for the aggregation of
the component parts into subsystems and systems. The IA architect uses iterations
of the IA
2
P to define system (S
0
) IA requirements, subsystem (S
n
) contribution to
systemic IA requirements (they in turn become subsystem IA requirements), com-
ponent contribution (C
n
) to subsystem IA requirements, etc. The IA architect asks
questions regarding the security needs of components as individual artifacts, e.g.,
clearing memory after each use in a software application. The IA architect also asks
questions regarding the aggregate effect of the safeguards in context of overall IA
objectives for the system.
The IA architect may use systemic decomposition requirements engineering
alone or in conjunction with business process decomposition. The requirements
