Security Risk Management Domain Model

Size: px

Start display at page:

Download "Security Risk Management Domain Model"

Trevor French
6 years ago
Views:

1 Lecture 2: Security Modelling Understanding security goals and secure business activities Dr. Raimundas Matulevičius 1" Security Risk Management Domain Model "2""

2 Goals and Questions What is modelling? What is Tropos Secure Tropos Security Risk-aware Secure Tropos What is BPMN Security risk-oriented BPMN 3" What is Modelling? "5""

3 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 "6"" Systems involves a lot of modelling 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 The application domain Book (1,n) author ISBN title name (0,n) Person The modelling domain Designations for the application domain B = Book P = Person R = Wrote Book: entity Person: entity author: relation Designations for the model s domain Common Properties For every B, at least one P exists such that R(P, B) Source: Adapted from Jackson, 1995, p "7""

4 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 Book (1,n) author ISBN title name DOB (0,n) Person Phenomena not captured in the model ghost writers pseudonyms anonymity Common Phenomena every book has at least one author every book has a unique ISBN 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 Phenomena not true in the world no two people born on same date with same name 8" Modelling Languages Early requirements Late requirements Architectural design Detailed design Implementation and testing BPMN i* (actor and goal modelling) KAOS (goals for software spec.) Use cases Activity diagrams Class diagrams Component diagrams "9""

5 Security Modelling Languages Early requirements Late requirements Architectural design Detailed design Implementation and testing Security Risk-oriented BPMN Secure TROPOS KAOS extension to security Misuse cases Mal-activity diagrams UMLsec SecureUML "10"" Security Modelling Languages Early requirements Late requirements Architectural design Detailed design Implementation and testing Security Risk-oriented BPMN Secure TROPOS KAOS extension to security Misuse cases Mal-activity diagrams UMLsec SecureUML "11""

6 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 13 Goals:- Describe"func2ons"that" must"be"carried"out" Actors:- Tips:- Owners"of"goals" Mul2ple"sources"?"be@er" goals" Associate"stakeholders"with" each"goal" Use"scenarios"to"explore" how"goals"can"be"met" Tropos Constructs 14"

7 "15"" Tropos Constructs 16"

Secure Tropos Security constraint Restriction related to the security of the system Influence the analysis and design of a system Restricts alternative design

8 Secure Tropos 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 "17"" Security risk management process "19""

"20"" 20" Security Objectives Determination Determine the security

9 Context and Assets Identification Description of organisation and its environment sensitive activities related to information security "20"" 20" Security Objectives Determination Determine the security objectives to be reached Confidentiality, Integrity, Availability "21"" 21"

22" estimate them qualitatively or quantitatively

10 Risk Analysis and Assessment Identify risks and estimate them qualitatively or quantitatively "22"" 22" Risk Analysis and Assessment Identify risks and estimate them qualitatively or quantitatively "23"" 23"

11 Risk Treatment Decisions Avoiding-risk- Transferring-risk- Retaining-risk- Reducing-risk- Risk-treatment- decisions- Defini?on- Decision"not"to"be"involved"in,"or"to" withdraw"from"a"risk" Sharing"with"another"party"the" burden"of"loss"for"a"risk" Accep2ng"the"burden"of"loss"from"a" risk" Ac2on"to"lessen"the"probability," nega2ve"consequences,"or"both," associated"with"a"risk" "24"" 24" Security Requirements Definition Security requirements - security solutions to mitigate the risks "25"" If security requirements are unsatisfactory Revise the risk treatment step Revise all of the preceding steps 25"

Advantages Reasonably intuitive Explicit declaration of business activities, processes and

12 Control Selection and Implementations Implement system countermeasures within organisation "26"" 26" 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 28

13 Business Process Model and Notation version 2.0 Descriptive Modelling Analytical Modelling Executable Modelling "29"" (White, 2004, Business Process Model and Notation Simple example "30"" (White, 2004,

14 31" Asset identification // Security objectives determination "34"" 34"

15 Risk Analysis "35"" 35" Risk Treatment Decisions Avoiding-risk- Transferring-risk- Retaining-risk- Reducing-risk- Risk-treatment- decisions- Defini?on- Decision"not"to"be"involved"in,"or"to" withdraw"from"a"risk" Sharing"with"another"party"the" burden"of"loss"for"a"risk" Accep2ng"the"burden"of"loss"from"a" risk" Ac2on"to"lessen"the"probability," nega2ve"consequences,"or"both," associated"with"a"risk" "36"" 36"

16 Security Requirements Definition Security requirements - security solutions to mitigate the risks "37"" If security requirements are unsatisfactory Revise the risk treatment step Revise all of the preceding steps 37" Control Selection and Implementation "38"" 38"

17 Message to take home Security Modelling Security Modelling Languages Security risk-aware Secure Tropos Security risk-oriented BPMN Misuse cases Mal-activity diagrams 40"

Goal. Introduce the bases used in the remaining of the book. This includes

Goal. Introduce the bases used in the remaining of the book. This includes Fundamentals of Secure System Modelling Springer, 2017 Chapter 1: Introduction Raimundas Matulevičius University of Tartu, Estonia, rma@ut.ee Goal Introduce the bases used in the remaining of the book.