Filling the gap between Requirements Engineering and Public KeyTrust Management Infrastructures

1
Filling the gap between Requirements Engineering
andPublic Key/Trust Management Infrastructures

• Paolo Giorgini
• Department of Information and Comm. Tech.
• University of Trento (Italy)
• Joint work with
• Fabio Massacci, John Mylopoulos, and Nicola
  Zannone

2
Summary

• Motivation
• Our approach
• Secure aware-Tropos
• Case study
• Formalization
• Axioms
• Proprerties
• Trust Management Implementation
• Conclusion and future work

3
Trust Management and PKIs

• Trust Management and PKIs are hot topics in
  security research
• sophisticated policy languages, algorithms, and
  system for managing security credentials
• Solutions based on public-key cryptography and
  credential have been shown to be well suited in
  satisfying the security requirements of
  distributed systems
• However, there is big gap between solutions and
  the requirements of the entire system

4
Security and Requirements

• No methodologies for linking security policy to
  the mainstream requirements analysis process
• The usual approach towards the inclusion of
  security within a system is to identify security
  requirements after system design
• Security mechanisms have to be fitted into a
  pre-existing design
• may not be able to accommodate them
• security requirements can generate conflicts
  functional requirements of the system

5
Our goal

• There are proposals improving on secure
  engineering or architectures for trust
  management, but nobody has proposed a methodology
  that considers together both these approaches
• We want to introduce a trust management system
  into the requirements engineering framework
• avoid designing an entire system and then
  retrofitting a PKI on its top, when it is already
  to late to make it fits snugly

6
Our proposal

• A process that integrates trust, security and
  system engineering, using the same concepts and
  notations used for requirements specification
• Three steps approach
• Functional Requirements modeling
• Trust Requirements modeling
• PKI/trust management implementation
• We use Tropos, an agent-oriented methodology, for
  requirements modeling and analysis

7
Tropos Methodology

• Tropos is an agent-oriented software development
  methodology, tailored to describe both the
  organization and the system itself
• Tropos uses concepts of
• 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

8
Security-Aware Tropos

• Tropos has not been designed with security in
  mind
• We introduce four new relationships
• Trust ,among two agents and a service
• Delegation, among two agents and a service
• Ownership, between an agent and a service
• Offer, between an agent 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

9
An illustrative 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.

10
The Functional Requirements Model
D Dependency A Aim S Service
11
The Trust Requirements Model
O Ownership T Trust
12
The Trust Management Implementation
2 forms of Delegation P Permission (deleg.
for use) G delegation for Grant
13
Formalization (1)

• Predicates for the functional requirements model
• offers(a,s)
• aims(a,s)
• has(a,s)
• depends(a,b,s1,s2)
• Predicates for the trust requirements model
• owns(a,s)
• trust(a,b,s1,s2,n) n trust depth
• Predicates for the trust management
  implementation
• fulfills(a,s)
• delGrant(idC,a,b,s1,s2,n) idC certificate
  identify
• n delegation depth
• permission(idC,a,b,s1,s2)

14
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

15
Axioms

• using Datalog

16
Properties

• We use the DLV system for automatic verification
  of security requirements

17
Negative Authorization (1)

• We use a closed world policy the lack of an
  authorization is interpreted as a negative
  authorization
• This approach has a major problem in the lack of
  a given authorization for a given actor does not
  prevent this user from receiving this
  authorization later on
• We propose an explicit negative authorization,
  namely an explicit denial for an actor to access
  a service
• Negative authorizations are stronger than
  positive authorizations
• Two predicates
• delDenial(idC,a,b,s,n)
• prohibition(idC,a,b,s)
• and analougsly for positive authorization
• delDChain(A,B,S)
• prohibitionChain(A,C,S)

18
Negative Authorization (2)

• Axioms
• Properties

19
Trust Management Implementation

• We use the RT framework (by Li et al.), which
  provides policy language, semantics, deduction
  engine, and pragmatic features
• RT includes a declarative, logic-based semantic
  foundation based on Datalog, support for
  vocabulary agreement, strongly-typed credential
  and policies, and flexible delegation structures
• In RT, an entity is a uniquely identified
  individual or process
• An entity can issue credentials and make requests
• RT uses the notion of role to represent
  attributes
• Entity.Role

20
Roles in the RT framework

• Only the entity A has the authority to A.R, and A
  does so by issuing role-definition credentials
• An entity A can define A.R to contain A.R1,
  another role defined by A
• A.R?A.R1, means that A defines that R1 dominates
  R
• A credential A.R?B.R is a delegation from A to B
  of authority over R. This can be used to
  decentralize the user-role assignment.
• A credential of the form A.R?B.R1 can be used to
  define role-mapping across multiple organizations
• The credential A.R?A.R1.R2 states that A.R
  contains any B.R2 if A.R1 contains B.

21
Moving to the RT framework

• permission(ID,A,B,S1,S2)
• A.S1?B.S2
• delGrant(ID,A,B,S1,S2,N)
• A.S1?B.r.S2
• where B allows to use the service S1 to actors
  in the role B.r

22
Example 1

• A patient allows his clinician to read his
  personal/medical data to provide accurate medical
  treatment.
• permission(id,Pat,Cli,Rec,MedTre)-
  isClinicianOf(Pat,Cli)owns(Pat,Rec)
• In RT
• Pat.recordAc(read,?FPat.record)?
  Pat.clinician.provide(?EmedTre)
• Given Pat.record?Rec and Pat.clinician?Cli, one
  can conclude that
• Pat.recordAc(read,Rec)?Cli.provide(?EmedTre)

23
Example 2

• The Medical Information System allows the
  clinician to write on his patient records to
  upgrade them.
• permission(id,MIS,Cli,Rec,upgrade(Rec))-
  isClinicianOf(Pat,Cli)owns(Pat,Rec)
• In RT
• MIS.recordAc(write,?FPat.record)?
  Pat.clinician.upgrade(?FPat.record)
• Given Pat.record?Rec and Pat.clinician?Cli, one
  can conclude that
• MIS.recordAc(write,Rec)?Cli.upgrade(Rec)

24
Conclusion and future work

• We have introduced a process that integrates
  security and requirements engineering
• A clear separation of trust and delegation
  relationship
• Our framework supports the automatic verification
  of security requirements
• We have defined the trust management
  implementation of our framework into the RT
  framework
• Future work
• incorporating explicitly roles adding time
  features
• integration with the Formal Tropos tool