Modeling Security Requirements Through Ownership, Permission and Delegation

1. Modeling Security Requirements Through Ownership, Permission and Delegation A comedy in 10 acts plus an epilogue starring F.Massacci Also starring P. Giorgini J. Mylopoulos N. Zannone www.troposproject.org

2. What’s on Stage • Know thy speaker • The piece • Act 1 - The landascape out there • Act 2 - The father • Act 3 - An honest day’s work • Act 4 -The tale of two brothers • Act 5 - Shadows at dusk • Act 6 - Enter our hero • Act 7 - Going into the battlefield • Act 8 - Dr. Trust and mr. Mistrust • Act 9 - The step-sister • Act 10 - Looking into the future • Epilogue - Brave new world

3. Know Thy Speaker • Fabio Massacci Academic Biography • 1994 - 1998 - PhD at University of Rome I (Automated Reasoning with Applications to Security) • 1999 – 2001 Assistant Professor in Siena • 2000 – Visiting Researcher at IRIT-CNRS Toulouse France • 2001 – now Associate (now Full) Professor at Univ. of Trento • Current research interest security engineering and formal verification of security properties • The Dark Side • 1991 – Volunteer in Refugee Camps in Croatia • 1994 – 1996 National Committee of Italian Campaign for Tax Objection to Military Expences • 1993 – 1997 European Treasurer of International Non Governamental Organization (a past time with 20+ national member branches) • 2002 - Deputy Rector for ICT Procurement (another past time at 4M€/year)

4. Act 1 – The Landscape Out There How a Large Enterprise Project Looks Like

5. A story… • Who? • Leading International Consultancy Company • Leading European ERP Provider • Local Software Integrator for e-Goverment - owned by the Local Goverment • Public Administration Human Resources Department • Public Administration IT Department • What? • Human Resource IT System

6. The plot • A 2+M€ project for the verticalized ERP system for management of human resources in the public administration to be done on an integrated ERP platform hosted in outsourcing • HR management in public administration is complex: • your time in employment may be longer than the period you have actually been employed because you can count the military service into that or the service into another public institution. • When you run for a open call for (higher up) post and you win, the day you change role you formally resign from the old job and are hired to the new job… • A Virtual Organization was set up to sell the result of the project to other public administrations • 2 years of modelling and design and the project go live • Local SW Integrator responsible for the actual verticalization of ERP and corrective maintenance and evolution • Old HR systems turned off by Administration IT department and new system is run in outsourcing to local integrator.

7. Software Engineering our story • Very Interesting Case Study • Complex Organizational Scenario • Complex relations between partners • Internal structures and departments • Complex Processes • Dependencies of Actors • Outsourcing of data processing • Security & Privacy • Authorization issues on promotion and demotion • Lots of privacy sensitive data

8. Act 2 – The Father What You Always Wanted to Know About AOSE and Didn’t Care to Ask...

9. What is Software? • Traditional view • An engineering artifact, designed, tested and deployed using engineering methods; rely heavily on testing and inspection for validation (Engineering perspective) • A mathematical abstraction, a theory, which can be analyzed for consistency and can be refined into a more specialized theory (Mathematical perspective) • More Recent Views • A non-human agent, with its own personality and behavior, defined by its past history and structural makeup (Cognitive Science perspective) • A social structure of software agents, who communicate, negotiate, collaborate and cooperate to fulfil their goals (Social perspective)

10. Agent-Oriented Software Engineering • Research on the topic generally comes in two flavours: • Extend UML to support agent communication, negotiation etc. (e.g., Bauer and Odell); • Extend current agent programming platforms (e.g., JACK) to support not just programming but also design activities (Jennings et al). • Here we use a methodology for building agent-oriented software which supports requirements analysis, as well as design.

11. What is an Agent? • A person, an organization, certain kinds of software. • An agent has beliefs, goals (desires), intentions. • Agents are situated, autonomous, flexible, and social. • But note: human/organizational agents can’t be prescribed, they can only be partiallydescribed. • Software agents, on the other hand, have to be completely specified during implementation. • Beliefs correspond to (object) state, intentions constitute a run-time concept. For design-time, the interesting new concept agents have that objects don’t have is... ...goals!

12. i* - Tropos Methodology • Agent-Oriented RE Methodology • Agents, Roles • Goals, Tasks, Resources • Dependency among agents (A depends on B on G, if A wants G to be done and B agrees to look after that) • Goal Decomposition (AND/OR, pos./neg. contribution) • Adequate for the case at hand • Easy to Understand by Users for Early RE • Good for Modelling Organizations • Formal Reasoning Tools Available • www.troposproject.org • But there might be your own favourite… 6/17

13. i* - Tropos Methodology (cont) • Four phases of software development: • Early requirements -- identifies stakeholders and their goals The organizational environment of a software system can be conceptualized as a set of business processes, actors and/or goals. • Late requirements -- introduce system as another actor which can accommodate some of these goals. • Architectural design -- more system actors are added and are assigned responsibilities; • Detailed design -- completes the specification of system actors.

14. Tropos vs The World JACK i* TROPOS GAIA KAOS Z AUML UML, Catalysis & Co. Nothing here!! Detailed design Architectural design Early requirements Late requirements Implementation

15. Why Worry About Human/Organizational Agents? • Because their goals lead to software requirements, and these influence the design of a software system. • Note the role of human/organizational agents in OOA, --> use cases. • Also note the role of agents in up-and-coming requirements engineering techniques such as KAOS [Dardenne93]. • In KAOS, requirements analysis begins with a set of goals; these are analysed/decomposed to simpler goals which eventually either lead to software requirements, or are delegated to external agents.

16. Act 3 – A Honest Day’s Work How the i*/Tropos Methodology for Requirements and Software Engineering works

17. Early Requirements:External Actors and their Goals A social setting consists of actors, each having goals (and/or softgoals) to be fulfilled. Low cost scheduling Manager Participant Good meeting Schedule meeting Productive meetings Schedule meeting

18. Minimal effort Quality of schedule Degree of participation Minimal conflicts Collection effort Matching effort Schedule meeting Goal Analysis + - + - + - - + Collect timetables Choose schedule By person By system Manually Automatically By all means By email Have updated timetables Collect them

19. Actor Dependency Models Initiator ContributeToMtg UsefulMtg ScheduleMtg CalendarInfo Scheduler Participant AttendMtg SuitableTime Actor dependencies are intentional: One actor wants something, another is willing and potentially able to deliver.

20. Using These Concepts • During early requirements, these concepts are used to model external stakeholders (people, organizations, existing systems), their relevant goals and inter-dependencies. • During late requirements, the system-to-be enters the picture as one or a few actors participating in i* models. • During architectural design, the actors being modelled are all system actors. • During detailed design, we are not adding more actors and/or dependencies; instead, we focus on fully specifying all elements of the models we have developed.

21. Late Requirements with i* Initiator ContributeToMtg UsefulMtg ScheduleMtg System CalendarInfo Timetable manager Participant Scheduler Manage CalendarInfo AttendMtg MtgInfo Reporter SuitableTime

22. Software Architectures with i* System Timetable manager Collect CalendarInfo Participant Update MtgInfo CalendarInfo InfoGatherer Retrieve MtgInfo Reporter Updater Process query Retriever

23. i*/Tropos - Development Process • Initialization: Identify stakeholder actors and their goals; • Step: For each new goal: • adopt it; • delegate it to an existing actor; • delegate it to a new actor; • decompose it into new subgoals; • declare the goal “denied”. • Termination condition: All initial goals have been fulfilled, assuming all actors deliver on their commitments.

24. i*/Tropos – Development Process II • Actor Diagram • Goals and Subgoals of an actor • Goals that an actors wants • Functional Dependency Diagram • Delegation of Execution • Refinements by • Goal Decomposition within an Actor Diagram • Goal Execution Delegation to agents in a Dependency Diagram • Implicitly if adding a dependency on Goal G from A to B means that G becomes a goal of B. • (Computer Supported) Analysis • Qualitative and Quantitative Goal Fulfillment

25. Tropos vs The World JACK i* TROPOS GAIA KAOS Z AUML UML, Catalysis & Co. Nothing here!! Detailed design Architectural design Early requirements Late requirements Implementation

26. We have all we need, don’t we? • Steps • Model the Actors and their functional goals and tasks • Model the Dependencies • Analyze the model (eg showing goals are fulfilled) • Refine the models and iterate • Yet… • some (essential according users) functionality have no correspondance into requirements • some requirements have no correspondance into functions • Some questions on privacy and security cannot be answered (and even expressed) • Eg. do we respect need-to-know privacy principle of EU legislation?

27. Act 4 – The Tale of Two Brothers Software vs Security Engineering, a critical review

28. Software vs Security Engineering • Are security bugs different from ordinary bugs? On balance I claim that they are, not for a technical but for a social reason. • Consider a paradigmatic “ordinary” bug, such as library that wrongly calculates the square root of 2 while apparently doing everything else right. • After certain amount of hilarity the community response would be either to use a different library , or, more likely, to avoid taking the square root of 2. • If a security bug is found in a system there is a community of people who make their personal priority to make the wrong behavior happen, typically in other people’s computers. R. Needham - U. of Cambridge

29. Security vs Software Engineering II • Software Engineer: design a system so that legitimate users can do what they want to do • Security Engineer: design a system so that unlegitimate 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!

30. Some (Unscholarly) Discarded Ideas… • Discarded idea 1 • Add primitives/constraints to Tropos/Kaos/UML/name-your-pet-RE-formalism for the various security requirements • Confidentiality, authentication, access controls or so on are security services and mechanisms NOT security requirements! • ACID Transactions are a DB service not an IS requirement… • Discarded idea 2 • Model security requirements separately from functional requirements • Well, wheere’s the distinction then? Why at all bother? • Discarded Idea 3 • Model the goals of the attacker • They are not the goals of the security engineer!

31. Same Ideas: Scholarly Classified • 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,]

32. Same Ideas: Scholarly Evaluated • UML Pros and Cons • Well-known even if meta-level extension not standardized • Effective - MDA -> automatic configuration of system • “Too Late” - model of system rather than organization • An average doc for “Security Policy and Security Management” (compulsory for italian public administration) is 30% on ICT systems - 70% on paper or organizational requirements • Worse for privacy legislation • Early requirements Pros and Cons • Capture organizational structure • Modelling done at object-level (limited extensions) • “Too Functional” - Security is modelled explicitly and in parallel with the actual functional model

33. Same Ideas: Scholarly Reclassified • Meta-level approaches • Modify the language to introduce security & privacy features • Pros: modelling more effective and compact • Cons: language constructs must gain “market acceptance”, semantics and reasoning to be upgraded • Object-level approach • Use the language to model security and privacy features • Pros: modelling well established, reasoning features ready • Cons: modelling often cumbersome, some time impossible • Anyhow, we discarded them…

34. Act 5 – Shadows at Dusk A critical review explaining why certain Users Requirements do not look to make sense (but only at Face Value)

35. Back to our story: Users conspire for requirements • Procedures for managing events for employment period calculations included the generation of excel files beside the ERP system • Double entry in both the ERP system and the Excel file • No such double entry existed in the previous system • Actual salary computed only with data on the ERP • The ERP system integrated directly with another SW from a different provider in charge of computing the salary depending on the events • Nigthly backup performed by integrator so this not an issue • Yet Users claimed it essential…

36. The misplaced belief of the RE… • “You will do what Requirements tells you should” (bugs aside) • I’m capturing the requirements and they say that Alice should do X on behalf of Bob. • It goes without saying that Alice will do the job. • I’ll make it sure when “implementing” Alice. • After all I’m collecting these £$%&/ requirements to design the system meeting them. Aren’t we? • Eeer, • Unfortunately it is not possible to tell Alice what to do (i.e. to implement Alice)… Alice is an outsourced data process!! • Delegation does NOT mean trust

37. A conspiracy unveiled… • Dependencies assume implicit trust • Public Administration trusted ERP and Consulting Company to design correct conceptual model • Local Integrator trusted Consulting Company to receive correct conceptual model • Public Administraton trusted Local IT Integrator to correctly implement model and guarantee integrity of data. • IT and HR Department part-of of P.A. • But trust might not be there • A director of IT Department trusted correct implementation • So ordered old system to be turned down • B vice-director of HR Department in charge of the system, and C vice-director of IT department, both in charge of the project did NOT trust the Local Integrator to perform complete test suite on their procedure and guarantee data integrity… • So set up the “check up” Excel procedure (actually they were right…)

38. The plot thickens… • The outsourced services was perfomed on three platforms • Local Integrator managed all three platforms (Devel, Test, Production) • Provided development for maintenance and evolution once receiving a request from Public Administration (opening and serving a ticket) • Tested its own changes and those by Public Administration • Sometime PA wanted to know everybody • Local Integrator had to communicate all administrators of the testing and production system and their actions had to be logged • Testers that were not from Public Administration and had access to Public Administration data test suite communicated back and logged • Sometime Public Administration didn’t want to know • Receiving ticket Local Integrator had to tell responsible for service • Closing of the ticket to be agreed with the requestor and then performed • Actual staff in charge of the ticket was not requested, nor logged, neither users nor administrator of develop platform

39. The misplaced belief of the SE… • “You can do whatever the Software let you do” • I’m fulfilling requirements and Bob needs X from Alice. • It goes without saying that Alice can do the job. • We have just “designed” the server Alice to meet requirements of providing data to Bob. • Anything extra Alice does is good, provided she at least meet the requirements, isn’t it? • Eeer, • unfortunately X is a data from Charlie we cannot give it to Bob unless Charlie agrees. • Alice just happens to have it in store for him • Delegation of execution and delegation of permissions do NOT coincide

40. i*/Tropos Methodology Re-assessed • Limitation • Mindset is Cooperative Information Systems • Only Functional Requirements, No trust at language level • Misplaced Assumptions (for our puroposes): • If Alice provides a service she has also the authority to decide who can use it • If designer delegates goal G from Alice to Bob doesn’t mean Bob should be willing to do it and trusted to do it! • Key idea to overcome it • Distinction between goals of the actors described in the model and goals of the designers • Design a non-cooperative information system!

41. Act 6 – Enter Our Hero A Quick Introduction to Secure Tropos

42. Some (Unscholarly) Good Ideas… • Hunch 1 • 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 • Hunch 2 • 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, mechs

43. Some Ideas ReAssessed • UML • CORAS notion of asset [Lund et al.] in UML standard for risk management • Early Requirements • Tropos idea of stakeholders analysis and strategic dependencies [Yu & Mylopoulos] • Security-Aware Tropos notions of ownership and trust [Giorgini et al.]

44. SecureTropos - Informal Model • Add-ons • Distinction between wanting/offering/owning a goal • Trust relationship on Agent/goals/Agents • Some agents want some goal/task to be done • Hospital doctor wants to consult medical record • Other agents offer this goal/task • Nephrology ward locker stores medical records • Another agent owns this goal/task • Patient owns the medical record • Agents trust other agents on the goal • Patient trust Hospital to store medical record

45. Secure Tropos Extra Constructs • Trust Relationship Among Actors • Tells the trusted legitimated from the untrusted unlegitimate • Ownership != Provisioning • Tell’s who’s actually offering a service from who’s entitled to decided who can use the service • Permission != Execution • I trust you to at-most fulfill a goal (permission) • I trust you to at-least fulfill a goal (execution)

46. Permission vs Execution • at-most delegation: when the delegater wants the delegatee to fulfill at most a service • This is delegation of permission • The delegatee thinks “I have the permission to fulfill the service (but I do not need to)” • at-least delegation: when the delegater wants the delegatee to perform at least the service • This is delegation of execution • The delegatee thinks “Now, I have to get the service fulfilled (let’s start working)” • Good Old i* Dependency • Delegation of Execution + Trust of Execution • No notion of ownership: if you depend on X to fulfil G, X is by default authorized to do G.

47. i*/Tropos Revisited • 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 trust that B will do it • Wanting = Owning • If designer says 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. • Point of View of Designer => Point of View of Actors

48. Act 7 – Entering into the Battlefield How the Secure Tropos Constructs can be integrated and used in the software development process

49. SecureTropos - Methodology • Actor Diagram • Goals that an actors wants, provides, or owns • Functional Dependency Diagram • Delegation of Execution • Trust Dependency Diagram • Trust of Execution and Permission Relations • Trust Management Diagram • 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 • (Computer Supported) Analysis • Goal Fulfillment (Functional Delegation Chain) • Need-to-do (a chain of Dpermission only if there is a chain of Dexecution) • Trusted Execution (Trust Chain Match Funct. Deleg. Chain) • Trusted Delegation (Trust Chain Match Permis. Deleg. Chain)

50. Never Without a Screen Dump…