SEKE 2012 Proceedings - Knowledge Systems Institute

component are properly labeled with security levels. The
component enforces the multilevel security policy
internally so that security mechanisms are i ntended to
provide secure access c ontrol. This technique is
developed for a single security model, so it is restricted to
access control. Other security features are not taken into
account.
Deng et. al. [3] proposed a methodology to m odel
secure software architectures and verify whether required
security constraints are assured by t he composition of
components of the system. This approach introduces
security constraint patterns, which specify the se curity
policies that the security syste m must enforce. However,
this approach is lacking focus on what type and fo rm of
security policies should be used in a give n context and
how to im plement them in a system d esign. The
components are considered the central units for assembly
and deployment. Interactions between components are
captured in component interfaces.
Using connectors as the central construct, a distributed
software architecture in [4] is com posed of a set of
components and a set of connect ors that can be used to
connect the components. The Unified Modeling Language
(UML) [10, 11] is used to describe the com ponent
interconnection patterns for synchronous, asynchronous
and brokered communications. Though different kinds of
connectors are proposed in [4], t here are no
considerations for en forcing security in to these
connectors. The message communication via the
connectors between components is not secure.
In [5], a connector centric approach is used to model,
capture, and enforce security. The security characteristics
of a software architecture are described and enforce d
using software connectors. An e xtensible architecture
security contract specified by components is regulated
and enforced by connectors. Connectors can decide what
principals can e xecute the connected components. But,
this approach models only access control as a security
concern. The security properties like confidentially, nonrepudiation
and integrity are not taken into account.
Aspect-oriented design (AOD) techniques in [6] are
used to encapsulate security concerns in complex systems.
Different security concerns are modeled as aspects that
can be woven into models of essential functionality. The
mechanisms required to protect against attacks are used to
identify the needing aspects and the strategy for weaving
them into a design. There ar e many benefits of t reating
security concerns as aspects during design m odeling, but
this approach requires s oftware engineers to know
knowledge of aspect-oriented design.
In earlier work by the aut hors [7], an approach is
described to model complex applications by m odeling
application requirements and designs separately from
security requirements and designs using the UML
notation. Security requirements are captured in security
use cases and encapsulated in security objects. When a
system requires security serv ices, security use cases are
extended from the non-secure business use case at
extension points. However, [7] paid relatively less
attention to secure application architecture where security
requirements can be m apped to a sec ure software
architecture.
In later work by the aut hors [8], an approach is
described for modeling the evolution of a non-secure
application to a secure application in term s of a
requirements model and a software architecture. In the
software architecture, security services a re encapsulated
in connectors separately from components. The sec urity
services are activated if the security requirement
conditions are satisfied. However, this approach does not
offer various secure connectors that are used for different
communication patterns and security services.
3. Secure Connectors
The software architecture [14, 15] for concurrent a nd
distributed applications can be designed by m eans of
components and connectors. The components address the
functionality of an application, whereas connectors deal
with communication between components. Each
component defines application business logic that is
relatively independent of th ose provided by other
components. A component may request ser vices from
other components, or provide services to them through
connectors. A connector acts on behalf of components in
terms of com munication between components,
encapsulating the det ails of i nter-component
communication.
Separately from application com ponents, security
services can be encapsulated in connec tors between
components in the software architecture for concurrent
and distributed applications [8]. The original role of
connectors in the software architecture is t o provide the
mechanism for m essage communication between
components [14, 15]. However, in this paper, the role of
connectors is extended to security by adding security
services to the connectors, which are referred to as secure
connectors. Secure connectors are designed by
considering both the security serv ices required by
components and the type of message communication
required between the components.
The security services provided for components are
confidentiality, integrity, non-repudiation, access control,
and authentication, as follows:
Confidentiality security service, which prevents
secret information from being disclosed to any
unauthorized party, can be achieved by secu re
connectors encapsulating cryptosystems.
Integrity security service, which protect s against
unauthorized changes to sec ret information, can be
performed by secure connectors using message digest
(MD) or message authentication code (MAC) [13].
395