Transcript Slide 1

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
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 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 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
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
i
*
JACK
TROPOS
GAIA
KAOS
Z
AUML
Nothing here!!
UML, Catalysis & Co.
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,
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
Low cost
scheduling
fulfilled.
Manager
Participant
Schedule
meeting
Good
meeting
Productive Schedule
meeting
meetings
Università degli Studi di
Trento
Quality of
schedule
Minimal
effort
Collection
effort
Minimal
conflicts
Matching
effort
-
-
+
+
+
-
Schedule
meeting
+
-
Collect
timetables
Choose
schedule
By
person
By all
means
Degree of
participation
Goal
Analysis
By
system
Manually
Automatically
By
email
Have
updated
timetables
Collect
them
Università degli Studi di
Trento
Actor Dependency Models
ContributeToMtg
UsefulMtg
Initiator
ScheduleMtg
CalendarInfo
Scheduler
Participant
AttendMtg
SuitableTime
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 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*
ContributeToMtg
UsefulMtg
Initiator
ScheduleMtg
CalendarInfo
Participant
Scheduler
AttendMtg
System
Timetable
manager
Manage
CalendarInfo
MtgInfo
SuitableTime
Reporter
Università degli Studi di
Trento
Software Architectures with i*
System
Collect
CalendarInfo
Participant
CalendarInfo
Timetable
manager
Update
MtgInfo
InfoGatherer
Reporter
Retrieve
MtgInfo
Updater
Process
query Retriever
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
i
*
JACK
TROPOS
GAIA
KAOS
Z
AUML
Nothing here!!
UML, Catalysis & Co.
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
overall goals!
Università degli Studi di
Trento
Some (Unscholarly) Discarded Ideas…
• Discarded idea 1
– Add primitives/constraints to Tropos/Kaos/UML/name-your-pet-REformalism 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 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 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
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]
– 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 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 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
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. 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 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, 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 justfor-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…