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

Ta b l e 1 Alignment of five concepts

References (1) (2) (3) (4) (5)

ISO/IEC Guide 73 Risk Event Consequence / /

AS/NZS 4360 Risk Event Consequence

Impact

/ /

ISO/IEC 27001 Risk / Impact Threat Vulnerability

ISO/IEC 13335 Risk / Harm Threat Vulnerability

Common Criteria Risk Threat Consequence / Vulnerability

NIST 800-27
NIST 800-30

Risk / Impact Threat Vulnerability

EBIOS Risk Cause Impact / Vulnerability

MEHARI Risk

Risk scenario

/ Consequence / /

OCTAVE Risk / Impact

Consequence

Threat Vulnerability

CRAMM Risk / Loss Threat Vulnerability

CORAS Risk / Unwanted

incident

Threat
scenario

Vulnerability

Haley et al. Moffet
and Nuseibeh

Risk / Impact Threat Vulnerability

Firesmith Risk / Harm Hazard

Threat

Vulnerability

main categories of sources: ( i ) RM standards, ( ii ) security-related standards, ( iii )
security RM methods, and ( iv ) security-oriented RE frameworks.
Step 2 - Construction of the ISSRM domain model . Based on the outcomes of
step 1, we define a conceptual model of the ISSRM domain as a UML class diagram,
complemented with a glossary obtained by reusing and, when needed, improving the
most relevant definitions we found.
Step 3 - Comparison between ISSRM domain model and security-oriented lan-
guages. Prominent security-oriented RE languages (KAOS extended to security
[ 29] , Abuse Frames [ 31] , Misuse Cases [51] , Abuse Case [ 42] and Secure-Tropos
[ 47] ) are confronted with the ISSRM domain model. We investigate the meta-
models and definitions of those languages, trying to find out which concepts of the
ISSRM domain model are fully supported, partially supported or missing. The main
expected results of this step are:

• The validation of the claim that those RE languages overlook RM;

• The assessment of the coverage of each modelling language with respect to

ISSRM;

• The identification of the improvements (extensions or revisions) required to make

the languages suitable for ISSRM.

Step 4 - Definition of ISSRM language support. As mentioned in the intro-
duction, our final goal is to provide ISSRM-compliant versions of common RE
languages. Our aim is to do so by meeting the highest standards in conceptual