Modeling Security Requirements Through Ownership, Permission and - - PowerPoint PPT Presentation

Università degli Studi di Trento

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

Università degli Studi di Trento

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

Università degli Studi di Trento

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)

Università degli Studi di Trento

Act 1 – The Landscape Out There

How a Large Enterprise Project Looks Like

Università degli Studi di Trento

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

Università degli Studi di Trento

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

Università degli Studi di Trento

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

Università degli Studi di Trento

Act 2 – The Father

What You Always Wanted to Know About AOSE and Didn’t Care to Ask...

Università degli Studi di Trento

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)

Università degli Studi di Trento

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-
• riented software which supports requirements

analysis, as well as design.

Università degli Studi di Trento

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

• 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!

Università degli Studi di Trento

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

Università degli Studi di Trento

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.

Università degli Studi di Trento

Tropos vs The World

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

Università degli Studi di Trento

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,

• r are delegated to external agents.

Università degli Studi di Trento

Act 3 – A Honest Day’s Work

How the i*/Tropos Methodology for Requirements and Software Engineering works

Università degli Studi di Trento

Early Requirements: External Actors and their Goals

A social setting consists of actors, each having goals (and/or softgoals) to be fulfilled.

Participant Manager

Schedule meeting Productive meetings Schedule meeting Low cost scheduling Good meeting

Università degli Studi di Trento

Goal Analysis

Schedule meeting By all means By email

• +

+ + +

• Collect

timetables By person By system Have updated timetables Collect them Choose schedule Manually Automatically Matching effort Collection effort Minimal conflicts Degree of participation Quality of schedule Minimal effort

Università degli Studi di Trento

Actor Dependency Models

Initiator

ContributeToMtg AttendMtg UsefulMtg CalendarInfo SuitableTime

Scheduler Participant

ScheduleMtg

Actor dependencies are intentional: One actor wants something, another is willing and potentially able to deliver.

Università degli Studi di Trento

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.

Università degli Studi di Trento

Late Requirements with i*

AttendMtg UsefulMtg CalendarInfo SuitableTime

Scheduler Participant

ScheduleMtg

System Timetable manager Reporter

Manage CalendarInfo MtgInfo ContributeToMtg

Initiator

Università degli Studi di Trento

Software Architectures with i*

CalendarInfo

Timetable manager Reporter

Collect CalendarInfo Retrieve MtgInfo Update MtgInfo Process query

Updater Retriever InfoGatherer System Participant

Università degli Studi di Trento

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

• n

their commitments.

Università degli Studi di Trento

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

Università degli Studi di Trento

Tropos vs The World

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

Università degli Studi di Trento

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?

Università degli Studi di Trento

Act 4 – The Tale of Two Brothers

Software vs Security Engineering, a critical review

Università degli Studi di Trento

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

Università degli Studi di Trento

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

• verall goals!

Università degli Studi di Trento

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!

Università degli Studi di Trento

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,]

Università degli Studi di Trento

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

Università degli Studi di Trento

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…

Università degli Studi di Trento

Act 5 – Shadows at Dusk

A critical review explaining why certain Users Requirements do not look to make sense (but only at Face Value)

Università degli Studi di Trento

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…

Università degli Studi di Trento

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

Università degli Studi di Trento

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

Università degli Studi di Trento

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

Università degli Studi di Trento

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

Università degli Studi di Trento

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!

Università degli Studi di Trento

Act 6 – Enter Our Hero

A Quick Introduction to Secure Tropos

Università degli Studi di Trento

Some (Unscholarly) Good Ideas…

• Hunch 1

– Security Requirements are social requirements – We need to start from a RE methodology modelling

• rganizations

– 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

Università degli Studi di Trento

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

Università degli Studi di Trento

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

Università degli Studi di Trento

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)

Università degli Studi di Trento

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.

Università degli Studi di Trento

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

Università degli Studi di Trento

Act 7 – Entering into the Battlefield

How the Secure Tropos Constructs can be integrated and used in the software development process

Università degli Studi di Trento

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)

Università degli Studi di Trento

Never Without a Screen Dump…

QuickTime™ and a TIFF (LZW) decompressor are needed to see this picture.

Università degli Studi di Trento

Secure Tropos for Security Services

• 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

Università degli Studi di Trento

Formal Model behind CASE Tool

• 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)

Università degli Studi di Trento

SecureTropos – Formal Reasoning

• Semi-formal Analysis

– Annotate diagrams with formulae

• Partial checks at type level
• Eliminate already many errors in the chains
• Formal Analysis

– Full model at instance level

• Define instances of agents and goals
• instantiate delegation in many ways

– Finite State Model checking and (to be done) infinite state analysis – Allows Discovery of subtler relationships between parties

• Patient trusts “her” clinician, and hospital

– Analys relationships with third parties

• Delegation of permissions can create unexpected breach of trust
• “natural & simple” permission chain may not match “natural” trust chain

Università degli Studi di Trento

Act 8 – Dr Trust and Mr. Mistrust

How to cope with conflicts in Secure Tropos

Università degli Studi di Trento

Social vs Individual Trust

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

• Individual (Dis)Trust

– 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…)

Università degli Studi di Trento

Social => Individual?

• Social Trust => Individual Trust

– The agents playing a social role “should” inherit the trust relationships of that role – If Alice play R1 and R1 trusts R1 and Bob plays R2 then Alice trusts Bob…

• Useful feature to “complete” models in

Computer Aided RE

– Social trust relationships are always drawn in RE

• After all they are among THE system specifications

– Designers must only draw social trust relationship and the system does the rest BUT…

Università degli Studi di Trento

Solution: Distrust as a primitive

• Bad solution 1: distrust as absence of trust

– Don’t work at all with automatic completion (which solve the problem for 9.998 employees)

• Bad solution 2: distrust as not-trust

– One conflict makes the whole system inconsistent even if the remaining 9.998 employees are all fine.

• Good solution: Keep ‘em separate

– Model Trust and Distrust as independent primitive – Check whether there is a both a distrust/trust relations among two instances of actors in the model drawn by the designer

Università degli Studi di Trento

Sample Conflicts

Trust at social level Distrust at individual level (user not up to the role) Distrust at social level (eg procedures imposing restriction on roles) Trust at individual level

Università degli Studi di Trento

Modelling Trust & Distrust

• Default Completion of Social Relations

trust(A,B, Goal) <= trust(T, Q, Goal) & A instance-of T & B instance-of Q distrust(A,B, Goal) <= distrust(T, Q, Goal) & A instance-of T & B instance-of Q

• Default Transitive Completion of Relations

trust-tr(X, Y, G) <= trust(X, Y, G) & not distrust-tr(X, Y, G) trust-tr(X, Z, G) <= trust-tr(X, Y, G) & trust-tr(Y, Z, G) & not distrust-tr(X, Z, G) distrust-tr(X, Y, G) <= distrust(X, Y, G) distrust-tr(X, Z, G) <= trust-tr(X, Y, G) & not distrust-tr(X, Y, G) & distrust(Y, Z, G)

Università degli Studi di Trento

Checking Conflicts

• Direct Conflicts

<= trust-tr(X, Y, G) & distrust-tr(X, Y, G)

• Indirect Conflict where both default rules

hinder each other

<= trust-tr(A, B, G) & distrust-tr(T, Q, G) & A instance-of T & B instance-of Q <= distrust-tr(A, B, G) & trust-tr(T, Q, G) & A instance-of T & B instanc-of Q

• Sometimes solving conflicts not enough

Università degli Studi di Trento

Monitoring Conflicts

• If you don’t trust somebody just monitor is

work to check for error

– The HR Dept. Hand-made solution …

• Let the system find parts to be monitored!

– Modify rule for trust and distrust so that they only fire if not monitored – Add rules for identify monitoring so that constraints

• n conflicts are not violated

– The solver does the rest!

• The HR Dept. solution … automated…

Università degli Studi di Trento

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.

Università degli Studi di Trento

All’s well that ends well!

• Agent trust and distrust among agents

formally represented in the model

– The excel procedure is a conflict of social trust vs individual distrust.

• Once identified can be removed or

monitored

– HR department solution no longer a violation of need-to-know – Actually more monitoring is called for by other distrust relations (eg checkout of conceptual model).

Università degli Studi di Trento

Act 9 - The Step Sister

How do you capture privacy in the framework?

Università degli Studi di Trento

Privacy != Security

• Privacy is the right of individuals to

determine for themselves when, how, and to what extent information about them is communicated to others.

– Alan Westin - Professor of Law at Columbia Univ.

• Contentious Corollary 3 and 4

– We cannot use Software Engineering Methodologies, they have different goals (we cannot use Security Methodologies either) – Engineering doesn’t mix with civil liberties…

Università degli Studi di Trento

Real life…

• Delegation of permissions can never be as fine

grained as you would need them

– Cleaning lady has the key to open the room – She can empty the wastebin or steal papers from the desk.

• Real life contracts or data submissions have

purpose tagged to permissions

– Special power of attorney for contracts – Privacy statement according US, EU or national Legislation – You got this (permission, data, thing) to do that (action)

• If you breach trust (use for other purposes) then

you can be sued, fined, etc. etc.

Università degli Studi di Trento

Privacy is Linking Permission to Purpose

• Fact of Life

– We want something done – We give private information (or access to it) to get it done

• If private information is used for given purpose

– Happy user

• If private information is used for other purposes

– Consent must be sought (eg according Law) – Unhappy or unwilling users

• Just map that into the Secure Tropos framework

– Permission on Goals is there – Purpose is just Delegation of Execution!

Università degli Studi di Trento

Act 10 – Looking into the future

A magnificent progressing future

• f research challenges

Università degli Studi di Trento

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, ISO-17799

• Plus one little, little, little, little, problem…

Università degli Studi di Trento

Epilogue – Brave New World

THE Challenge

Università degli Studi di Trento

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 cumulative person/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…