Software Engineering for Security: Towards Architecting Secure

Software

Doshi Shreyas
Information and Computer Science Dept.
University of California, Irvine
CA 92697, USA.
+1 949 824 8438
[email protected]

ABSTRACT
Much of the work so far in the area of security of software
Since the advent of distributed systems, security of systems has come from the Cryptography community.
software systems has been an issue of immense concern. While other areas of Computer Science like Computer
Traditionally, security is incorporated in a software Networks and Theory have also contributed to the
system after all the functional requirements have been solution to the problem of security of software systems,
addressed. This paper argues for the need for security we found that the area of Software Engineering has made
concerns to be an integral part of the entire software very little contribution. This is quite ironic considering
development life cycle. Different research areas that lie at the fact that the problem is that of how ‘software’ systems
the confluence of Software Engineering and Security are can be made more secure. These software systems are an
surveyed. Finally, the paper focuses on the use of outgrowth of some Software Engineering process
Software Architecture to solve certain problems that are presumably with Software Engineering principles applied
faced in the engineering of secure systems. in their development. It is fair to deduce that we might be
able to make systems more secure by incorporating
Keywords security considerations explicitly in the Software
Engineering process and by applying certain Software
Software Engineering, Security, Software Architecture, Engineering principles to solve problems faced in the
Secure Software Architecture. engineering of secure software. However, several
impediments lie along this path.
1. INTRODUCTION
Security is a non-functional requirement [CN95]. Since
As society becomes more and more reliant on software developers grapple with the problem of getting the
systems for its smooth functioning, software security is functionality right without overrunning schedules or
emerging as an important concern to many in the field of budgets, security is not the utmost concern for system
Computer Science. Since security attacks can cause developers- even in systems where security threats might
anything from losses worth millions of dollars in business be easily perceptible. Hence, software system security is
to intrusion into defense systems, the repercussions of typically an afterthought [Gas88], i.e. security may be
such security attacks can be quite grave. However, it is considered seriously if the functional requirements are
not only large organizations and governments that are met and the project is within the schedule and budgets. As
susceptible to security attacks. Today, security has also observed in [Bro87], this is seldom, if ever, the case.
become a concern for the average citizen. Citizens are
becoming increasingly aware about the security threats In this paper, we shall look at the different research areas
over computer networks, encouraging them to take that lie at the confluence of the fields of Software
adequate steps to protect their credit card numbers and Engineering and Security. More specifically, we shall
personal information over the Internet. Though such look in detail how research in the area of Software
preventive steps by ordinary citizens and organizations Architecture [PW92] can help solve the problems that lie
are necessary, they do not offer long-term solutions to the in the path of development of secure software systems.
problem of security of software systems. It is known fact Before we delve further into the topic, it is worthwhile to
that the wily hacker [CB94] can find ways to get around examine what security really means and the different
these steps. What then is the solution? dimensions of security.

Doshi Shreyas Security of a software system is a multi-dimensional

Term paper for ICS 121
concept [BSW01]. The multiple dimensions of security
are:
ΠAuthentication- The process of verifying the identity secure systems, or to enhance the security of software
claimed by an entity. systems.
ΠAccess control- The process of regulation of the kind ΠSecurity for Software Engineering- This refers to
of access (e.g.- read access, write access, no access) research in the areas of security and cryptography
an entity has to the system resources. that helps solve problems in different areas of
ΠAudit trail- A chronological record of events leading Software Engineering.
up to a specific security-relevant system state. This We shall now look at each of the above categories and
record can later help in the examination or also identify research directions that lie therein.
reconstruction of the specific security scenario of
interest. 2.1 Software Engineering for Security
ΠConfidentiality- The property that deals with making
certain information unavailable to certain entities. Software Engineering research for Security can roughly
ΠIntegrity- The property that information has not been be structured around the waterfall model as follows.
modified since its inception from the source.
ΠAvailability- The property of the system being ΠSecurity requirements engineering- Eliciting security
accessible and usable for an authorized entity. requirements is a critical step in adopting a security-
ΠNon-repudiation- The property that places confidence oriented software development approach early in the
regarding an entity’s involvement in certain life cycle. Security requirements should be
communication. determined after the functional requirements have
been ascertained [DS00], since they are intimately
Security can mean different things at different times. dependent on the kind of functional requirements that
Generally, when security is referred to, it essentially have been gathered. Generic security requirements
implies one or more of the above dimensions of security. for systems have taken the form of security models or
For example policies [BP75] [GM82] [McL94]. More recent work
ΠSecurity in E-mail communication might involve [VKP01] has attempted to study trust assumptions of
ensuring confidentiality, non-repudiation and software developers regarding how the users will use
integrity. the system. According to [VKP01], erroneous trust
ΠSecurity in online shopping would involve ensuring assumptions of developers regarding the manner in
authentication, confidentiality, integrity and non- which the system will be used usually result in
repudiation. compromise of security. Though developers make
such assumptions throughout the software
A security attack (or simply an attack) is an attempt to development life cycle, the two main reasons for
adversely affect one or more of the above security dangerous and erroneous trust assumptions are:
dimensions of the system. When an attack is successful, • Incomplete requirements and
the security of a system is said to have been • Miscommunication between developers.
compromised. Throughout this paper we use the term Hence, it is necessary to elicit accurate trust
secure system. We define a secure system as one that has assumptions during the requirements analysis phase.
the requisite type and amount of security to be able to We believe that research in the area of requirements
counter the potential threats it may face. In the remainder engineering for security needs to be focused in this
of the paper, we shall use the above security-related terms direction. Such an approach could also be useful to
frequently. We shall also use certain terms from the the developer of a secure system in that the
related area of cryptography. Readers unfamiliar with the identification and articulation of trust assumptions
basic terms in cryptography are referred to [Sch96]. can be used as a security guideline for later stages of
software development.
This paper is organized as follows. In section 2, we
identify and classify research areas in the fields of ΠFormal Analysis of security protocols- The security
Software Engineering and Security. In section 3, we look protocols that developers choose to use in their
at the use of software architecture for engineering secure system are not necessarily as secure as the developers
software systems. Section 4 presents a summary of the might perceive them to be. For example, flaws have
contributions of this paper and section 5 concludes the been found in almost every authentication protocol
paper by raising some points for discussion. that has been published to date. Hence, we believe
that before developers can place trust in a particular
2. SOFTWARE ENGINEERING AND SECURITY security protocol, it is necessary that the trust be
justified explicitly and formally. This can be done
We categorize research in the area of Software only by a formal analysis of candidate security
Engineering and Security into two research directions- protocols. For example, [Kem89] describes how an
ΠSoftware Engineering for Security- This area encryption protocol can be formally analyzed using
explores Software Engineering research and the Ina Jo [LSS+80] specification language. While
principles that can be used in the engineering of Ina Jo is a generic specification language, several
 techniques have been developed specifically for security. This is because security, unlike
formal analysis of security protocols (e.g.- [BAN90]). functionality, is not an externally observable
We believe that it is necessary for software engineers property. Hence, we believe that existing testing
to make a decision about the security protocol they strategies that work well for testing functionality
will use in their system only after formal analysis of need to be extended in order to accommodate explicit
the protocol puts sufficient confidence in the security testing. A conventional approach to security
correctness and security of the protocol. Such formal testing has been the hiring of a security expert who
analysis could be done by a trusted external agency would try to attack the system and exploit any
or by the software engineers themselves. potential weaknesses of the system. Though this
approach is a very attractive one, we believe that
ΠArchitecting/Designing secure software- According more needs to be done. Since testing is a phase
to [DS00] there is an emergent need for integrating during which budget and schedules are tight, it is
security policies with the design of systems. For necessary to devise automated security testing
example, a research direction would be [DS00] to mechanisms which can test the security of the system
extend standards such as UML [RSC97] so as to with less effort (time and cost) than the manual
include the explicit modeling of security dimensions security testing approach described above. For
like authentication, access control, etc. identified example, [FL94] and [FKA+94] describe a semi-
earlier. We believe that software architectures can automated approach for security testing. [DWW99]
play a vital role in the development of secure describes the reasons for not relying on conventional
systems. The use of principles of Software testing strategies for testing security and recommends
Architecture in solving security-related problems in the promotion of open security testing to increase
distributed systems and in making software systems confidence in the security of software.
more secure forms the focus of this paper. We now look at how research in the area of security can
help solve certain problems in software engineering.
ΠProgramming languages and programming
paradigms for secure software- According to 2.2 Security for Software Engineering
[VBC01], programming language designers have
until recently ignored security primitives that Security can solve the following problems faced in
programmers should have at their disposal. In fact, Software Engineering.
security risks are known to have been uncovered in
several programming languages (e.g.- C, C++ ΠSecure Software Deployment and Configuration
[VBC01]). In this regard, the Java security Management- Several privacy and security issues
architectural extensions [WBD+97] [Gon97] are a [DGS99] surface in post-deployment configuration
step in the right direction. A related development in management [HW96]. [DGS99] discusses these
this area is the emergence of the aspect-oriented issues and attempts to find solutions to the problems
programming paradigm (AOP) [KIL+97]. The object faced in this area. According to [DGS99],
oriented programming paradigm models security very cryptographic techniques emerge as an important
poorly since invocations to security methods are solution to these issues.
typically scattered throughout the application code,
making it difficult to abstract the security aspect of ΠComponent test coverage claims- Vendors of
software. AOP can provide a separation of the Commercial Off the Shelf (COTS) components are
security aspect of the system from all other aspects faced with the challenge of assuring their customers
like reliability, fault-tolerance, etc. This can be very that adequate testing has been done on their
useful in programming security into an application, components without actually revealing source code,
since all security concerns can be programmed test cases, etc. Revealing this might convey vital
together and later dispersed through the actual code information about the component. If such information
using an aspect weaver [KIL+97]. Emerging is revealed, it is possible that the component may be
technologies are posing several challenges to created by a competitor thereby making the vendor
programming languages, requiring them to adapt lose its competitive advantage. In [DS99], a
their security mechanisms so as to secure the cryptographic technique by which the test coverage
applications running on the technologies. For claims of a component can be verified without
example, [GS01] describes the security risks in WML revealing essential information about the component
posed by the mobile e-commerce technology. is described.

ΠSecurity testing- For any system where security ΠProtection of software- Piracy of software is a source
concerns are sufficiently large, it is necessary to test of tremendous losses to the software industry. Hence,
the system to determine explicitly whether it satisfies efforts to effectively counter the software privacy
the security requirements. We believe that testing for problem are necessary. Both software (e.g.- [HP87])
functionality is significantly different from testing for and hardware-based (e.g.-[MM84]) solutions to the
 problem have been proposed. Most of the software-
based approaches proposed this far use cryptography.
So far, however, not many solutions to the problem
have been effective because of the adversarial
economics [DS00] involved.

In this section, we looked at the confluence of the areas of

Software Engineering and Security from two
perspectives:
ΠSoftware Engineering for Security and
ΠSecurity for Software Engineering.
To engineer secure software, the first perspective is more
useful and we shall be looking at this perspective in the
remainder of this paper. Within this perspective, we shall
be focusing on the use of Software Architecture for
engineering secure software.
Figure 1. Object Management Architecture, printed from [Chi98]
3. SOFTWARE ARCHITECTURE FOR SECURITY
Figure 1 shows a model of distributed object computing
We believe that research in the field of Software with the Object Management Architecture (OMA) of
Architecture can help solve several problems that lie in CORBA. At the center lies the Object Request Broker
the path of developing secure software. In the next (ORB) which serves the purpose of connecting
subsection, we describe CORBA security as an example heterogeneous software components in arbitrary
of the security considerations involved in a component- configurations. Four basic types of software components
based distributed system. We describe in sections 3.2 are identified in OMA:
through 3.6 several aspects of software architecture and ΠObject Services- provides basic services that are
how they can be used to tackle specific problems in needed by other components in the distributed
engineering secure software. Finally, in subsection 3.7 we system.
look at how the convergence of Aspect-Oriented ΠHorizontal Facilities- that are needed through by all
Programming (AOP) and Software Architecture may be a users in the distributed system and may be used by
promising area for future research. components in the vertical facilities.
ΠVertical Facilities- that provide capabilities for
3.1 CORBA Security specific types of businesses.
ΠApplication objects- which combine all other
According to [WWW1], Common Object Request Broker components and provide enterprise-specific services.
Architecture (CORBA) is an architecture and
specification for creating, distributing, and managing The need for developing a specification for the Object
distributed program objects in a network. It allows Request Broker resulted in the creation of the Common
programs that may be developed by different vendors and Object Request Broker Architecture or CORBA. Since
may be situated at different locations to communicate in a clients and objects in a distributed system may be
network through an interface broker [WWW2]. Various heterogeneous, it is necessary to devise means by which
security issues emerge in a scenario described above. they may be able interact in a language and platform
Here we will describe the basic Object Management independent manner. In order to accomplish this, the
Architecture and ORB architecture. With these interface to objects is defined using a standard OMG
foundations, we shall describe the security requirements Interface Definition Language (IDL). Using such a
in CORBA and the possible solutions to the security standard interface, it is conceivable that clients and object
requirements. This will serve to articulate the security implementations would be able to translate transparently
issues involved in Software Architecture and describe at a between different programming languages, operating
high level how they can be solved. [Chi98] gives further systems, data formats, etc. Such a scheme is depicted in
details regarding the CORBA Security Service. More figure 2.
information about CORBA may be found in [WWW2].
 Table a. Security issues and possible countermeasures in CORBA
Issue Countermeasures

Authorized user gaining access to unauthorized information Control of access to

ΠInterfaces
ΠSubsets of implementation of an interface
ΠInterface operations
Non-repudiation measures
Security audit log mechanism

A user masquerading as another user User authentication and mutual authentication between the client and the
object implementation.

Eavesdropping on a communication channel and tampering with Cryptographic measures like encryption and hashing
communication between objects

Bypass of security controls Delegation mechanisms controlled by clients and object implementations

ΠDefinition of secure architectures using an ADL

[MQR+97] [ML97].
ΠIntegrating security for COTS based systems [BS98]
[BS99].
ΠResolution of complex security-related interactions
between heterogeneous software components [BI97].

Apart from these benefits, use of principles of software

architecture also provides the following additional
benefits to the developer of a secure system
ΠReuse of security-related code across different
systems [JH98] [Dam98]
ΠUse of architectural patterns [YB97]
Figure 2. OMG IDL in CORBA, printed from [Chi98] ΠCreation of autonomous security agents [FL96]
[BGS+98] [QS98] [TOH99]
As described in [Chi98], the major security issues that
emerge in case of the architecture described above are
In the following subsections, we shall describe
shown in Table a.
representative research from each of the above areas. We
also look at a related topic in this section: the use of
3.2 The Role of Software Architecture
aspect oriented programming [KIL+97] in abstracting the
security aspect of systems.
Having seen the possible countermeasures against the
security problems that arise in component based
3.3 Definition of secure architectures
distributed systems, we will describe here specific ways
in which we can deal with them by exploiting existing
A promising approach to secure system design is the
features of Software Architecture and by proposing new
incorporation of security considerations into the software
features, when necessary. The field of software
architecture. Software architecture can be used to define
architecture [PW92] provides a clear separation between
and model the security requirements of a software system
components and their interactions. In this framework, an
in order to assist in
architecture description language (ADL) allows the
ΠSubsequent system development and
specification of system in terms of the following
ΠChecking the implementation for compliance with
abstractions [BI97]:
the security requirements.
1. Components- define computational units written in
any programming language.
In order to model security requirements in the form of
2. Connectors- describe the type of interactions between
architecture, we may express them using an ADL. The
components.
problem of using an ADL to include security
3. Configuration- defines a system structure in terms of
considerations in the overall software architecture has
interconnection of components through connectors.
been addressed in [MQR+97] and [ML97]. In [MQR+97],
Software architecture can be extremely helpful in
the authors Moriconi et al. describe the use of SADL (an
engineering secure software systems in three distinct
Architecture Description Language) in the formalization
ways, depending on the scenario of the problem at hand.
of their Secure Distributed Transaction Processing 3. Identifying how the connections are used.
(SDTP) system. The authors use a formal approach to
software architecture [AG94] to incorporate security These steps are applied to the system structures
requirements by means of three steps [MQR+97]: successively at the three levels of abstraction defined
1. Formalizing the system architecture in terms of above: the global, conops and execution levels. The first
common architectural abstractions. two steps are self-explanatory, however, the last step
2. Specialization of the system architecture into deserves explanation. By identifying how the connections
different architectures, each depending on different are used, it is possible to determine operational security
assumptions regarding the security of system constraints on the components and the their interactions.
components. This is a convenient way of specifying for example, the
3. Proving that every implementation corresponds to the conditions under which an interaction will occur between
system architecture or one of its specializations and components and the conditions under which an interaction
thereby satisfies the security requirements. will not occur. Figures 3, 4 and 5 depict the application of
steps 1, 2 and 3 respectively on the MISSI reference
In this subsection, we will discuss in detail, the approach architecture at the global level of abstraction. The reader
described in [ML97] by Meldal and Luckham. In [ML97] is referred to [ML97] for the details and explanation.
the authors describe the use of the RAPIDE ADL [LV95]
to define a reference architecture for the description of
NSA’s MISSI (Multilevel Information System Security
Initiative) architecture. According to [ML97]
A reference architecture is an architecture
used to define references against which
implementations can be checked for
compliance. Figure 3. Components of the MISSI Reference Architecture, printed
The use of reference architectures is useful in that it from [ML97]
provides an elegant way to obtain separation of concerns
in the system. That is, one reference architecture for a
system may be used to specify the security requirements
of the system, while another may be used to specify its
fault-tolerance requirements. We shall see later in this
section how similar separation of concerns can be
obtained using the aspect-oriented programming Figure 4. Connecting Architectural Components, printed from [ML97]
paradigm [KIL+97].
According to [LV95]
RAPIDE is a concurrent event-based
simulation language for defining and
simulating the behavior of software
architectures.
The authors use RAPIDE to capture two aspects of the
MISSI reference architecture:
1. Structures- describes the arrangement of the different
components of the system at the following levels of
abstraction
ΠGlobal level focuses on the main components
and constraints on the interactions between the
components.
ΠThe concept of operations or conops level
focuses on the functional decomposition of the
architecture.
ΠThe execution level focuses on the dynamic,
physical structure of the system
Figure 5. Security Constraint, printed from [ML97]
2. Information flow integrity- describes the adherence of
the interactions to certain policies and procedures as
determined by the reference architecture.
Once the three steps are applied at different levels of
The formal capture of the architecture, according to abstraction, RAPIDE maps can be used to relate
[ML97] involves three steps. components and interactions at one level of abstraction to
1. Identifying components components and interactions at another level of
2. Identifying how they are connected and abstraction. The approach outlined here provides a
convenient way of specifying the security aspects of a Gateway (RTIG) component. RTIG uses the Federate
system. The following benefits may be accrued by an Object Model (FOM) that describes the classes of data
approach of the kind described above: exchanged by federates during execution. In [BS98], two
ΠConvenient separation of the security-related aspects security threats are identified in this architecture.
of the system ΠAttacks on the communication links between the
ΠExplicit formal modeling of the security-related components or the RTI and
aspects in the form of the software architecture ΠAttacks via misuse or unauthorized use of RTI
ΠVerification of the implementation with respect to the services.
architecture and the verification of the architecture
with respect to the requirements, by means of proofs. The first threat is countered by creating a secure
ΠProviding a model to reason about the security connection that ensures secrecy and authenticity of the
properties of the system. data that is transmitted between the RTIA and RTIG. The
We shall now look at another problem; that of integrating second threat is countered by adding access control
security into COTS based systems. mechanisms within RTI services. Figure 7 shows the
architecture of the system after having made provisions
3.4 Integrating security in COTS based systems for countering the threats.

The use of Commercial off the shelf software (COTS)

components is a very attractive choice faced by software
development organizations for economical software
development and reducing the time-to-market. Since
COTS components are intended to work in varied
environments that may have different security
requirements, security is not typically not ‘programmed
into’ these components. Hence, no or very limited generic
security services are typically provided by COTS
Figure 7. RTI security architecture, printed from [BS99]
components. However, since most of these components
are meant to work in a distributed environment, they
system using these components would be susceptible to To secure the communication between the RTIA and
various security risks. It is therefore necessary to RTIG processes, GSS API [Lin97] is integrated within the
somehow incorporate security for the particular system at RTIA and RTIG by extending the socket class that is used
hand that uses these components. to exchange messages within RTI. GSS API (Generic
Security Services Application Programming Interface)
This problem presents another area of research for the use [Lin97] is a standard that defines the cryptographic
of Software Architecture for engineering secure software services that can be used to secure a client-server
systems. In fact, the problem is exacerbated due to the application. Access control mechanisms are integrated
fact that the non-testability of some COTS components within the RTIG and security labels are associated with
might actually pose major security threats to the system federates and objects of the federation. [BS99] describes
that uses such components [MV99]. [BS98] and [BS99] one more example of how security is integrated using a
address the problem architectural approaches for software architecture in systems using COTS based
integrating security in COTS based distributed systems. In components.
[BS98] the authors describe the CERT HLA/RTI
distributed interactive simulation environment that is Though this approach might look attractive at first, we
developed using COTS components with security believe it has a severe limitation- it requires the
integrated into the system later. The RTI architecture is modification of the COTS components. According to us,
depicted in figure 6. the option of modifying the components themselves in
order to incorporate security considerations is not a viable
one because
ΠThis inhibits the future reusability of the component
ΠIn situations in which the source code of the
component is not provided, it is not possible to
modify the component at all.
ΠThe effort involved in modifying the component
might well exceed the effort that would be required to
Figure 6. RTI architecture, printed from [BS99]
develop the component from scratch.
In the architecture, a federate (e.g.- Fed1) denotes an ΠModification of components would entail regression
individual simulation. Each federate interacts with the testing [RH96] of the components. Without access to
RTI Ambassador (RTIA) component which exchanges the source code such testing cannot be carried out
messages over the network, in particular with the RTI faithfully.
ΠIn some cases, legal restrictions against modifying Specifying the security properties related to encryption
their COTS components are imposed by the involves the specification of
component manufacturers. ΠThe encryption algorithm used
ΠThe nature of parameters used by the encryption
Apart from [BS99] and [BS98], very little work exists in algorithm that is chosen
this area. The limitations of the approach in [BS98] and
[BS99] suggest that this is an area worth exploring by With heterogeneous components, mismatches can arise at
further research in Software Architecture. In the next either level- for the choice of the encryption algorithm as
section, we will look at a connector-oriented approach well as due to the nature of parameters used by the
that might be a more pragmatic approach towards tackling encryption algorithm. To handle these mismatches, the
such a problem. developer must first specify the different acceptable
requirements for encryption as shown in figure g.
3.5 Resolution of mismatched security-related
interactions of heterogeneous software components

The problem of architectural mismatch [GAO95] is a

major hindrance to the reuse of software. This problem
occurs due to the mismatches in the assumptions of the
reusable component about the system that it is to be a part
of. In the context of security for a distributed software
system with heterogeneous components, this problem Figure g. Specifying security requirements, printed from [BI97]
manifests itself in the form of differing Quality of Service
(QoS) requirements [BI97]. In [BI97], the authors Bidan Since each component can have a different set of
and Issarny attempt a solution to the problem of grappling encryption requirements like the one in figure g., it
with complex security requirements of components in becomes necessary to compose and compare the
open distributed systems. Software Architecture is used to encryption requirements. Since encryption and decryption
specify security requirements. After specification of the functions are generally symmetric, a primary requirement
security requirements of each component, it is possible to for composition is that the encryption algorithm should be
build customized connectors (at compile time) that meet the same at both ends of a connector. This means that if
the security requirements of both the components we consider a connector as composed of two sub-
involved in the connection. This is described in figure 7. connectors, one for each component, then the encryption
algorithm should be the same for each of the two sub-
connectors. In order to achieve the similarity of the
encryption algorithm, the application developer is
responsible for specifying a list of encryption algorithms
in the two sub-connectors, along with the associated trust
degree of the algorithm. Then, the encryption algorithm of
the connector is that algorithm which belongs to both sub-
connectors and has the highest trust degree. After the
selection of the encryption algorithm, the parameters can
Figure 7. Security requirements and customized connectors, printed be also selected according to this strategy. That is, a trust
from [BI97] degree is associated with the parameters of the encryption
algorithms and the parameters chosen are the ones that
The authors of [BI97] use this approach to specify the correspond to the highest trust degree and are specified in
following categories of security requirements of both the sub-connectors. A similar approach is adopted
components: for the selection of authentication algorithms and access
ΠEncryption requirements control mechanisms.
ΠAuthentication requirements
ΠAccess control requirements The above technique is a simple and effective way of
Each of these categories of requirements can widely vary resolving security-related architectural mismatch between
from component to component. The challenge is to components. An architecture-oriented approach is both
compare and compose these requirements so that
intuitive and elegant and ensures that the security
heterogeneous components can talk to each other using concerns are addressed early in the software development
the customized connector shown in figure g. We shall life cycle. This approach also lends itself well to resolving
illustrate here how this challenge is addressed for the
the security mismatches of legacy systems and
encryption requirements. Authentication and access components, a problem described in [DS00]. [FBF99]
control requirements are described in detail in [BI97]. discusses a wrapper-based approach to the same problem.
In the next subsection, we shall have an overview of some Software agents that implement security controls are
benefits that can be accrued by the software developer by described in [BGS+98] and [FL96]. The concept of
using principles of software architecture. The key software security agents as described in [FL96] is that
distinction between the issues discussed in this section agents can be implemented to monitor and perform access
and those in the next section is that while the former control, authentication, etc. by wrapping insecure
focuses on architectural solutions to security problems, components. These agents are called SafeBots in [FL96].
the latter essentially describes the benefits that can be SafeBots have a certain level of intelligence associated
obtained by developers of secure systems by using with them in that they can adapt their actions to local and
software architectures. These benefits may not necessarily global context. Programming agents may be a promising
contribute to enhance the security of the system. step towards monitoring security of a distributed system.
However, the programming of such agents is a very
3.6 Other Benefits obtained by using software difficult task. This is due to the following reasons
architectures [TOH99]:
ΠMobile agents might act in remote hosts with varied
The first benefit that can be obtained by using software environments. This makes the task of predicting their
architectures is the reuse of security-related code. It is an behavior difficult.
observation that security-related code of a software ΠIt is difficult to program agents that act in different
system does not generally lend itself well to reuse [JH98]. platforms especially since the platforms themselves
This is due to the fact that are being rapidly changed.
Πthis code is typically embedded along with the
functional code of the system and To counter these problems, in [TOH99], the authors
Πsecurity-related code is typically specific to the propose an architecture oriented agent system
particular system for which it was developed. development method based on agent patterns. A layered
system architecture is defined in order to investigate a
As described in [JH98] and [Dam98], abstracting security systematic agent development process. Furthermore,
considerations to the level of software architecture by behavior patterns that correspond to the individual layers
methods described in the section 3.5 enables the reuse of are devised in order to make the development of the
security-related code across varied applications. By layers easy. Behavior patterns are documentation of good
managing the security considerations outside components, past experiences in the development and behavior of
and in the connectors, the security and the functional agents. The layered agent system architecture is shown in
aspects are made independent of each other, thereby figure 8.
facilitating reuse. As we shall see later, such separation of
concerns can also be obtained using the Aspect Oriented
Programming paradigm [KIL+97].
Architectural patterns are defined in [OR98] as
fundamental organizational descriptions of
common top-level structure observed in a
group of software systems.
Architectural patterns capture and express earlier
experiences in the design and development of software. In
this manner, they provide a guideline for system Figure 8. Layered agent system architecture, printed from [TOH99]
developers during early stages of the software lifecycle.
In [YB97], several architectural patterns for the security In the above figure, the macroarchitecture layer represents
aspect of applications are presented. These patterns can be the outline of the system configuration. The
applied by the system developer both to serve as a macroarchitecture layer is independent of specific agent
security guideline for developers and reason about platforms. The microarchitecture layer describes the detail
application security. Apart from [YB97], not much work of system configuration and the agent behaviors
has been done in this promising area. However, [BRD98] specialized in each agent platform. The object level
describes a pattern language for a generic object-oriented represents the implementation of the system depending on
cryptographic architecture. the design of the upper two layers. Behavior patterns that
correspond to the individual layers described above are
We believe that the use of software architecture concepts then determined. Finally, the three layers are designed in
would also aid the developer in the development of a top down fashion using these behavior patterns. Using
security agents. According to [FL96], security agents are such an architecture-based approach along with agent
ubiquitous, communicating, dynamically behavior patterns, it becomes easier for the developer to
confederating agents that monitor and develop agent systems efficiently. The approach in
control communications among the [TOH99] is described for generic agents but it can be
components of preexisting applications. applied to the development of security agents. Related
work in the area of security agents can be found in we identified the work that has been done in the area of
[BGS+98] and [QS98]. architecting secure systems. We categorized and
abstracted certain common features among these
3.7 Aspect Oriented Programming approaches. We also identified certain problems with the
existing approaches and presented some future research
The use of Software Architecture is one approach to avenues that could be explored.
constructing systems with evolutionary and reusable
security. Another related approach, as identified in 5. DISCUSSION
[DS00], is the use of the aspect oriented programming
(AOP) paradigm [KIL+97]. The AOP paradigm explicitly As pointed out earlier, the benefits that can be accrued by
provides for separation of concerns. In AOP, the different adopting a security-centered software engineering effort
aspects of the system are programmed in their most are enormous. However, we do not intend to imply that a
natural form and then these different aspects are woven software engineering effort should focus more on security
together to produce the executable code. Such an than on other software qualities. But we do believe that
approach lends itself well to the separation of the security security is not a quality that can be ‘pasted’ onto software
concerns (or the security aspect) from the functional once it is completed. If the software system that is being
features of the system. The AOP approach can be used to engineered is to be secure, security must be a concern
separate low-level security concerns as well high-level throughout the software development life cycle. While
security concerns from the other concerns. While high- efforts to attain software qualities like correctness and
level security concerns refers to security risks that are maintainability in a software product are being applied
external to the application (like intruders), low-level throughout the software development life cycle, security
security concerns are those that refer to the application lags far behind in this respect. For example, a large
itself behaving in a insecure manner, possibly due to an amount of effort during software development does not
attack (like buffer overflows). contribute largely to the development task directly. A
significant part of this effort is directed towards making
In [VBC01], the authors Viega et al. describe the use of the product more maintainable i.e. to induce the
AOP to program security applications. They illustrate this maintainability quality in the software. In fact, many
by using an example of a language developed by them software development organizations have begun to adopt
that extends the C programming language in order to specific tools and programming languages like Java in
support AOP. Such an extension can then be used to order to make their software more maintainable. This
abstract security concerns outside the program proper. concern for software maintainability throughout the
According to [VBC01], this would be helpful from the software development life cycle is justified, since if the
security point of view in a number of ways: software product is more maintainable, lesser
ΠInsecure function calls may be replaced by secure maintenance costs will be incurred. In recent times,
function calls. security attacks have also led to huge costs for the
ΠBuffer overflow can be prevented. software user as well as the developer. Unfortunately,
ΠSecurity audit trail and logging is possible. security has not received as much attention during
ΠGeneric socket code can be replaced by SSL socket software development as software maintainability has.
code. We are not attempting to indicate that software
ΠPrivileged sections of a program can be specified. organizations are careless about security. However, it is a
According to [DS00], the confluence of the field of known fact that not many software engineers have a
software architecture and AOP is a promising prospective formal background of security concepts. Also, a large
research area for engineering secure software. impediment to the adoption of a security-centered
approach to software development is the lack of adequate
4. SUMMARY software engineering tools and techniques that help
follow this security-centered approach. This may be
Very little work that specifically addresses the problem of attributed to the fact that the field of Software
engineering secure systems exists in the area of Software Engineering for Security is a relatively young field.
Engineering. In this paper, research in two seemingly However, we believe that in spite of a few limitations, the
independent areas- Software Engineering and Security- kind of work that has been surveyed in this paper is
has been assimilated in order to certainly a step in the right direction.
Πdemonstrate the solution of some problems in
engineering secure systems and ACKNOWLEDGEMENTS
Πpoint to some research directions in the area of
software engineering that would aid in the The author would like to thank Prof. David Rosenblum
engineering of more secure systems. for the comments and suggestions provided by him during
With the understanding that principles of software the course of writing this paper. The author would also
architecture can be useful in solving many problems like to thank Eric Dashofy for the discussion that led to
encountered in the development of distributed systems, the selection of this topic.
REFERENCES [DGS99] P. Devanbu , M. Gertz , S. Stubblebine. Security
for Automated, Distributed Configuration Management.
[AG94] R. Allen, D. Garlan. Formalizing Architectural In Proceedings, ICSE 99 Workshop on Software
Connection. Proceedings of the 16th International Engineering over the Internet. 1999.
Conference on Software Engineering. May 1994.
[DS99] P. Devanbu, S. Stubblebine. Cryptographic
[BAN90] M. Burrows, M. Abadi, and R. Needham. A Verification of Test Coverage Claims. IEEE Transactions
Logic of Authentication. ACM Transactions on Computer on Software Engineering. 1999.
Systems, 8. February 1990.
[DS00] P. Devanbu, S. Stubblebine; Software
[BI97] C. Bidan, V. Issarny. Security benefits from Engineering for Security: A Roadmap. Proceedings of the
software architecture. Proceedings of conference on The future of Software engineering. 2000.
COORDINATION’97: Coordination Languages and
Models. 1997. [DWW99] A. Dima, J. Wack, S. Wakid. Raising the Bar
on Software Security Testing. IT Professional. Vol. 1, No.
[BP75] D. E. Bell, L. J. LaPadula. Secure Computer 3, May/June 1999.
system: Unified Exposition and Multics Interpretation.
Technical Report MTR-2997, MITRE Corporation, [FBF99] T. Fraser, L. Badger, M. Feldman. Hardening
Bedford, MA. July 1975. COTS Software with Generic Software Wrappers. IEEE
symposium on Security and Privacy. 1999.
[BRD98] A. M. Braga, C. M. F. Rubira, R. Dahab.
Tropyc: A Pattern Language for Cryptographic Software. [FKA+94] G. Fink, C. Ko, M. Archer, K. Levitt. Toward
In 5th Pattern Languages of Programming (PLoP’98) a Property-based Testing Environment with Application
Conference, 1998. to Security Critical Software. Proc. of the 4th Irvine
Software Symposium. April 1994.
[Bro87] F. P. Brooks, Jr. No Silver Bullet; Essence and
Accidents of Software Engineering. IEEE Computer [FL96] R. Filman, T. Linden, SafeBots: a Paradigm for
20(4). April 1987. Software Security Controls. Proceedings of New Security
Paradigms Workshop, Lake Arrowhead, CA USA. 1996.
[BS98] P. Bieber, P. Siron. Design and Implementation of
a Distributed Interactive Simulation Security [GAO95] D. Garlan, R. Allen and J. Ockerbloom.
Architecture. Proceedings of the 3rd International Architectural Mismatch or Why it’s hard to build systems
Workshop on Distributed Interactive Simulation and out of existing parts. Proceedings, 17th International
Real-Time Applications. 1998. Conference on Software Engineering, Seattle WA. April
1995.
[BS99] P. Bieber, P. Siron. Security Architectures for
COTS Based Distributed Systems. Available at [Gas88] M. Gasser. Building a Secure Computer System.
http://www.cert.fr/francais/deri/bieber/papers/ist11/ Van Nostrand Reinhold - New York, NY. 1988.

[BSW01] I. Bashir, E. Serafini, K. Wall. Securing [BGS+98] J. Balasubramaniyan, J. O. Garcia-Fernandez,

Network Software Applications: Introduction. E. H. Spafford, D. Zamboni. An Architecture for
Communications of the ACM 44, 2. February 2001. Intrusion Detection using Autonomous Agents.
Department of Computer Sciences, Purdue University;
[CB94] B. Cheswick, S. Bellovin. Firewalls and Internet Coast TR 98-05. 1998
Security: Repelling the Wily Hacker. Addison-Wesley.
1994. [GM82] J.A. Goguen and J. Meseguer. Security Policy
and Security Models. Proceedings of the 1982 IEEE
[Chi98] D. Chizmadia, A Quick Tour Of the CORBA Symposium on Research on Security and Privacy, IEEE
Security Service. Information Security Bulletin. Press. 1982.
September 1998.
[Gon97] L. Gong. New security architectural directions
[CN95] L. Chung, B. A. Nixon, "Dealing with Non- for Java. Proceedings of COMPCON ’97. 1997.
Functional Requirements: Three Experimental Studies of
a Process-Oriented Approach." Proeedings of the 17th [GS01] A. K. Ghosh, T. M. Swaminatha. Software
ICSE, Seattle, WA, U.S.A. April 1995. Security and Provacy Risks in Mobile E-commerce.
Communications of the ACM 44, 2. February 2001.
[Dam98] Christian Damsgaard. Secure Software
Architecture. Jensen Project SIRAC, IMAGINRIA 655. [FL94] G. Fink, K. Levitt. Property-based testing of
Avaliable at citeseer.nj.nec.com/10161.html. 1998. privileged programs. In Tenth Annual Computer Security
Applications Conference, pages 154--163. IEEE [OR98] J. Ortega-Arjona, G. Roberts. Architectural
Computer Society Press. December 1994. Patterns for Parallel Programming. Proceedings of the 3rd
European Conference on Pattern Languages of
[HP87] A. Herzberg, S. S. Pinter. Public Protection of Programming and Computing. 1998.
Software. ACM Transactions on Computer Systems,
5(4):371—393. November 1987. [PW92] D. E. Perry, A. L. Wolf. Foundations for the
Study of Software Architecture. ACM SIGSOFT Software
[HW96] D. Heimbigner, A. L. Wolf. Post-Deployment Engineering Notes, 17. October 1992.
Configuration Management. Software Configuration
Management: ICSE'96 SCM-6 Workshop Selected Papers [QS98] Q. He, K. P. Sycara. Towards a Secure Agent
(Berlin, Germany). 1996. Society. ACM AA'98 Workshop on Deception, Fraud and
Trust in Agent Societies. 1998.
[JH98] C. Jensen, D. Hagimont Protection
Reconfiguration for Reusable Software Proceedings of the [RH96] G. Rothermel, M. Harrold. Analyzing regression
2nd Euromicro Conference on Software Maintenance and test selection techniques. IEEE Transactions on Software
Reengineering (CSMR’98). 1998. Engineering, 22(8). August 1996.

[Kem89] R. A. Kemmerer. Analyzing encryption [RSC97] Rational Software Corporation. The Unified
protocols using formal verification techniques. IEEE Modeling Language. Documentation Set Version 1.0,
Journal on Selected Areas in Communications, 7. 1989. Santa Clara, CA. January 1997.

[KIL+97] G. Kiczales, J. Irwin, J. Lamping, J. Loingtier, [Sch96] B. Schneier. Applied Cryptography, Protocols,
C. V. Lopes, C. Maeda, A. Mendhekar. Aspect-Oriented Algorithms, and Source Code in C. Second Edition, John
Programming. A Position Paper from Xerox PARC. 1997. Willey & Sons. 1996.

[Lin97] J. Linn. Generic Security Service Application [TOH99] Y. Tahara, A. Ohsuga, S. Honiden. Agent
Programming Interface. Internet RFC 2078. January System Development Method Based on Agent Patterns
1997. Proceedings of The Fourth International Symposium on
Autonomous Decentralized Systems. 1999.
[LSS+80] R. Locasso, J. Scheid, D. V. Schorre, P. R.
Eggert. The Ina Jo Reference Manual. Technical Report [VBC01] J. Viega, J.T. Bloch, P. Chandra. Applying
TM-(L)-6021/001/000, System Development Corporation, Aspect-Oriented Programming to Security. Cutter IT
Santa Monica, California. 1980. Journal. February, 2001.

[LV95] D.C. Luckham, J. Vera. An Event Based [VKP01] J. Viega, T. Knono, B. Potter. Trust (and
Architecture Definition Language. IEEE Transactions on MisTrust) in Secure Applications. Communications of the
Software Engineering Vol. 21, No 9, September 1995. ACM. February 2001.

[McL94] J. McLean. Security Models. J. Marciniak, [WBD+97] D. S. Wallach, D. Balfanz, D. Dean, E. W.

editor, Encyclopedia of Software Engineering. Wiley Felten. Extensible Security Architectures for Java.
Press. 1994. Technical Report 546-97, Department of Computer
Science, Princeton University. April 1997.
[MQR+97] M. Moriconi, X. Qian, R. Riemenschneider,
and L. Gong. Secure Software Architecture. Proceedings [WWW1] http://www.whatis.com
of the IEEE Symposium on Security and Privacy. 1997.
[WWW2] OMG. The Common Object Request Broker
[ML97] S. Meldal and D. Luckham. Defining a Security Architecture (CORBA). http://www.omg.org/
Reference Architecture. Technical Report CSL-97-728
Program Analysis and Verification Group Report No. 76 [YB97] J. W. Yoder and J. Barcalow. Architectural
Computer Systems Laboratory Stanford University. 1997. Patterns for Enabling Application Security. In Proc. 4th
Pattern Languages of Programming, Monticello, IL,
[MM84] T. Maude, D. Maude. Hardware protection September 1997. Available as Washington University
against software piracy. Communications of the ACM, Technical Report WUCS--97—34. 1997.
27(9). September 1984.

[MV99] G. McGraw, J. Viega. Why COTS Software

Increases Security Risks. ICSE Workshop on Testing
Distributed Component-Based Systems. May 1999.