![](bg3.png)
It is a security features or security goals based
process which is driven by risk and security
standards (concretely ISO/IEC 27001 and Common
Criteria) and deals with security requirements and
their related artefacts from the early stages of SPL
development in a systematic and intuitive way
especially tailored for SPL based development.
It is based on the use of the latest and widely
validated security requirements techniques, such as
security use cases (Firesmith 2003) or misuse cases
(Sindre et al., 2005), along with the integration of
the Common Criteria (CC) components and
ISO/IEC 27001 controls into the SPL lifecycle in
order to facilitate SPL products security
certification. Moreover, our proposed process
suggests using a method to carry out the risk
assessment which conforms to ISO/IEC 13335
(ISO/IEC 2004), concretely it uses Magerit (López
et al., 2005) (the spanish public risk management
methodology and which is recognised by the NATO)
for both SPL risk assessment and SPL products risk
assessment. Furthermore, SREPPLine has the aim of
minimizing the necessary security standards
knowledge as well as security expert participation
during SPL products development.
To this end, it provides a Security Core Assets
Repository to facilitate security artefacts reuse and
to implement the security variability model and the
security requirement decision model, which assist in
the management of the variability and traceability of
the security requirements related artefacts of the SPL
and its products. These models are the basis through
which the activities of SREPPLine capture, represent
and share knowledge about security requirements for
SPL and help to certificate them against security
standards. In essence, it is a knowledge repository
with a structure to support security requirements
reasoning in SPL.
As it is described in Figure 1 our process is
composed of two subprocesses (shown in pink):
Product Line Security Domain Requirements
Engineering (PLSecDomReq) subprocess and
Product Line Security Application Requirements
Engineering (PLSecAppReq) subprocess. These
subprocesses cover the four basic phases of
requirements engineering according to (Kotonya et
al., 2000): requirements elicitation; requirements
analysis and negotiation; requirements
documentation; and requirements validation and
verification. However, due to space restrictions, in
this paper we shall only outline the security
requirements variability management and the key
tasks that are part of the activities of PLSecAppReq
subprocess.
3 SECURITY REQUIREMENTS
VARIABILITY MANAGEMENT
The security requirements artefacts variability
management is supported by two models. The
Security Variability Model is used to assist in the
management of the variability and traceability of the
security requirements related artefacts of the SPL
and its products along with the SPL and its products
security standards certification. The Security
Requirement Decision Model supports the capturing,
specifying and reasoning about security
requirements and their artefacts for the SPL
members. It furthermore supports the development
of a security requirement protection profile for the
security goals of the system and it is also helpful in
the process of determining the most appropriate
security requirements artefacts and security
standards.
3.1 Security Variability Model
Our proposed Security Variability Model, which will
be shown in Figure 2 is based on the Reusable
Assets Specification (RAS), adopted as an OMG
standard (OMG_(Object_Management_Group)
2004) and moreover extends the orthogonal
variability model of Pohl et al.(Pohl et al., 2005). It
is also part of the Security Requirement Decision
Model. This variability model relates the defined
variability to other software development models
such as feature models, use case models, design
models and test models. Thus, it provides a cross-
cutting view of the security requirements variability
across all security development artefacts and assists
in keeping the different views of variable security
requirements artefacts consistent.
In order to relate the variability defined in the
variability model to the software artefacts specified
in other models, the meta-model depicted in Figure 2
contains the class ‘artefact’ which represents any
kind of development artefact. Particular
development artefacts are sub-classes of the
‘artefact’ class, such as ‘security artefact’ which is a
specialization of an artefact.
In addition, as is depicted in Figure 2, a security
artefact can but does not have to be categorized. The
‘category’ class helps us avoid semantic problems
and assists in reusing security artefacts, and even in
applying security patterns. It is a key class for the
security requirement decision model, because it
guides us through the categories thus allowing us to
identify the security requirements artefacts
systematically. Moreover, the ‘security artefact’
SECRYPT 2008 - International Conference on Security and Cryptography
444