Roles and Security

1
Roles and Security

• The Tropos Approach
• MOSTRO Meeting 29/03/2004
• Paolo Giorgini paolo.giorgini_at_dit.unitn.it
• Luiz Olavo Bonino bonino_at_dit.unitn.it

2
Security and Software Engineering

• Traditional SE approaches treat security as a
  non-functional requirement
• The usual approach includes security within a
  system identifying the security requirements
  after system design
• Security mechanisms have to be fitted into a
  pre-existing design
• Security still remains an afterthought

3
Security and Requirements Engineering

• Proposals for Security RE can be classified into
  two main streams
• Use an off-the-shelve framework and security
  requirements are modelled in such a framework
• UML, KAOS, i/Tropos etc.
• The features of the framework are used to
  formally analyze security requirements or guide
  the implementation
• Take a RE framework and enhances it with novel
  constructs specific to security.
• Formal analysis techniques and implementation
  guidelines need to be revised and/or extended to
  accommodate the new concepts

4
Security and Requirements Engineering

• Most proposals focus on
• protection aspects of security and explicitly
  deal with a series of security services
  (integrity, availability, etc.)
• and related protection mechanisms (passwords,
  crypto etc)
• Our goal is to introduce security requirements
  analysis in the early phases of the software
  development
• This will allow us to
• elicit security requirements from the
  organizational environment
• analyze security requirements within the
  organizational environment in which the software
  system will operate
• motivate the use of specific security mechanisms

5
Social x Individual

• In Tropos models involves two different levels of
  analysis social (roles and positions) and
  individual (agents)
• Social level the structure of organizations are
  defined associating to every role (or position)
  objectives and responsibilities
• Individual level agents are not only defined
  with their objectives and responsibilities, but
  also they are associated to roles (or positions)
  they can play.

6
Tropos concepts

• Actor
• Intentional entity role, position, agent (human
  or software)
• Goal (softgoal)
• Strategic interest of an actor
• Task
• Particular course of action that can be executed
  in order to satisfy a goal
• Resource
• Physical or informational entity (without
  intentionality)
• Social dependency (between two actors)
• One actor depends on another to accomplish a
  goal, execute a task, or deliver a resource

7
Tropos metamodel
8
Actors

• Intentional actors entities to which intentional
  dependencies can be ascribed
• Agent (personal) An actor with concrete,
  physical manifestation
• Position (organizational) Intermediate in
  abstraction between a role and an agent. A set of
  roles typically played by one agent. An agent
  occupies a position and a position covers a role.
• Role (attribute) Abstract characterization of
  the behavior of a social actor within some
  specialized context or domain of endeavor

9
Agent, Position and Role
10
Dependencies ? Actors

• Role or Position Dependencies are associated
  with a role/position when these dependencies
  apply regardless of who plays/covers the
  role/position
• Agent An agent has dependencies that apply
  regardless of what roles the agent is playing or
  the position the agent is covered by..

11
Tropos dependencies

• Goal dependency
• Task dependency
• Resource dependency

12
Tropos and Security

• Tropos has not been designed with security in
  mind
• It has been shown (Liu et al. 2003) how Tropos
  can be used to model privacy, but also (Giorgini
  et al. 2003) the lack of ability to capture at
  the same time functional and security features of
  an organization.
• A structured process integrating security and
  system engineering has been proposed (Mouratidis
  et al. 2003)

13
Secure Tropos

• The concept of service used to refer to a goal,
  task, or resource
• We introduce three new relationships
• Trust ,among two actors and a service
• Delegation, among two actors and a service
• Ownership, between an actor and a service
• And we refine the methodology by
• Define functional dependencies of services among
  actors
• Design a trust model among actors
• Identify who owns services and who is able to
  fulfill them

14
Secure Tropos concepts

• Ownership owns a service (goal, task or
  resource)
• Trust ???
• Delegation passage of authorithy
• Provisioning provides access to a service

15
Refining dependency

• Delegation of permission permission to fulfill
  the service
• Delegation of execution obligation to have the
  service fulfilled
• Trust of permission truster trusts that trustee
  uses correctly the service
• Trust of execution truster trusts that trustee
  is able to fulfill the service

16
Example Case Study

• A health care IS, in which
• Patient, that depends on the hospital for
  receiving appropriate health care. Further,
  patients will refuse to share their data if they
  do not trust the system or do not have sufficient
  control over the use of their data
• Hospital, that provides medical treatment and
  depends on the patients for having their personal
  information.
• Clinician, physician of the hospital that
  provides medical health advice and, whenever
  needed, provide accurate medical treatment
• Health Care Authority (HCA) that control and
  guarantee the fair resources allocation and a
  good quality of the delivered services.
• Medical Information System (MIS), that, according
  the current privacy legislation, can share the
  patients medical data if and only if consent is
  obtained.

17
Functional Requirements Model
18
Trust Requirements Model
19
Trust Management Implementation
20
Formalization (1)

• Predicates for the functional requirements model
• provides(a,s)
• requests(a,s)
• Depends(a,b,s)
• fulfills(a,s)
• satisfy(a,s)
• Predicates for the trust requirements model
• owns(a,s)
• trust(a,b,s,n) with n trust depth
• entrust(a,b,s,n) with n trust depth
• Predicates for the trust management
  implementation
• delegate(idC,a,b,s,n) idC certificate identify
• n delegation depth
• entitled(a,s,n)

21
Formalization (2)

• A way to see depth is the number of
  re-delegation depth 1 means that no
  re-delegation is allowed, depth N that N-1
  further step are allowed

22
Axioms

• Using Datalog

23
Properties

• A??B means one must check that each time that A
  holds it is desirable that also B holds.

24
Refining Delegation

• 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 (lets start working)

25
Refining Trust

• There could be situations where some actors must
  delegate permission or execution to other actors
  they do not trust
• at-most trust when the truster trusts that the
  trustee at most fulfills the goal but will not
  overstep it.
• at-least trust when the truster trusts that the
  trustee at least fulfills the goal

26
At-most and at-least
27
Monitoring

• Sometime work needs to be delegated even when
  there is no trust
• Monitoring can offer a surrogate for trust
• The goal of an actor playing the role of monitor
  is to check for the violation of trust
• The act of monitoring can be done by the
  delagater himself, or he can delegate it to some
  other actor to get it done
• Two different kind of monitoring
• at-most monitor and at-least monitor

28
At-most monitor
29
At-least monitor
30
Monitoring

• When the service to monitor is a goal/task, we
  need to extend the monitoring to all sublevels of
  delegation until the level where the actual
  execution takes place
• Monitoring is not a construct, but a security
  patterns that allows the designer to overcome the
  lack of trust
• Monitoring has to be treated as any other goal
• It can be further subject to refinement,
  delegation of execution and delegation of
  permission
• Trusts relationship linked to monitoring can then
  be captured with standard constructs

31
Predicates refinements
t ? exec,perm for delegate, delegateChain and
monitoring t ? exec,perm,mon for trust and
trustChain t ? satisfy,exec,owner for confident
32
Axioms for execution
33
Axioms for permission
34
Axioms with both perm and exec

• Need-to-know owners may want to know if their
  permission reached the actors who actually need
  it.
• These axioms allow for the identification of
  actors who actually need-to-have permissions

35
Properties