Modeling Security Requirements Through Ownership ...zannone/publication/slide/gior-mass... · A...
Transcript of Modeling Security Requirements Through Ownership ...zannone/publication/slide/gior-mass... · A...
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
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 stepsister– 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 IRITCNRS 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 eGoverment 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 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.
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 nonhuman 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
AgentOriented 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 agentoriented 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
runtime concept. For designtime, the interesting new concept agents have that objects don’t have is...
...goals!
Università degli Studi di Trento
i* Tropos Methodology• AgentOriented 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
requirem
ents
requirem
ents Late Late
requirem
ents
requirem
ents
Architec
tural
Architec
tural
design
design
DetailedDetailed
design
design
Implementation
Implementation
KAOSKAOSZZ
UML, Catalysis & Co.UML, Catalysis & Co.
AUMLAUML
TROPOSTROPOSGAIAGAIA
Nothing here!!
ii**
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 upandcoming 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.
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
Schedulemeeting
Productivemeetings
Schedulemeeting
Low costscheduling
Good meeting
Università degli Studi di Trento
Goal Analysis
Schedulemeeting
By all means By
-
- +
++
+
-
-
Collecttimetables
By person
Bysystem
Have updatedtimetables
Collectthem
Chooseschedule
Manually
Automatically
MatchingeffortCollection
effort
Minimalconflicts
Degree ofparticipation
Quality ofscheduleMinimal
effort
Università degli Studi di Trento
Actor Dependency ModelsInitiatorContributeToMtg
AttendMtg
UsefulMtg
CalendarInfo
SuitableTime
SchedulerParticipant
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 interdependencies.
• During late requirements, the systemtobe 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
SchedulerParticipant
ScheduleMtgSystem
Timetablemanager
Reporter
ManageCalendarInfo
MtgInfo
ContributeToMtg Initiator
Università degli Studi di Trento
Software Architectures with i*
CalendarInfo
Timetablemanager
Reporter
CollectCalendarInfo
RetrieveMtgInfo
UpdateMtgInfo
Processquery
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 on 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
requirem
ents
requirem
ents Late Late
requirem
ents
requirem
ents
Architec
tural
Architec
tural
design
design
DetailedDetailed
design
design
Implementation
Implementation
KAOSKAOSZZ
UML, Catalysis & Co.UML, Catalysis & Co.
AUMLAUML
TROPOSTROPOSGAIAGAIA
Nothing here!!
ii**
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 needtoknow 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 overall goals!
Università degli Studi di Trento
Some (Unscholarly) Discarded Ideas…• Discarded idea 1
– Add primitives/constraints to Tropos/Kaos/UML/nameyourpetREformalism 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, ModelDriven Architecture [Basin et al.]– UMLsec [Juriens]– AbuseCases [McDermott & Fox]– Misuse Cases [Sindre & Opdhal]
• Early Requirements Proposals– Antirequirements [van Lamsweerde et al., Crook et al.], – ProblemFrames, 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
– Wellknown even if metalevel 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 objectlevel (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• Metalevel 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• Objectlevel 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 partof 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 vicedirector of HR Department in charge of the system, and C vicedirector 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 Reassessed• 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 noncooperative information system!
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
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
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]– SecurityAware Tropos notions of ownership and
trust [Giorgini et al.]
Università degli Studi di Trento
SecureTropos Informal Model• Addons
– 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 atmost fulfill a goal (permission)– I trust you to atleast fulfill a goal (execution)
Università degli Studi di Trento
Permission vs Execution• atmost 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)”• atleast 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) – Needtodo (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 aTIFF (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 (securei* Diagrams)– Extensional properties of classes (and instances)
• Properties– Formulae that may be in true or may not be true– eg Needtoknow (or needtodo): 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• Semiformal 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 partof of P.A.• Individual (Dis)Trust
– A director of IT Department trusted correct implementation• So ordered old system to be turned down
– B vicedirector of HR Department in charge of the system, and C vicedirector 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 nottrust– 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 levelDistrust 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 instanceof T & B instanceof Q
distrust(A,B, Goal) <= distrust(T, Q, Goal) & A instanceof T & B instanceof Q
• Default Transitive Completion of Relationstrusttr(X, Y, G) <= trust(X, Y, G) & not distrusttr(X, Y, G)trusttr(X, Z, G) <= trusttr(X, Y, G) & trusttr(Y, Z, G) &
not distrusttr(X, Z, G)distrusttr(X, Y, G) <= distrust(X, Y, G)distrusttr(X, Z, G) <= trusttr(X, Y, G) & not distrusttr(X, Y, G)
& distrust(Y, Z, G)
Università degli Studi di Trento
Checking Conflicts• Direct Conflicts
<= trusttr(X, Y, G) & distrusttr(X, Y, G)• Indirect Conflict where both default rules
hinder each other<= trusttr(A, B, G) & distrusttr(T, Q, G) &
A instanceof T & B instanceof Q<= distrusttr(A, B, G) & trusttr(T, Q, G) &
A instanceof T & B instancof 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. Handmade 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…
Università degli Studi di Trento
Monitoring Conflicts• If you don’t trust somebody just monitor its work
to check for error– The HR Dept. Handmade 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
needtoknow– 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 of 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, ISO17799
• Plus one little, little, little, little, problem…
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 justfordoingyouafavour rate of 1K€/personday + taxes?
• Trust information is very useful, but how to “officially” use it?– without being stranded to misery by oncefriendly company
lawyers and union collective actions…?• Research challenge for the next millennium…