Modeling Security Requirements Through Ownership, Permission and Delegation

1. Modeling Security Requirements Through Ownership, Permission and Delegation P. Giorgini F.Massacci J. Mylopoulos N. Zannone www.troposproject.org

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

3. 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.

4. Modelling 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

5. 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

6. 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?

7. 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

8. 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!

9. Some Ideas… we don’t like • Idea 1 • Add primitives/constraints to Tropos/Kaos/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 a IS requirement… • Idea 2 • Model security requirements separately from functional requirements • This is exactly the problem everybody is ranting about • Idea 3 • Model the goals of the attacker • They are not the goals of the security engineer!

10. Some ideas… we like • Hunch 1 • Security Requirements are social requirements • 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

11. 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 • Users claimed it essential…

12. 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 tell Alice what to do (i.e. to implement Alice)… Alice is an outsourced data process… • Delegation does NOT mean trust

13. 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…)

14. 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 PA 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

15. 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

16. 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)

17. 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.

18. Underlying Formal Model • Formal Model • Answer Set Programming (aka Datalog¬) • Deduction, Satisfiability, Abduction • Axioms • Intensional properties and rules • Models (secure-i* Diagrams) • Extensional properties of classes (and instances) • Properties • Formulae that may be in true or may not be true • eg Need-to-know (or need-to-do): all actors which have been delegated a permission to fulfill a goal has also been delegated the execution of the goal (directly or indirectly)

19. How do you use them? • Security Services as Patterns… • Authorization: there is a delegation of permission chain from owner to final user and provider, • Availability: there is delegation of execution chain to a trusted (for execution) service provider, etc. • Computer Aided Requirements Engineering • Diagrams (automatically) mapped into a Formal Model • Draw the Graphical Model • Check the properties on the Formal Model

20. CASE Tool Support • Case Study on Privacy Protection in the Enterprise • CEO’s goal of compliance with legal requirments and a number of refinements (eg delegation to CIO of drafting privacy policy legal documents) • Demos • Create actor’s model of goals • Shows various format (XML, Formal Tropos, ASP) • Show basic reasoning mechanisms • STool Demo • Short (4minutes) sttool-4min.swf • Medium (6minutes) sttool-6min.swf • Long (7.5minutes) sttool-7,30min.swf

21. Never Without a Screen Dump…

22. Monitoring Conflicts • If you don’t trust somebody just monitor its work to check for error • The HR Dept. Hand-made solution … • Trust of Execution is • I do it myself • I delegate the work to the trusted Alice • I delegate the work to untrusted Bob I don’t trust and I delegate to trusted Sam to monitor that Bob would do the job. • Monitoring is just a pattern… • Can thus be identified automatically.

23. Ongoing and Future Work • More Sophisticated Reasoning • Privacy Concepts • Build formal theory + reasoning services • Relations with other formalisms (eg HippoDB) • Completing the Development Process • Expand the model beyond early requirements • Ongoing Case Studies • Compliance with Privacy Legislation or ISO-17799 • Plus one little, little, little, little,problem…

24. The story is over, life is back… • WHO dares printing an official requirements document where • The HR Staff of the Public Administration declare that the develop & testing people of the Local Integrator are distrusted to provide any good testing in spite of 160K€/year corrective maintenance contract on top of a 100K€ ERP hosting contract, • The vice CIO of the Local Integrator does not trust the Leading International Consulting Company to have provided the correct data model after a year of consultancies running at a just-for-doing-you-a-favour rate of 1K€/person-day + taxes? • Trust information is very useful, but how to “officially” use it? • without being stranded to misery by once-friendly company lawyers and union collective actions…? • Research challenge for the next millennium…