See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/220135814

RUP extension for the development of secure systems

Article  in  International Journal of Web Information Systems · December 2007

DOI: 10.1108/17440080710848099 · Source: DBLP

CITATIONS READS
12 238

2 authors:

Carlos Eduardo de Barros Paes Celso Hirata

Pontifícia Universidade Católica de São Paulo (PUC-SP) Instituto Tecnologico de Aeronautica
17 PUBLICATIONS   81 CITATIONS    126 PUBLICATIONS   411 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Discrete Event Simulation Techniques View project

My doctoral degree at the Technological Institute of Aeronautics (ITA) View project

All content following this page was uploaded by Carlos Eduardo de Barros Paes on 21 July 2017.

The user has requested enhancement of the downloaded file.

 RUP Extension for the Development of Secure Systems
Carlos Eduardo de Barros Paes
Department of Computer Science,Pontifícia Universidade Católica de São Paulo, Brazil
carlosp@pucsp.br
Celso Massaki Hirata
Department of Computer Science, Instituto Tecnológico de Aeronáutica, Brazil
hirata@ita.br
Abstract
The expansion of computer usage results from the
progress of technology and communication. As a
consequence, attacks on computer systems with
malicious objectives are growing and can represent
damages and losses for companies. It is recognized
that security has become a critical issue in software
development. Most of the software development
processes were proposed before this recognition
therefore they do not provide appropriate support for
the development of secure systems. RUP (Rational
Unified Process) is a well-known software engineering
process that provides a disciplined approach to
assigning tasks and responsibilities within a
development organization; however, it has little
support for development of secure systems. The
proposal of this work is to present an extension to RUP
for the development of secure systems. The security is
embodied in RUP as a knowledge area (discipline)
with activities and roles defined according to the
architecture of process engineering UMA (Unified
Method Architecture). An example was elaborated to
clarify and verify the feasibility of the proposal.
1. Introduction
Nowadays the development of mature software is
accomplished through the use of good practices of
Software Engineering. Software development with
emphasis in security should guide the developer and
use methods, techniques and tools that allow a good
organization of the development process, as well as
good quality results. In order to obtain quality results,
it is necessary to perform both a satisfactory elicitation
of functional requirements and quality attributes (non
functional requirements), and the system architecture
definition.
During the development of a system, security is
important and must be regarded in the first phase of the
International Conference on Information Technology (ITNG'07)
0-7695-2776-0/07 $20.00 © 2007
software development cycle for the construction and
operation of the system. Rational Unified Process
(RUP) is a software engineering process that provides
a disciplined approach to define tasks and
responsibilities inside an organized system
development [1][2]. The goal is assure the production
of software that satisfies the needs of clients, in a time
period and a predictable cost. Although RUP may be
customized and extended for different types of
projects, it does not address specifically the
development of secure systems. This limitation can be
easily verified since security in RUP consists basically
of identification and documentation of supplementary
requirements during the initial phases of development.
No concern exists with respect to the definition of a
security plan and security policies that address the
needs of the stakeholders and users, as well as, the
definition of a secure system architecture that
considered such policies. Therefore the RUP is
incomplete with respect to the development of secure
systems.
This paper presents a proposal of a RUP extension
and adaptation for the development of security
systems. As a consequence of our proposal, a software
engineer could consider security risks and develop
secure applications. A related work is proposed by
Wimmel [3]. The work is based on Common Criteria
(CC/ISO 15408) and proposes a process that combines
the development guided by phases with the activities
requested by Common Criteria. However it does not
consider an incremental and iterative process such as
RUP. Some other papers [4], [3] [5] present isolated
solutions for the development of secure systems, i.e.
they do not consider security inside of a software
development process.
For the RUP extension and adaptation will used an
engineering process architecture called UMA (Unified
Modeling Architecture). UMA is based on the SPEM
1.1 pattern (Software Process Engineering Meta-
Model) of OMG (Object Management Group) for
processes engineering. The pattern defines schema and
 terminology for representing methods consisting of
method content and processes [6].
The paper is organized as follows. Section 2
discusses security in the software development
process. Section 3 presents the software process
engineering. Section 4 presents the extension and
adaptation of RUP for development of secure software.
Section 5 shows the example used to analyze the
feasibility of our proposal. Finally, section 6 presents
conclusions and final comments.
2. Secure Software Development
As discussed earlier, security should be considered
with attention throughout the development process.
For example, a lack of specification in any
development activity can compromise the quality of
the final product of software, making the software
unacceptable to the client.
In order to incorporate security mechanisms, it is
necessary to know both the context (where) and the
reason (why) they are used. There are several
mechanisms that can usually be embodied in systems
to support security.
Such mechanisms can be divided into two groups:
communication and access [7]. The communication
group is related to the communication between users
and processes, possibly residing in different machines.
The mechanisms used are the secure channel,
authentication, integrity of the message and
confidentiality. The access group is related to the
authorization or restriction of access to information
and resources for the authorized individuals. A way to
restrict the access to resources of a system, for
example, a corporate database, is through mechanisms
of access control. The term "individuals" is used to
designate the agents that access information and
resources maintained in a system. For example, an
individual can be a user or a process.
For the development of a secure system, security
policies should be adopted and mechanisms of security
should be used in order to implement such policies.
The distinction between policies and mechanisms is
useful when the secure system is designed, but
frequently it is difficult to assure that a certain set of
mechanisms fully implements the desired policies. It is
understood that the policies are independent from
technology. Besides the policies and mechanisms,
activities and specific roles for the security should be
considered in the development process. The roles are
assigned to members of the development team and they
take part in activities that use techniques, knowledge
International Conference on Information Technology (ITNG'07)
0-7695-2776-0/07 $20.00 © 2007
and tools to incorporate security in the specification,
design and system construction.
3. Software Process Engineering
The use of software development process faces
enormous pressures; being recognized that the
understanding, the adaptation and effective
administration of development process are an
important factor for the success of software projects
[8]. The software development process improves the
predictability and quality, reduces costs and times in
the execution of the project, helps the stakeholders,
and supplies structure for future improvement [8].
However, the processes implementation is not an easy
task. The processes are complex, highly iterative, with
parallelisms and several relationships among tasks.
The environment of processes is unstable, because of
changes of technology, business requirements and
project team. It is usual that the processes are strongly
rigid or is not precisely defined [9].
The OMG defined a metamodel pattern for process
modeling named SPEM (Software Process
Engineering Metamodel). The objective of the pattern
is to facilitate the definition of the software life cycle,
the understanding and the improvement of software
development processes. The SPEM is a metamodel that
uses an object-oriented approach and defines UML
stereotypes for software process modeling. The
specification SPEM is structured in a profile UML and
supplies a complete metamodel based on the model
architecture MOF (Meta-Object Facility) [10].
In this paper, UMA (Unified Modeling
Architecture) is used for modeling of software process
engineering. The UMA is based on SPEM and defines
schema and terminology for representing methods
consisting of method content and processes. UMA has
been developed as a unification of different method
and process engineering languages such as the SPEM
extension to the UML for software process
engineering, the languages used for RUP v2003,
Unified Process, IBM Global Services Method, as well
as IBM Rational Summit Ascendant. It provides
concepts and capabilities from all of these source
models unifying them in a consistent way, but still
allowing expressing each of these source methods with
their specific characteristics. The unification
specification proposed by the UMA was submitted for
OMG as part of SPEM 2.0 and was embodied in the
last version of Rational Unified Process (RUP v2007)
[6] [11].
The specification of UMA provides a separation of
method content and process. The method content is an
 explanation step-to-step of how the specific objectives In Figure 1, the new discipline security is a
of development are reached independently of the concern from the inception phase to the transition. As
placement of those steps in the development cycle. It represented in the whale’s diagram, the workload for
provides content descriptions such as roles, tasks, work security concentrates on the elaboration phase, in
products, and guidelines. In turn, the process defines which the secure architecture is defined for the system,
how the elements of the method content are organized and in the construction phase.
in a sequence that can be customized for a specific For the new discipline, a reference workflow related
type of project [6]. to security was defined. Figure 2 shows the workflow
In this paper, the security is included in RUP as proposed for the security discipline.
method content inside the software development
process that must address security requirements.
Activities, tasks, roles and work products are defined,
according to UMA and incorporate to RUP. The
proposal presented in this work was implemented in
RUP using the modeling tool named IBM RMC
(Rational Method Composer) for software
development process engineering.

4. RUP Extension for the Development of

Secure Systems
Security is considered a non-functional or quality
requirement of a system and it must be considered
along all cycle of development. There are two
alternatives to consider security in RUP: extension and
customization. In an extended version of RUP, security
is seen as a new discipline in order to support the
development of secure systems. To customize the
existent standard RUP is simply done by incorporating
the activities, tasks and roles related to the security in
the already existent disciplines. We believe that the
second alternative makes the understanding and
implementation of security inside the process more
difficult and complex, because the workflow is mixed
with other areas of knowledge, turning its execution
and control less manageable.
In the following we describe extend version of
RUP. Figure 1 illustrates the process RUP after
incorporating the security discipline.

Figure 2. Security Discipline Workflow

In Figure 2, the security discipline workflow is

represented through a UML activity diagram. Each
activity is detailed into tasks that are developed by
Figure 1. RUP Extension for Secure Systems members according to their roles. The role represents a

International Conference on Information Technology (ITNG'07)

0-7695-2776-0/07 $20.00 © 2007
 responsibility of the execution of tasks that should be
assigned to some member of the development team. Misuse Cases Definition
The result of the activity execution is the production of
some work products. The misuse cases definition consists of the
In this diagram, the initial activity is the security identification and specification of misuse cases. A
planning. The security planning is realized in the misuse case is the inverse of a use case, i.e., it is
inception phase, and for consistence it must be simply a use case of negative scenarios from the point
evaluated before the beginning of the next activity. of view of hostile actor to the system under
The activity misuse cases definition is also realized in development [12]. The misuse cases have been
the inception phase, and drives all the development proposed to elicit non-functional requirements,
using the RUP for secure system. After the execution particularly security requirements. The misuse cases
of the security planning, the following two activities are initiated by the mis-actor. A mis-actor is the
can be realized: threat identification and analysis and inverse of an actor, i.e., an actor that one does not want
security policies definition. Both activities are the system to support, an actor who initiates misuse
accomplished in the first iterations in the elaboration cases [13].
phase. After the execution of those activities, the
following two flows can be realized concurrently:
architecture refinement for security and security tests
elaboration. The architecture refinement for security
should be realized in the final iteration of the
elaboration phase and the security tests elaboration
must be realized in the end of the construction phase or
in the first iteration in the transition phase.
Each one of the activities is detailed in terms of
tasks, which involve the participation of defined roles
inside of the process. The role represents a
responsibility of the task execution that should be
taken by some team development member. The result
of the task execution is the generation of some work
products. In the following, the activities proposed for Figure 3. Security Plan Development Activity
the discipline security are detailed.
The responsible role for this activity is the Security
Security Planning Engineer. Figure 4 shows the tasks and the work
products generated in this activity.
The security planning consists of the tasks
identification, verification and necessary validation for
the development of a secure system. In the security
plan are identified, the workers, the necessary
resources, the definition of milestones, and the
scheduler for the development of the tasks that involve
security. The responsible role for the development of
the tasks related with this activity is the Security
Manager. Figure 3 shows the input and output work
products generated from this activity.
In Figure 3, the task proposed for this activity is the
development of the security plan. For the elaboration
of this plan the following input work products must be
considered: iteration plan, supplemental specifications,
and software development plan. As a result of the
execution of this task, the security plan describing all Figure 4. Misuse Cases Definition Activity
the activities, tasks and roles related to security is
obtained.

International Conference on Information Technology (ITNG'07)

0-7695-2776-0/07 $20.00 © 2007
 Figure 4 presents the tasks proposed for this
activity: misuse cases identification and misuse cases
specification. In order to identify the misuse cases, it is
necessary to use as input the use case model. The use
case model is created during the inception e
elaboration phases.
In these two tasks the misuse cases and the mis-
actors are identified and documented in the Misuse
Cases Model. After the misuse cases identification,
each misuse case must described using a template as
proposed by Sindre [13].
Threat Identification and Analysis
The threat identification and analysis consists of
identifying items that need to be protected and
potential threats. The responsible role for the tasks
development related with this activity is the Security
Engineer. Figure 5 shows the tasks described in the
following and the work products generated that are
proposed for this activity.
Figure 5. Threat Identification and Analysis
Activity
Figure 5 presents the tasks proposed for this
activity: asset identification, threat identification, and
threat classification. In order to perform the asset
identification and threat identification tasks, it is
necessary to use as input the vision document. The
vision document is created early in the RUP inception
phase and defines the stakeholders view of the product
to be developed, specified in terms of key needs and
features The final results of the tasks development are
the: threat document and attack tree work products.
The following tasks are proposed for this activity:
• Asset Identification identifies what assets will be
International Conference on Information Technology (ITNG'07)
0-7695-2776-0/07 $20.00 © 2007
part of the analysis, aligned with the objectives of the
enterprise. Firewalls, databases, operating systems,
servers, workstations, routers, applications, files with
confidential data, logs, passwords, web sites, can be
part of this analysis.
• Threat Identification identifies the threats to the
system. For this task, we can use, for example,
Microsoft STRIDE model (Spoofing, Tampering,
Repudiation, Information disclosure, Denial of service,
Elevation of privilege) and other categories of threats
of the specific application domain [17]. The result of
this task is the definition of the attack model using
attack tree to analyze the identified threats and the
textual description of the tree. The potential threats are
described using attack tree. The attack trees provide a
formal, methodical way of describing the security of
systems, based on varying attacks. They were defined
by Bruce Schneier [18] [19] based on earlier work by
Nancy Leveson [20]. Attacks are represented in a tree
structure, with the attacker goal as the root node and
the different ways of achieving that goal as leaf nodes.
An attack tree models the attacker decision process.
Besides the attack model, this activity produces the
documentation of the threats (work product document
of threats) using, for example, the model shown in
Table 1. In this table, one example of the threat
description is presented as proposed in [17]. For each
one, a brief description of the threat, the definition of
the objective of the threat, the related risk, and the
techniques used for the attack, and the necessary
counter-measures to avoid the attack is described.
Table 1: Threat Document Example
Thread Attacker obtains authentication credentials
Description by monitoring the network
Threat target Web application user authentication
process
Risk
Attack techniques Use of network monitoring software
Countermeasures Use SSL to provide encrypted channel
• Threat Classification classifies the threats. The
classification can be made, for example, using
Microsoft DREAD model (Damage Potential,
Reproducibility, Exploitability, Affected users and
Discoverability) [17]. This model helps to determine
the actual impact of a security threat. This impact is
measured in terms of threat risk. The attribution of the
risk consists of the last step of the threat classification.
For example, the risk of a specific threat can be the
product of the threat probability and the potential
damage that indicates the consequences to the system
whether an attack happens. A scale of 1-10 can be used
for the probability, where 1 represents a threat with
 low occurrence probability and 10 represents high
occurrence probability. Similarly, the scale of 1-10 can
be used for the potential damage (1 indicate minimum
damage and 10 represents a catastrophe). This allows
addressing the threats using an ordered list. In general,
it is not economically feasible to deal with all the
identified threats. Those with low chance and damage
can be discarded [17].
Security Requirements Definition
The threat document defined in the previous activity
is the first step for the security requirement definition.
Each countermeasure that is defined and verified is a
security requirement that should be incorporated in the
design and code and validated in the security test
activity. The resources to be expended for the
implementation of the requirements must be in
accordance with the classification of the threats. The
responsible role for the task development for this
activity is the Security Engineer. Figure 6 shows the
tasks, roles and work products generated from the
execution of this activity.
Figure 6. Security Requirements Definition
Activity
In Figure 6, the task proposed for this activity is the
security requirement identification. For the execution
of this task it the input of the threat document is
necessary. This task has as an output the security
requirement document that can follow the pattern
CC/ISO 15408 [21]. This pattern describes
functionalities related to the security that the system
can incorporate.
Some standards for the evaluation of security are
defined in order to deal with the increasing needs of
security in the computer systems. These standards
establish practices of reference and facilitate
International Conference on Information Technology (ITNG'07)
0-7695-2776-0/07 $20.00 © 2007
knowledge dissemination. One of the patterns mostly
used nowadays is Common Criteria, ISO/IEC 15408
(Common Criteria goes Information Technology
Security Evaluation), an international pattern that
establishes criteria to analyze the security of
information technology products.
Security Policies Definition
The security policies definition consists of the
activity that defines the philosophy, strategy, rules and
practices related to security of information systems.
The security policies defined in this activity are related
to the use of the software system that is being
developed. They are not the organization security
policies, but they are part of it.
In order to perform the tasks in this activity, two
roles are employed: Security Manager and Security
Engineer. Figure 7 shows the tasks, roles and work
products generated from the development of this
activity.
Figure 7. Security Policy Activity
The figure shows the following tasks for this
activity: security policy elaboration, security policy
assessment, security policy review, and security
mechanism definition. The input work product for the
task security policy elaboration is the vision document.
The input work product for the task security
mechanism definition is the security requirement
document. The final output work product of these tasks
is a document with the system security policy. We
describe the tasks proposed for this activity in the
following:
• Security Policy Elaboration consists of the
production of the security policy document. It contains
 guidelines, norms, rules concerning to permissions
(who can make what) and procedures of information
security.
• Security Policy Assessment consists of
performing the evaluation of the security policy for the
system. Optionally, some international standard for the
assessment of the security policies can be used such as
ISO-17799 (security of organization), ISO - 15408
(security of components), SSE-CMM, and ITIL
(Information Technology Infrastructure Library).
• Security Policy Review consists of review and
evaluation of security policies, and in the identification
of the requested changes.
• Security Mechanism Definition consists of the
definition of security mechanisms that implements the
security policies. Those mechanisms are defined as
security requirements and they are documented in the
security requirement document of the system
Architecture Refinement for Security
In this activity, the different models (analysis,
design, implementation and deployment) and the
different model view of the architecture are assessed in
order to support the identified security requirements.
According to RUP, the different views are defined as
the 4+1 view model of architecture proposed by [1].
Besides the requirements, the use of security design
patterns should be considered for detailing the
different views of system architecture. The process is
iterative and finishes when the development team
concludes that the security requirements are being
realized. The role responsible for the development of
the tasks is the Security Software Architect.
In order to support the identified requirements of
security for system for the different views, we can
consider the use of an extension of the UML for the
secure system development called UMLSec [4]. With
this extension of UML it is possible to capture and to
represent requirements of security in the diagrams of
use case, activity, deployment, sequence, and state.
The architectural security patterns or security
patterns are simply well known solutions for recurring
problems of security [22] [23]. Table 2 introduces
some of the main security patterns that can be
considered in the development of secure system [22].
The output of this task is the work product software
architecture with security document containing the
specification of security’s requirements with security's
patterns. Figure 8 illustrates the tasks, roles and work
products generated in this activity.
International Conference on Information Technology (ITNG'07)
0-7695-2776-0/07 $20.00 © 2007
Table 2: Security design patterns catalogue
Name of Pattern Intention
Single Access Point Create a unique module of login. All
the users will have to go through this
module.
Access Validation Create an object that encapsulates the
security policies.
Roles Create one or more objects roles that
define the rights of access for a group.
Session Create objects session to store copies
of the global variable.
Full View With Provide a full view to users, showing
Errors exceptions when needed.
Limited View Give to the user just the
options that he needs.
Secure Access Layer Use the mechanism of security of the
external system, if they exist.
Otherwise develops mechanisms of
low-level security.
Input Validation Create an object of reliable validation.
Exception Create a mechanism of exception treat
Management structuralized that prevents the access
to the private data.
Figure 8 shows the tasks for this activity:
architectural security analysis and application of
security patterns. The architectural security analysis
task uses as input the security requirement and
software architecture documents. The result of the
tasks is the software architecture with security
document.
Figure 8. Architecture Refinement for Security
Activity
Security Test Elaboration
The goal of this activity is to identify the required
security tests, define the test planning, and realize the
simulation of security. The objective of the security
tests is to capture the risks contained in a system
through the simulation of an illicit and non-authorized
 attack. This simulation aims to obtain information that
should be protected, capture the eventual existent
vulnerabilities and recommend preventive actions to
reduce the risk of damage from actual invasions.
Figure 9. Security Test Elaboration Activity
Two roles are proposed for performing these tasks:
Security Test Manager and Security Tester. Figure 9
shows the tasks and the work products generated in
this activity. Figure 9 shows the tasks for this activity:
security test identification, security test plan definition
and security simulation. The task security test
identification uses the following input work products:
security requirements document, threat document, and
attack model. The security tests plan definition
generates the plan of tests of security. The plan and the
executable code of the system (built) are used in the
task of security simulation as input work product. The
output of the activity is the executable code of the
system tested with respect to the security requirements.
5. Example
With the objective of evaluating the feasibility of
this proposal, an example was accomplished. The
example is the development of a system that realizes
distributed transaction between banks. The distributed
transaction is the transfer between banks. In this
distributed transaction, the customer is allowed to
perform transfers of values between accounts of
different banks located in different sites. The transfer
is one transaction of an enterprise application called
checking account control system. The distributed
transaction must preserve the ACID (atomicity,
concurrent control, isolation and durability) property.
The system is composed of several managers of
transaction that cooperate to execute the global
International Conference on Information Technology (ITNG'07)
0-7695-2776-0/07 $20.00 © 2007
transaction. Each site of the system consists of two
subsystems, as shown in Figure 10. In Figure 10, the
transaction manager (TM) is responsible to execute the
local transactions and maintain access to the data
stored locally. The transaction coordinator (TC)
coordinates the execution of several transactions
(global and local) locally initiated.
Transaction
TCA Coordinator TCB
TMA TMB
Transaction
Manager
Computer Computer
Bank A Bank B
Figure 10. Structure of the Inter-Bank Transfer
System
The structure of the transaction manager is similar
in several aspects to the structure used in the
centralized systems. Each transaction manager is
responsible for both maintenance of a log for recovery
and concurrency control of execution of transactions in
the same site. The transaction coordinator is
responsible for the coordination and execution of all
transactions initiated in that place. For each
transaction, the coordinator must initiate its execution,
divide it into sub-transactions and distributing them to
the appropriate sites for execution and coordinate the
completion of the transaction that can result in commit
or abort.
Atomicity can be guaranteed by using the two-
phase commit protocol (2PC). In this protocol, a
distributed transaction is initiated and coordinated by
one of the sites. This site is called coordinator. When
the distributed transaction finishes, all the others sites
involved with the transaction inform the coordinator
that the sub-transaction has finished. The coordinator
is responsible for starting the protocol 2PC.
During the communication between the managers
and coordinators, several security threats can happen.
For instance, the attacker can adulterate messages
exchanged in the 2PC, compromising the integrity.
In order to evaluate the Extended RUP proposed in
this paper, the example was developed using two
different approaches of development (instances of the
process) using the RUP. The first development was
 made using the basic RUP. The second development
used the Extended RUP for security presented in this
paper. This section is organized as follows. Section 5.1
presents the development of the application using the
basic RUP. Section 5.2 describes the development
using the extension of RUP for secure systems.
Finally, Section 5.3 presents some comparisons and
analysis of the two developments.
5.1. Development Using RUP
The inter-bank transfer system was developed by
considering the necessary activities, tasks and work
products for the context of the application. The main
goal of the development was to accomplish the
implementation of a distributed system that has
security requirements.
In the inception phase the functional and non-
functional requirements and the use cases were
identified. The main use cases (high priority) were
described in a high level specification and the
preliminary software development plan was defined.
The target of the system was also defined based on the
product vision (vision document). The inception phase
ended with the following work products: vision
document, use case model, glossary of terms,
supplementary specification, and iteration plan. The
supplementary specification included the security
requirements.
In the elaboration phase the candidate architecture
was defined based on functional and non-functional
requirements identified for the system. Additionally,
the candidate architecture was defined. In the end of
the elaboration phase, all the use cases selected for the
first version of the system were completely analyzed
and designed (workflows analysis and design). The
elaboration phase generated the following work
products: analysis and design models, system
architecture (architecture), deployment model, and data
model.
During the construction phase, the remaining use
cases were analyzed, designed and described with
details (workflow analysis and design). The
implementation workflow was developed in this phase.
The architecture of the system was tested and analyzed
considering the non-functional requirements. The
construction phase produced the following main work
products: implementation model and test model.
Based on this development, it was possible to
analyze and to evaluate the RUP considering the
importance of security requirements. In Section 5.2,
the analysis is presented considering the support of
basic RUP for the development of secure systems.
International Conference on Information Technology (ITNG'07)
0-7695-2776-0/07 $20.00 © 2007
5.2. Development Using the Secure RUP
After the development of the system using basic
RUP, a new development was undertaken now
considering the extension of the RUP for secure
systems proposed in this paper. Moreover, the main
activities, tasks and work products already realized in
the first development were considered.
During the development of the application, some
activities and tasks related to the security were
incorporated into the development process. The goal
was to test and evaluate the pertinence and significance
of the activities and tasks considering the needs of
security inherent to the application. The execution of
the new activities and tasks generated the following
work products: misuse cases model, threat document,
requirement document according to the model CC/ISO
15408, and architecture document with the different
architectural views of the refined system for security.
These work products allowed defining a secure
architecture for the distributed transactions system.
This made it possible to construct a new version of the
system to meet the security requirements.
5.3. Analysis and Comments
During the development of the application using the
basic RUP, activities, tasks, roles and work products
related with the security were not specifically
identified. In the guidelines for the construction of the
architecture, RUP suggests that security specialists be
identified but it does not specify roles and tasks.
Therefore, RUP is not sufficiently complete to deal
with security.
During the development of the example using the
extension of RUP, it was possible to identify and to
analyze more easily and directly, in the initial phases
of the development (inception and first iterations in the
elaboration phase), the security requirements. The
inclusion and representation of those requirements in
the different views of architecture allowed defining a
more consistent and representative architecture in
terms of security, facilitating the system
implementation. The tests were accomplished in a
more complete way and allowed to evaluate better the
aspects of the security of the system. All this
contributed to both reduce the development time,
because the security was addressed from of the initial
phases of the development cycle, and assure the
product final quality. However, our proposal has some
drawbacks. It involves 16 additional tasks, 7 additional
work products, and 4 additional roles. As a
consequence, the first two phases, inception and
 elaboration, of our example took longer to complete
but the construction phase took shorter to conclude.
We observed that the total times of both developments
are close for the transfer system but the development
with the secure RUP provided a better quality product.
6. Conclusion
An extension of RUP to deal with security was
proposed. The proposal includes a new discipline to
address security. Considering the security as a new
discipline facilitates the management of execution and
control of the activities and tasks related to security.
The proposal resulted in the definition of a better
system architecture considering the security
requirement. However, the extension of RUP includes
additional tasks, work products, and roles.
For a simple application, the example, the basic
RUP does not support security satisfactorily. For this
reason, we believe that our proposal of process can
result better quality of secure software.
Although we did not have significant difference
between the development time in the example using
the basic and the extended RUP, we believe that this
difference can be more favorable to the secure RUP for
more complex systems. A further work could evaluate
this question.
7. References
[1] Kruchten,P., The Rational Unified Process: An
Introduction. Wokingham, UK: Addison-Wesley, 1998.
[2] Jacobson,I., Booch, G., Rumbaugh, J., The Unified
Software Development Process, Wokingham, UK:
Addison-Wesley, 1999.
[3] Wimmel, G., Model-Based Development of Security-
Critical Systems. PhD thesis, TU München, 2005.
[4] Jurjens, J., Secure Systems Development With UML.
Springer, 2005.
[5] Anderson, R. J., Security Engineering: A Guide to
Building Dependable Distributed Systems. John Wiley
Professional, 2001.
[6] HAUMER,P. IBM Rational Method Composer: Part 1:
key concepts, IBM, Dezembro 2005, http://www-
128.ibm.com/developerworks/rational/library/jan06/hau
mer/ (accessed in April 2006)
[7] Tanenbaum, A. S. & Sten, M., Distributed Systems:
Principles and Paradigms. Prentice Hall, 2002.
[8] SOMMERVILLE, I, Software Engineering , Addison
Wesley , 7th Edition , May 2004.
[9] PRESSMAN, R. S., Software Engineering – A
Practitioner´s Approach, McGraw Hill, 5th Edition,
December 2003
[10] OMG, Software Process Engineering Metamodel
Specification, Version 1.1, Janeiro 2005,
http://www.omg.org/technology/documents/formal/spe
International Conference on Information Technology (ITNG'07)
0-7695-2776-0/07 $20.00 © 2007
View publication stats
m.htm (accessed in April 2006).
[11] HAUMER,P. IBMRational Method Composer: Part 2:
Authoring method content and processes, IBM, Janeiro
2006, http://www-
128.ibm.com/developerworks/rational/library/jan06/hau
mer/ (accessed in April 2006).
[12] Alexander, I. Misuse case: Use Case with Hostile Intent.
IEE Software, 58-56, 2003.
[13] Sindre, G. & Opdahl, A., Eliciting Security
Requirements by Misuse Cases, 120-130. Proceedings of
TOOLS Pacific 2000. Sydney, Australia, Nov. 20-23,
2000. Los Alamitos, CA: IEEE Computer Society Press,
2000.
[14] Bencomo, A., Extending the RUP, Part 1: Process
Modeling. IBM Developer Works, 2005.
[15] Booch, G., Rumbaugh, J., Jacobson, I., The Unified
Modeling Language - User Guide. Wokingham, UK:
Addison-Wesley, 1999.
[16] Object Management Group, Meta Object Facility
(MOF) Specification. Version 1.4, April 2004.
[17] Oslo, E. et al., Improving Web Application Security:
Threats and Countermeasures. Microsoft, 2003.
[18] Schneier, Bruce. Attack Trees. 21-29. Dr. Dobb's
Journal of Software Tools 24, 12 (December 1999): 21-
29
[19] Schneier, Bruce. Secrets and Lies: Digital Security in a
Networked World. New York, NY: John Wiley & Sons,
2000.
[20] Leveson, N. O., Safeware: System Safety and
Computers, Reading, MA: Addison-Wesley, 1995.
[21] ISO JTC 1/SC 27 Committee, ISO/IEC 15408:2005
Information Technology – Security Techniques –
Evaluation Criteria for IT Security. Londres: 1999. v1.0.
Available in: ISO Online Catalogue http://www.iso.ch
accessed in: 15 nov. 2005.
[22] Yoder, J. & Barcalow, J., Architectural Patterns for
Enabling Application Security. PLoP ’97, 1997.
[23] Kienzle, D. M. & ELDER M.C., Security Patterns for
Web Application Development. Defense Advanced
Research Projects Agency (DARPA) Contract #
F30602-01-C-0164, 2001.