Lecture 2: SECURITY MODELLING:

Understanding security goals and business activities

•  Altuhhova, O.; Matulevičius, R.; Ahmed, N. (2012). Towards Definition of Secure Business Process. In: LNBIP, CAiSE 2012 Workshop on Information Systems Security Engineering (WISSE’12). Springer Heidelberg, 2012, 1-15.

•  Matulevičius R., Mouratidis H., Mayer N.,Dubois E., Heymans P. (2012) Syntactic and Semantic Extensions to Secure Tropos to Support Security Risk Management, Journal of Universal Computer Science, vol. 18, no. 6, 816-844 72#

Security Risk Management Domain Model

#73##

What is Modelling?

#75##

Modelling… •  Modelling can guide elicitation:

–  It can help you figure out what questions to ask –  It can help to surface hidden requirements

•  i.e. does it help you ask the right questions?

•  Modelling can provide a measure of progress: –  Completeness of the models -> completeness of the elicitation (?)

•  i.e. if we’ve filled in all the pieces of the models, are we done?

•  Modelling can help to uncover problems –  Inconsistency in the models can reveal interesting things…

•  e.g. conflicting or infeasible requirements •  e.g. confusion over terminology, scope, etc •  e.g. disagreements between stakeholders

•  Modelling can help us check our understanding –  Reason over the model to understand its consequences

•  Does it have the properties we expect? –  Animate the model to help us visualise/validate the requirements

#76##

•  A model is more than just a description –  it has its own phenomena, and its own relationships among those

phenomena. •  The model is only useful if the model’s phenomena correspond in a

systematic way to the phenomena of the domain being modelled

Source: Adapted from Jackson, 1995, p120-122

For every B, at least one P exists such that R(P, B)

The application

domain

Designations for the application

domain

Common Properties

The modelling domain

Designations for the model’s domain

B = Book P = Person R = Wrote

Book: entity Person: entity

author: relation

Systems involves a lot of modelling

Booktitle

author (0,n)(1,n)

nameISBN

Person

#77##

“It’s only a model” •  There will always be:

–  phenomena in the model that are not present in the application domain –  phenomena in the application domain that are not in the model

•  A model is never perfect –  “If the map and the terrain disagree, believe the terrain” –  Perfecting the model is not always a good use of your time...

Source: Adapted from Jackson, 1995, p124-5

…every book has at least one author……every book has a

unique ISBN…

Common Phenomena

…ghost writers……pseudonyms…

…anonymity…

…no two people born on same date with same name…

Booktitle

author (0,n)(1,n)

nameISBN

Person

DOB

Phenomena not captured in the model

Phenomena not true

in the world

78#

Modelling Languages

#79##

KAOS (goals for software spec.)

i* (actor and goal modelling)

Use cases

Activity diagrams

Class diagrams

Component diagrams

BPMN

Early requirements

Late requirements

Architectural design

Detailed design

Implementation and testing

Security Modelling Languages

#80##

KAOS extension to security

Secure TROPOS

Misuse cases

Mal-activity diagrams

UMLsec

SecureUML

Early requirements

Late requirements

Architectural design

Detailed design

Implementation and testing

Security Risk-aware BPMN

Security Modelling Languages

#81##

KAOS extension to security

Secure TROPOS

Misuse cases

Mal-activity diagrams

UMLsec

SecureUML

Early requirements

Late requirements

Architectural design

Detailed design

Implementation and testing

Security Risk-aware BPMN

Goal modelling •  Approach

–  Focus on why a system is required –  Use goal refinement to arrive at specific

requirements –  Goal analysis

•  document, organize and classify goals –  Goal hierarchies show refinements and

alternatives •  Advantages

–  Reasonably intuitive –  Explicit declaration of goals provides sound

basis for conflict resolution

•  Disadvantages –  Captures a static picture - what if goals

change over time? –  Can regress forever up (or down) the goal

hierarchy

82

•  Goals:+–  Describe#func3ons#that#

must#be#carried#out#

•  Actors:+–  Owners#of#goals#

•  Tips:+–  Mul3ple#sources#@#beAer#

goals#–  Associate#stakeholders#with#

each#goal#–  Use#scenarios#to#explore#

how#goals#can#be#met#

Tropos Constructs

83#

#84##

Tropos Constructs

85#

Secure Tropos

#86##

•  Security constraint –  Restriction related to

the security of the system

–  Influence the analysis and design of a system

–  Restricts alternative design solutions

•  Secure dependency –  Introduces security

constraint(s) that must be fulfilled for the dependency to be satisfied

#88##

Context and Assets Identification

•  Description of organisation and its environment –  sensitive activities related to information security

88#

#89##

Security Objectives Determination •  Determine the security objectives to be reached

–  Confidentiality, Integrity, Availability

89#

#90##

Risk Analysis and Assessment

•  Identify risks and estimate them qualitatively or quantitatively

90#

#91##

Risk Analysis and Assessment

•  Identify risks and estimate them qualitatively or quantitatively

91#

#92##

Risk Treatment Decisions

Risk+treatment+decisions+

Defini@on+

Avoiding+risk+ Decision#not#to#be#involved#in,#or#to#withdraw#from#a#risk#

Transferring+risk+ Sharing#with#another#party#the#burden#of#loss#for#a#risk#

Retaining+risk+ Accep3ng#the#burden#of#loss#from#a#risk#

Reducing+risk+ Ac3on#to#lessen#the#probability,#nega3ve#consequences,#or#both,#associated#with#a#risk#

92#

#93##

Security Requirements Definition •  Security requirements - security solutions to

mitigate the risks

•  If security requirements are unsatisfactory –  Revise the risk treatment step –  Revise all of the preceding steps

93#

#94##

Control Selection and Implementations •  Implement system countermeasures within

organisation

94#

Business Process Modelling •  Approach

–  What organisation needs to do to achieve their business objectives?

•  Advantages –  Reasonably intuitive –  Explicit declaration of business

activities, processes and sub-processes

•  Disadvantages –  Captures only

a dynamic picture –  Not focussed on the business

support by technology

97

Business Process Model and Notation version 2.0

•  Descriptive Modelling •  Analytical Modelling •  Executable Modelling

#98## (White, 2004, http://www.bpmn.org/)

Business Process Model and Notation Simple example

#99## (White, 2004, http://www.bpmn.org/)

#101##

Asset identification // Security objectives determination

101#

#102##

Asset identification // Security objectives determination

102#

#103##

Risk Analysis

103#

104#

#105##

Risk Treatment Decisions

Risk+treatment+decisions+

Defini@on+

Avoiding+risk+ Decision#not#to#be#involved#in,#or#to#withdraw#from#a#risk#

Transferring+risk+ Sharing#with#another#party#the#burden#of#loss#for#a#risk#

Retaining+risk+ Accep3ng#the#burden#of#loss#from#a#risk#

Reducing+risk+ Ac3on#to#lessen#the#probability,#nega3ve#consequences,#or#both,#associated#with#a#risk#

105#

#106##

Security Requirements Definition •  Security requirements - security solutions to

mitigate the risks

•  If security requirements are unsatisfactory –  Revise the risk treatment step –  Revise all of the preceding steps

106#

107#

What have we learnt?

•  Security Risk Management Process •  Security Risk-oriented Modelling Languages

–  Secure Tropos –  Security Risk-aware BPMN –  Misuse cases –  Mal-activity diagrams

109#