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#