A Systematic Approach to Define the Domain of Information System Security Risk Management - Intentional Perspectives on Information Systems Engineering - page 284

Today there exist literally hundreds of IS Security RM (ISSRM) methods and
standards targeted to professionals (see Sect. 3.2 for an overview). They mainly
consist of process guidelines that help identify vulnerable assets, determine security
objectives, and assess risks as well as define and implement security requirements
to treat the risks. By using these methods one reduces the losses that might result
from security problems. However, these methods generally offer very little mod-
elling support. Instead, they usually resort to informal documentation in natural
language and ad hoc diagrams. This means that powerful abstraction mechanisms,
visualisations and automations offered by conceptual modelling techniques are
underexploited.
On the contrary, the Requirements Engineering (RE) literature features a
number of modelling languages specifically dedicated to security-sensitive con-
texts.Examples of such languages are Misuse Cases [ 51] and Abuse Cases [ 42] ,
which extend Use Cases [ 7] ; Abuse Frames [ 31- 33] derive from Problem Frames
[ 27] ; Secure-Tropos [ 17, 46, 47] originates from Tropos [ 4] and i ∗ [ 57] ; KAOS
[ 30] was also extended [ 29] to deal with security aspects. The main benefit of
these languages is to address security concerns in the early phases of IS devel-
opment. This allows enforcing security by construction , which is more effective
than doing it after the fact [ 48] . However, it turns out that these languages lack
constructs to properly represent risk, e.g., vulnerable assets, their associated secu-
rity risks and risk treatments (with the notable exception of [ 2] which supports a
more general notion of risk). Hence, although these languages are useful in eliciting
and modelling threats and countermeasures, they are still largely unable to address
cost-effectiveness concerns in a satisfactory manner.
These observations could be used as arguments in favour of defining a new, more
suitable modelling language. However, defining a completely new notation does not
appear to us as a viable option for at least two reasons. Firstly, this would only
further populate the already overcrowded jungle of modelling languages. Secondly,
we aim at a smooth rather than radical transition from current practice. Existing
languages address different complementary views (e.g., scenario-oriented view,
goal-oriented view

...

), all potentially useful for RE. ISSRM actually crosscuts those
views and should therefore be related to them. So, as long as this does not make the
languages too complex, we rather plead in favour of improving existing languages
with a better coverage of the ISSRM domain.
In this chapter, we do not go as far as proposing an extension to an existing lan-
guage. Instead, we describe an intermediate step which is concerned with answering
the following research question: What are the concepts that should be present in a
modelling language supporting ISSRM during the early stages of IS development?
In this, we follow a similar approach as those pioneers who designed IS modelling
languages back in the eighties [ 49, 50] : first identify the key concepts of the subject
domain, then design (or adapt) a language to support it.
The remainder of this chapter is structured as follows. Section 2 presents the
research method that we have followed for answering this question. In Section 3 we
introduce the basic definitions associated with security and risk management and
present our survey of the literature. Section 4 proposes a synthesis of the surveyed