università degli studi di trento modeling security requirements through ownership, permission and...

Università degli Studi di Trento

Modeling Security Requirements Through Ownership, Permission and

Delegation

A comedy in 10 acts plus an epiloguestarring F.Massacci

Also starring P. Giorgini J. Mylopoulos N. Zannone

www.troposproject.org


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


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)


Act 1 – The Landscape Out There

How a Large Enterprise Project Looks Like


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


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.


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


Act 2 – The Father

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

Care to Ask...


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)


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.


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!


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


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.


Tropos vs The World

Early

Early

require

ments

require

ments Late

Late

require

ments

require

ments

Archite

ctural

Archite

ctural

design

design

Detaile

d

Detaile

d

design

design

Implem

entatio

n

Implem

entatio

n

KAOSKAOSZZ

UML, Catalysis & Co.UML, Catalysis & Co.

AUMLAUML

TROPOSTROPOS

GAIAGAIA

Nothing here!!

ii**

JACK


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.


Act 3 – A Honest Day’s Work

How the i*/Tropos Methodology for Requirements and Software

Engineering works


Early Requirements:External Actors and their Goals

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

Participant Manager

Schedulemeeting

Productivemeetings

Schedulemeeting

Low costscheduling

Good meeting


Goal Analysis

Schedulemeeting

By all means By

email

-

- +

++

+

-

-

Collecttimetables

By person

Bysystem

Have updatedtimetables

Collectthem

Chooseschedule

Manually

Automatically

MatchingeffortCollection

effort

Minimalconflicts

Degree ofparticipation

Quality ofscheduleMinimal

effort


Actor Dependency Models

InitiatorContributeToMtg

AttendMtg

UsefulMtg

CalendarInfo

SuitableTime

SchedulerParticipant

ScheduleMtg

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


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.


Late Requirements with i*

AttendMtg

UsefulMtg

CalendarInfo

SuitableTime

SchedulerParticipant

ScheduleMtgSystem

Timetablemanager

Reporter

ManageCalendarInfo

MtgInfo

ContributeToMtg Initiator


Software Architectures with i*

CalendarInfo

Timetablemanager

Reporter

CollectCalendarInfo

RetrieveMtgInfo

UpdateMtgInfo

Processquery

Updater

Retriever

InfoGatherer

System

Participant


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.


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


Tropos vs The World

Early

Early

require

ments

require

ments Late

Late

require

ments

require

ments

Archite

ctural

Archite

ctural

design

design

Detaile

d

Detaile

d

design

design

Implem

entatio

n

Implem

entatio

n

KAOSKAOSZZ

UML, Catalysis & Co.UML, Catalysis & Co.

AUMLAUML

TROPOSTROPOS

GAIAGAIA

Nothing here!!

ii**

JACK


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?


Act 4 – The Tale of Two Brothers

Software vs Security Engineering, a critical review


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


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!


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!


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


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


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…


Act 5 – Shadows at Dusk

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


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…


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


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


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


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


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!


Act 6 – Enter Our Hero

A Quick Introduction to Secure Tropos


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


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


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


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)


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.


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


Act 7 – Entering into the Battlefield

How the Secure Tropos Constructs can be integrated and used in the

software development process


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)


Never Without a Screen Dump…

QuickTime™ and aTIFF (LZW) decompressor

are needed to see this picture.


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


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)


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


Act 8 – Dr Trust and Mr. Mistrust

How to cope with conflicts in Secure Tropos


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


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…


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


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


Modelling Trust & Distrust

• Default Completion of Social Relationstrust(A,B, Goal) <= trust(T, Q, Goal) &

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

A instance-of T & B instance-of Q

• Default Transitive Completion of Relationstrust-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)


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


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

on conflicts are not violated– The solver does the rest!

• The HR Dept. solution … automated…


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.


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


Act 9 - The Step Sister

How do you capture privacy in the framework?


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…


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.


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!


Act 10 – Looking into the future

A magnificent progressing future of research challenges


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…


Epilogue – Brave New World

THE Challenge


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…

università degli studi di trento modeling security requirements through ownership, permission and...

Documents