Tropos: Security. Agent-Oriented Software Engineering course Laurea Specialistica in Informatica A.A

Transcription

1 Tropos: Security Paolo Giorgini Department of Information and Communication Technology University of Trento - Italy Agent-Oriented Software Engineering course Laurea Specialistica in Informatica A.A

2 Talk Outline Security Requirements Engineering Reviewing the state-of-the-art Secure Tropos Modeling Framework Formal Framework Computer-Aided SRE Ongoing and Future Work Demo and Case Study P. Giorgini 2

3 Security and Requirements Engineering Traditional RE approaches treat security as a nonfunctional requirement According to this view security requirements are modeled as quality constraints under which the system must operate These need to be integrated with other non-functional requirements (e.g., reliability and performance), to be dealt with by the software development process P. Giorgini 3

4 Security in SE Practice The usual approach towards the inclusion of security within a system is to identify security requirements after system design Most SE proposals focus on protection aspects of security and explicitly deal with a series of security services (integrity, availability, etc.) related protection mechanisms (password, crypto, etc.) Security mechanisms have to be fitted into a pre-existing design may not be able to accommodate them security requirements can generate conflicts with functional requirements of the system Big gap between solutions and the requirements of the entire system P. Giorgini 4

5 Security Requirements Engineering Introduce security requirements analysis in the early phases of the software development process This allows us to elicit security requirements from the organizational environment analyze security requirements within the organizational environment in which the software will operate motivate the use of specific security mechanisms P. Giorgini 5

6 Object- vs Meta-Level Approaches Object-level approach Use an off-the-shelve framework (e.g., UML, Kaos, i*/tropos) as it is for modeling security requirements Pro: modeling well established, reasoning feature ready Con: modeling often cumbersome, some time impossible Meta-level approach Take a RE framework and enhance it with novel constructs specific to security Pro: modeling more effective and compact Con: language constructs must gain market acceptance, semantics and reasoning to be update P. Giorgini 6

7 Security vs Software Engineering Software Engineer: design a system so that legitimate users can do what they want to do Security Engineer: design a system so that illegitimate users cannot do what they should not do Contentious Consequence We cannot use traditional Requirements or Software Engineering methodologies for Security, they have different overall goals! P. Giorgini 7

8 Some Discarded Ideas Discarded idea 1 Add primitives to Tropos/Kaos/UML/name-your-pet-RE-formalism to accommodate various security requirements Confidentiality, authentication, access controls, etc., are security services and mechanisms NOT security requirements! Discarded idea 2 Model security requirements separately from functional requirements Well, whereʼs the distinction then? Why bother? Discarded Idea 3 Model the goals of the attacker They are not the goals of the security engineer! P. Giorgini 8

9 Other Ideas UML Proposals SecureUML, Model-Driven Architecture [Basin et al.] UMLsec [Juriens] Abuse Cases [McDermott & Fox] Misuse Cases [Sindre & Opdhal] Early Requirements Proposals Anti-requirements [van Lamsweerde et al., Crook et al.], Problem-Frames, Abuse Frames [Hall et al., Lin et al] Security Patterns [Giorgini & Mouratidis] Privacy Modelling [Liu et al., Anton et al,] P. Giorgini 9

10 Early Discussion UML Pros and Cons Well-known even if meta-level extension not standardized Too Late - model of system rather than organization Early requirements Pros and Cons Capture organizational structure Too Functional - Security is modelled explicitly and in parallel with the actual functional model P. Giorgini 10

11 SecureUML D. Basin, J. Doser, and T. Lodderstedt, 2003 They provide support for specifying access control policies The concepts of RBAC are represented as metamodel types User, Role, Permission, Actions are types UserAssignment, PermissionAssignment, RoleHierarchy are relations AuthorizationConstraint is a predicate attached to a permission by the association ConstraintAssignement Authorization constraints expressed in first-order logic Used to establish the validity of the permission P. Giorgini 11

12 SecureUML Metamodel D. Basin, J. Doser, and T. Lodderstedt. Model driven security for process-oriented systems. In Proc. of SACMAT '03, pages ACM Press, P. Giorgini 12

13 SecureUML Semantics An access control configuration is an assignment of users and permissions to role SecureUML makes access control decisions based on the access control configuration and on the validity of authorization constraints in a certain system state Verify if a user is allowed to perform actions in the system state at a certain time with respect to an access control configuration P. Giorgini 13

14 Limits of SecureUML NOT analyze security requirements within the organizational environment in which the software system will operate Require to know conflicting roles a priori NOT detect conflicts from the requirements model of the system P. Giorgini 14

15 Use Case Diagram Build a first sketch model of a system Characterize a way of using a system Offer a notation for describe the functionality of a system Actors: an abstraction of an external agent that interact with the system Use cases: specification of a type of interaction between a system and agents Association lines: connect agents with the use cases in which they participate P. Giorgini 15

16 Reservation System P. Giorgini 16

17 Abuse Cases McDermott & Fox, 1999 Negative use cases for modeling security requirements Specify an interaction between a system and one or more actors, where the results of the interaction are harmful to the system or one of the actors in the system Actors are the same that participate in use cases P. Giorgini 17

18 Reservation System P. Giorgini 18

19 Limits of Abuse Cases Model security requirements separately from functional requirements Abuse case diagrams show abuse only, not abuse together with normal use They do not investigate relations between use and abuse P. Giorgini 19

20 Misuse Cases Guttorm Sindre and Andreas Opdahl, 2000 Extend use cases for modeling security requirements Specify behaviour that the system should avoid Specify how a misuser can damage the system P. Giorgini 20

21 Concepts Misuser hostile actor a similar notation as an actor in use cases, except the misuser has a black "head" instead of white Misuse case course of actions performed to do harm to a stakeholder or the system itself behavior that is not wanted in the system illustrated by black circles Use cases functionalities of the system countermeasures against misuse Relations includes and extends prevents : use case prevents the activation of a misuse case detects : use case detects the activation of a misuse case P. Giorgini 21

22 E-Commerce G. Sindre and A. Opdahl. Eliciting Security Requirements by Misuse Cases. In Proc. of TOOLS Pacific P. Giorgini 22

23 Special mis-actors G. Sindre and A. Opdahl. Eliciting Security Requirements by Misuse Cases. In Proc. of TOOLS Pacific P. Giorgini 23

24 Advantages Focus on security in the early phases of the software development process Increase the chance of discovering threats that otherwise would have been ignored Help to trace and organize the requirements specification Help to evaluate requirements the real cost of implementing a use case includes the protection needed to mitigate all serious threats to it Easy to reuse in new development projects P. Giorgini 24

25 Disadvantages Use/Misuse case are informal No clear semantics (Hence) NO formal analysis No knowledge on how to write good quality misuse cases The focus is ONLY on the system-to-be NOT suitable for all kinds of threats There is not always an identifiable misuser and the misuse case may not always consist of an identifiable sequence of actions P. Giorgini 25

26 KAOS A research project Used to formalize goals into requirements Derive a description of a system's behavior Analyze system structure through acquiring and formalizing functional and non-functional requirements Supported by GRAIL tool P. Giorgini 26

27 KAOS concepts Agents active component of the system play some role Goals prescriptive statements of intent about the system functional goals: service to be provided non-functional goals: quality of service Domain properties descriptive statements about the environment (e.g., physical laws, norms) P. Giorgini 27

28 Goals Organized in terms of AND/OR hierarchies Goal refinement used to construct a refinement-abstraction hierarchy High level goals are strategic Coarse grained with many agents Low level goals are technical Fine grained involving less agents Requirement: terminal goal for one agent P. Giorgini 28

29 Obstacles Identify goal violation scenarios An obstacle to some goal is a condition whose satisfaction may prevent the goal from being achieved An obstacle O is said to obstruct a goal G in domain Dom iff {O,Dom} G Obstruction Dom O Domain consistency P. Giorgini 29

30 Obstacles Analysis Obstacles analysis consists in taking a pessimistic view of goals Identify as many ways of breaking goals as possible in order to resolve each of such situations Formal techniques for generation and AND/OR refinement of obstacles are available Obstacles need to be resolved once they have been generated Resolution techniques: goal substitution, agent substitution, goal weakening, goal restoration, obstacle prevention and obstacle mitigation Obstacle analysis is a recursive process it may produce new goals for which new obstacles may be generated and resolved P. Giorgini 30

31 Security Goals Considered a meta-class High level of abstraction Confidentiality Integrity Availability Privacy Authenticity Non-repudiation Each security goal has to be instantiated into applicationspecific security goal P. Giorgini 31

32 Confidentiality Goal Confidentiality Goal Avoid[SensitiveInfoKnownByUnauthorizedAgent] FormalSpec ag: Agent, ob: Object Authorized(ag,ob.Info) Knows(ob.Info) If an agent ag is not authorized to access info about an object ob, then he does not knows any information info about the object ob Goal Avoid[PaymentMediumKnownBy3rdParty] FormalSpec p: Agent, acc: Account (Owns(p,acc) Manages(p,acc)) (Knows(acc.Acc#) Knows(acc.PIN)) If agent p is not the owner of account acc and he should not manage it, he does not know number and PIN of the account P. Giorgini 32

33 Obstacles Analysis Taking the negation of the goal (NG) p: Agent, acc: Account (Owns(p,acc) Manages(p,acc)) (Knows(acc.Acc#) Knows(acc.PIN)) Suppose that the domain theory contains the following properties (D1) p: Agent, acc: Account Owns(p,acc) Knows(p.name) Knows(acc.Acc#) (D2) acc: Account Knows(acc.Acc#) Knows(acc.PIN) We can formally derived the following potential obstacle (O) p: Agent, acc: Account (Owns(p,acc) Manages(p,acc)) Knows(p.name) P. Giorgini 33

34 Anti-goals Obstacles sufficient for modeling and resolving nonintentional obstacles (accidental obstacles) Too limited for modeling and resolving intentional obstacles (malicious obstacles) Active attackers be modeled as well together with their own goals, capabilities, and the vulnerabilities they can monitor or control (anti-models) Anti-goals are the intentional obstacles to security goals P. Giorgini 34

35 Building Anti-models Root anti-goal are obtained by negation of security goals For each anti-goal, potential attacker are identified (WHO) For each anti-goal and corresponding attacker, the higher level antigoals are identified (WHY) For each anti-goal and corresponding attacker, the lower level antigoals are identified (HOW) AND/OR refinement process for anti-goals realizable by the attacker (anti-requirements) realizable by the attacker (vulnerabilities) Anti-models are derived from anti-goals formulations Anti-requirements are defined in terms of the capabilities of the corresponding attacker P. Giorgini 35

36 Running Antigoals Goal Avoid[PaymentMediumKnownBy3rdParty] FormalSpec p: Agent, acc: Account (Owns(p,acc) Manages(p,acc)) (Knows(acc.Acc#) Knows(acc.PIN)) AntiGoal Achieve[PaymentMediumKnownBy3rdParty] FormalSpec ag: Agent, ob: Object (Owns(p,acc) Manages(p,acc)) Knows(acc.Acc#) Knows(acc.PIN) P. Giorgini 36

37 Refining antigoals By asking what are sufficient conditions for someone unauthorized to know the number and PIN of an account simultaneously? AntiGoal Achieve[PaymentMediumKnownBy3rdPartyFromPinSearching] FormalSpec ag: Agent, ob: Object (Owns(p,acc) Manages(p,acc)) Knows(acc.Acc#) ( x:pin) [Find(p,x) Match(x,acc.Acc#)] AntiGoal Achieve[PaymentMediumKnownBy3rdPartyFromAccountNumberSearching] FormalSpec ag: Agent, ob: Object (Owns(p,acc) Manages(p,acc)) Knows(acc.PIN) ( y:acc#) [Find(p,y) Match(acc.PIN,y)] P. Giorgini 37

38 Limits of Antigoals Modeling attackers is difficult We have to consider all the possible obstacles even the ones unknown Many protocols for security are been proved to be incorrect after some years they are designed Many system vulnerabilities depend on the particular implementation Software vulnerabilities are not completely known P. Giorgini 38

39 Tropos and Security Requirements i*/tropos has not been designed with security in mind Lack of the ability to capture at the same time functional and security features of an organization The process of integrating security and functional requirements throughout the whole range of the development stages is quite ad hoc The concept of softgoal that Tropos uses to capture security requirements fails to adequately capture some constraints that security requirements often represent REMARK: softgoals are goals that have no clear-cut definition and/or criteria for deciding whether they are satisfied or not The methodology fails to provide concepts and processes to model trust relationships P. Giorgini 39

40 Tropos Dependency A dependency between two actors means that the dependee will take responsibility for fulfilling the functional goal of a depender Major assumption is that if you provide a service you have also the authority to decide who can use it, but... No way to specify or check whether the dependee is actually authorized to do so It can happen that an actor depends on another for a service, but the dependee is neither the owner of the service nor authorized to provide the service P. Giorgini 40

41 Claim Ownership and permission are at the very foundation of all security concerns no ownership, no security to worry about. If people didn't own human rights, privacy rights, physical property, security would be a meaningless word Permission as a complementary notion to obligation is well-accepted in Deontic Logics So, we introduce it in our modeling framework P. Giorgini 41

42 Moving towards a new proposal Idea 1 Idea 2 Security Requirements are social requirements We need to start from a RE methodology modelling organizations We need to capture the key social requirements for security We must model at the same time Functional Requirements and Security Requirements So we can see the interplay of both and check one does not get in the way of the other Occam's Razor Add few primitive constructs Other security requirements as patterns, services, mechanisms P. Giorgini 42

43 Secure Tropos Use the concepts offered by Tropos for actor, goal, task, and resource Make explicit who is the requester of the service, who is the legitimate owner of a service and who is able to provide a service Refinement of Tropos dependency Trust relationship on Actor/service/Actor Permission!= Execution P. Giorgini 43

44 Requiring, Ownership, and Provisioning Requiring Identify the objectives of actors Ownership Identify actors who are the legitimate owners of goals, plans, or resources The owner has full authority concerning the achievement of his goal, execution of his plan, or use of his resource He can also delegate this authority to other actors Provisioning Identify actors who have the capability to achieve goals, execute plans, or deliver resources P. Giorgini 44

45 Delegation Delegation of permission Used to model formal passage of authority The delegatee thinks I have the permission to fulfill the service (but I do not need to) Delegation of execution Used to model formal passage of responsibility The delegatee thinks Now, I have to get the service fulfilled P. Giorgini 45

46 Trust Trust is a relation between two actors representing the expectation of one actor (the trustor) about the capabilities and behavior of the other (the trustee) Trust of permission the trustor believes that the trustee will not misuse the goal, task, or resource Trust of execution the trustor believes that the trustee will achieve the goal, execute the task, or deliver the resource Trust is the mental counterpart of delegation Delegation is an action due to a decision, whereas trust is a mental state driving such decision P. Giorgini 46

47 Comparing Tropos and S-Tropos Tropos Model Actor Properties objectives Actor Relationships dependency Secure Tropos Model Actor Properties objectives entitlements capabilities Actor Relationships trust of execution delegation of execution trust of permission delegation of permission P. Giorgini 47

48 Comparing Tropos and S- Tropos Dependency = Delegation of Execution + Trust of Execution if designer says A depends on B for G then A has actually delegated fulfillment of G to B and trusts that B will do it if one depends on X to fulfill G, X is by default authorized to do G Wanting = Owning if designer says that A wants G, of course A is authorized to fulfill G Implicit Provisioning When designer stops dependency chain on goal G at agent B, it means that B will take care of it Trust vs Delegation Permit to model scenario where actors must delegate permission or execution to other actors that do not trust P. Giorgini 48

49 Secure Tropos -- Process Actor Diagram Goals that an actors wants, provides, or owns Dependency model - Functional Requirements Model Delegation of Execution Trust Model Trust of Execution and Permission Relations Trust Management Implementation Delegation of Permission Refinements by Goal Decomposition within an Actor Diagram Goal (Execution or Permission) Delegation to agents in a Delegation Diagram Modification of Trust Relationship P. Giorgini 49

50 Example P. Giorgini 50

51 Underlying Formal Model Formal Model Answer Set Programming (aka Datalog ) Deduction, Satisfiability, Abduction Models (Secure Tropos Diagrams) Extensional properties of classes (and instances) Axioms Intensional properties and rules Properties Specify conditions which must not be true in the model Formulae that may be in true or may not be true P. Giorgini 51

52 Axioms A P. Giorgini 52

53 Properties A?B means one must check that each time that A holds it is desirable that also B holds. P. Giorgini 53

54 Requirements Analysis Process P. Giorgini 54

55 Computer-Aided SRE Draw the graphical (Secure) Tropos models Diagrams (automatically) mapped into a Formal Model Datalog specifications Formal Tropos specification Check the properties on the Formal Model Integration within different Datalog solvers DLV System, ASSAT, C-Models, S-Models P. Giorgini 55

56 Secure Tropos Tool P. Giorgini 56

57 Social vs Individual Tropos involves two different levels of analysis Social level: the structure of organizations are defined associating to every role (or position) objectives and responsibilities Individual level: agents are not only defined with their objectives and responsibilities, but also they are associated to roles (or positions) they can play In Tropos there is no explicit separation between the two levels, and it is very difficult to maintain the consistency P. Giorgini 57

58 Social vs Individual (2) It is possible that requirements are given only at individual level or at social level Social => Individual The agents playing a social role should inherit properties and social relations of that role If Alice play R1 and R1 trusts R2 and Bob plays R2 then Alice trusts Bob Useful feature to complete models in Computer aided RE Social relationships are always drawn in RE After all they are among the system specifications Designers must only draw social relationships and the reasoning system does the rest P. Giorgini 58

59 Distrust Need for negative authorizations to help designers in shaping the perimeter of positive trust Distrust is a relation between two actors representing the expectation of one actor about the incapabilities and misbehaviour of the other Used to identify illegitimate actors Distrust as a primitive Model Trust and Distrust as independent primitive Distrust as absence of trust = Close World Assumption Trust Conflicts The presence of positive and negative authorization at the same time could generate conflicts on trust relationships Computer Aided RE automatically detects such conflicts P. Giorgini 59

60 Sample Conflicts Trust at social level Distrust at individual level Distrust at social level (eg procedures imposing restriction on roles) Trust at individual level P. Giorgini 60

61 Verification Process Design models at both social level and individual level, independently Verify correctness and consistency of social level Map relations at social level into models at individual level Solve conflicts if needed Verify correctness and consistency of models at individual level P. Giorgini 61

62 References [1] P. Giorgini, F. Massacci, J. Mylopoulous, and N. Zannone. Requirements Engineering meets Trust Management: Model, Methodology, and Reasoning. In Proceedings of itrustʼ04, LNCS 2995, pages Springer-Verlag, [2] P. Giorgini, F. Massacci, J. Mylopoulous, and N. Zannone. Filling the gap between Requirements Engineering and Public Key/Trust Management Infrastructures. In Proceedings of EuroPKIʼ04, LNCS 3093, pages Springer-Verlag, [3] P. Giorgini, F. Massacci, J. Mylopoulous, and N. Zannone. Modeling Social and Individual Trust in Requirements Engineering Methodologies? To appear itrustʼ05. [4] P. Giorgini, F. Massacci, J. Mylopoulous, A. Siena, and N. Zannone. ST-Tool: A CASE Tool for Modeling and Analyzing Trust Requirements. To appear itrustʼ05. [5] P. Giorgini, F. Massacci, J. Mylopoulous, and N. Zannone. Modeling Security Requirements Through Ownership, Permission and Delegation. Submitted to REʼ05. Tropos project: P. Giorgini 62