![](bg2.png)
the reuse of security requirements which are
compatible with the CC Framework subset. In
addition, in order to support this method and make it
easy the treatment and specification of the security
requirements, assets, security objectives and threats,
we will propose the use of several concepts and
techniques: a security resources repository (with
assets, threats, requirements, etc), the use of
UMLSec (Popp, Jürjens et al. 2003), misuse cases
(Sindre, Firesmith et al. 2003), threat/attack trees,
and security uses cases (Firesmith 2003). These
latter techniques will be used following the criteria
of effectiveness, and they allow us to integrate
security aspects from the beginning into an IS
development process, for example by expressing
security-related information within the diagrams in a
UML system specification, thanks to UMLSec.
The remainder of the paper is set out as follows:
in section 2, we will outline an overview of our
Security Requirements Engineering Process. Lastly,
our conclusions and further research are set out in
section 3.
2 A GENERAL OVERVIEW OF
SREP
The Security Requirements Engineering Process
(SREP) is an asset-based and risk-driven method for
the establishment of security requirements in the
development of secure Information Systems.
Basically, this process describes how to integrate the
CC into the software lifecycle model together with
the use of a security resources repository to support
reuse of security requirements (modelled with
UMLSec, or expressed as security use cases or as
plain text with formal specification), assets, threats
(which can be expressed as misuse cases,
threat/attack trees, UMLSec diagrams) and
countermeasures. The focus of this methodology
seeks to build security concepts at the early phases
of the development lifecycle.
As it is described in
Figure 1, the Unified Process
(UP) (Booch, Rumbaugh et al. 1999) lifecycle is
divided into a sequence of phases, and each phase
may include many iterations. Each iteration is like a
mini-project and it may contain all the core
workflows (requirements, analysis, design,
implementation, and test), but with different
emphasis depending on where the iteration is in the
lifecycle. Moreover, the core of SREP is a micro-
process, made up of nine activities which are
repeatedly performed at each iteration throughout
the iterative and incremental development, but also
with different emphasis depending on what phase of
the lifecycle the iteration is in. Thus, the model
chosen for SREP is iterative and incremental, and
the security requirements evolve along the lifecycle.
At the same time, the CC Components are
introduced into the software lifecycle, so that SREP
uses different CC Components according to the
phase, although the Software Quality Assurance
(SQA) activities are performed along all the phases
of the software development lifecycle. And it is in
these SQA activities where the CC Assurance
Requirements might be incorporated into, according
to (Kam 2005).
In addition, it facilitates the requirements
reusability. The purpose of development with
requirements reuse is to identify descriptions of
systems that could be used (either totally or
partially) with a minimal number of modifications,
thus reducing the total effort of development
(Cybulsky and Reed 2000). Moreover, reusing
security requirements helps us increase their quality:
inconsistency, errors, ambiguity and other problems
can be detected and corrected for an improved use in
subsequent projects (Toval, Nicolás et al. 2001).
Thereby, it will guarantee us the fastest possible
development cycles based on proven solutions.
Figure 1: SREP overview.
SECRYPT 2006 - INTERNATIONAL CONFERENCE ON SECURITY AND CRYPTOGRAPHY
468