Policy Based Network Management
Events
Monitor
Events
Manager
Agent
Managed
Objects
Control
actions
Decisions
Policies
New functionality
Programmable Networks
Page 1 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Policies
Security Specification






E-commerce, healthcare – multiple organisations
Complex security policies with many constraints and
exceptions
Common security policy specification which can map
onto heterogeneous implementation mechanisms for OS,
firewalls, databases …..
Need to specify security policy for groups and roles
(organisational positions)
Need to manage security – what actions
to perform when a violation detected?
Need for analysis tools
Page 2 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Policy Agents for Management
Authorisation
Policy
Obligation
Policy
Monitoring
Control
Managed Object
(Target)
Manager
(Subject)
Page 3 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Example Policies






Who is permitted to access a service, what operations they
can they perform, and when. E.g. Research staff can set
up video conferences between UK and USA only between
16:00 and 19:00, Monday to Wednesday.
What resources a mobile user can access when visiting a
remote location
What information transformations and UI adaptations
should take place when a user is mobile.
What actions should be performed when a login violation is
detected.
What diagnostic tests should be performed when an error
count is exceeded in a network component.
Allocate 10% of available bandwidth to voice over IP
Page 4 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Policy Definition
Rule governing choices in behaviour of the system
Derived from enterprise goals and service level
agreements
 Need to specify and modify policies without
coding into automated agents
 Policies are persistent
 But can be dynamically modified
 Change system behaviour without modifying
implementation – not new functionality

Page 5 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Ponder Policy Framework


Domains
Primitive policies
 Authorisation
 Obligation
 Filters
 Delegation


Composite Policies
Object orientation
Page 6 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Ponder Policy Based Solutions




Large scale
Multiple
Organisations
Domains/
directories
Triggering
migration
delegation etc.
Obligation
Policies
Authorisation
Policies
Security
Page 7 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Domains  Grouping
A domain is a collection of objects which have
been explicitly grouped together for management
purposes e.g. to apply a common policy
 (LDAP) directory

Hub
People
Page 8 /HP-Labs Bristol Mar. 2003
Hardware
© E. Lupu, M. Sloman,
2003
Components
Software
Components
Domains  Hierarchy

Sub-domains & overlapping domains
A
D
B
E
A
Page 9 /HP-Labs Bristol Mar. 2003
D
C
B
© E. Lupu, M. Sloman, 2003
C
E
Domains and Policies
Policy
Policy
Managers
Manager Agents
Managed Objects
Impractical to specify policy for individual objects
in large systems with many objects
 specify policy for domains
 Can change domain membership without
changing policy

Page 10 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Policy Propagation
Subjects
Page 11 /HP-Labs Bristol Mar. 2003
Targets
© E. Lupu, M. Sloman, 2003
Primitive Policies


Ponder declarative notation for specifying policy
Primitive policies




Authorisation
Obligation
Filters
Delegation
Page 12 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Policy
Rule governing choices in behaviour of the system




Need to specify and modify policies without
coding into automated agents
Policies are persistent
But can be dynamically modified
Many different types of policy  extensible
notation
Page 13 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Policy Notation


Precise specification of subjects, targets, actions
and constraints for authorisations and obligations
Needed for both:
Automated
agents
Human
managers
Page 14 /HP-Labs Bristol Mar. 2003

Clear specification of responsibility,
rights and duties  “job description”
© E. Lupu, M. Sloman, 2003
Authorisation Policy

Defines what a subject is permitted or
not permitted (prohibited) to do to a target


Permitted operations
Protect target objects from unauthorised
management actions
 Target based interpretation and enforcement
Page 15 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Authorisation Policies

All policies can be specified as a parameterised type from
which instances can be created
type auth+ video (subject s, string start, string end) {
target videoChannel;
action setup;
when time.between (start, end); }
inst kidsVideo = video (/family/kids, “1400”,“1900”);
adultVideo = video (/family/adults, “2000”, “2400”);
Page 16 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Filters

Transformations on parameters of positive authorisation
policies, where it is not practical to provide different
operations to reflect permitted parameters
inst auth+ employeeAccess {
subject
employees + managers ;
target
<DB> employeeDB ;
action
getEmp (empID) ;
if (subject = employees)
result = reject (result, salary, homeAddr); }
Page 17 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Negative Authorisation

Used for revocation of access rights
inst auth- revoke {
subject/users/JoeBloggs;
target
/resources/database ;
action
- ; // any action
when
time.date > 30:9:2002 }

Reflect organisational policies and laws
inst auth- nostrangle {
subject
projectmanagers;
action
strangle;
target
trainees; }
Page 18 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Default Authorisation

Default Negative
Everything forbidden unless explicitly authorised
inst auth- gateway {
subject s=sysAdmin; target gateways;
action load, enable, disable ;
when (s.location  ComputerRoom) ; }
auth+ gateway {
subject s=sysAdmin; target gateways ;
action load, enable, disable ;
when (s.location = ComputerRoom) ; }

Default Positive
Anything permitted unless explicitly forbidden
Page 19 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Obligation Policy





Defines what actions a subject must do
Subject based  subject interprets policy and
performs actions on targets
Event triggered obligation
Actions can be remote invocations or local scripts
Can specify sequencing or concurrency of
actions
Page 20 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Obligation Example

On a TX circuit failure, replace the circuit with a backup,
and, in parallel, reconfigure the transceiver with logging
the failure
type oblig
on
target
do
fail_reconfigure (subject s, set b) {
failure (cir, trans, switch) ;
<switchT> f = b ^ {switch} ;
f.disable(trans, cir) -> {f.enable(trans, “backup”)
|| s.log (cir, trans, switch); }
}
inst p = fail_reconfigure (.../roles/netops/,
…/network/switches) ;
Page 21 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Refrain Policy
inst

refrain politeBehaviour {
subject Agroup ;
target
AGroupNY + DGroupBoston ;
action
videoconf ;
when
(time.day=Friday); }
Similar to negative authorisation but subject
based interpretation
Page 22 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Delegation Policy

Specify which actions a subject can delegate to a
grantee

Must be a subset of subjects, actions and targets in an
authorisation policy
auth+
reset, enable,
disable
Page 23 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Delegation Example
inst auth+ serviceMan {
subject brManager; target brServices ;
action resetSchedule, enable, disable; }
inst deleg+ sDeleg (serviceMan) {
subject; brManager; grantee brEngineer ;
action resetSchedule ; }
Note: deleg- forbids delegation
Page 24 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Composite Policies





Group Policies
Manager position roles
and component roles
Role relationships
Management structures
Object orientation
Page 25 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Group Policies

Defines a syntactic scope for specifying a set of related
policies to be instantiated at the same time + constraints
on the policies
type group serviceFail (set <manager> m, set <service> s) {
constraint c = time.between(“0800”,”1800”);
inst auth+ scheduleReset {
subject m ; target s;
action resetSchedule; when c;}
oblig failReset {
subject m; target s;
on failure do resetSchedule; when c;}
}
Page 26 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
User Representation Domain
Adapter
URD



auth+
Personal
Resources
Persistent representation of a registered user
URD is subject of policies applying to a specific
person
At login adapter object created to represent and
act on behalf of person in system
 command interpreter
Page 27 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Roles
Role groups the rights and duties related to a
position in an organisation
 E.g., network operator, network manager,
finance director, ward-nurse
 Specify policy in terms of roles rather than
persons
 do not have to re-specify policies when person
assigned to new role

Page 28 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Manager Roles
Target Managed
Objects
Adapter
Agent
auth+ connect
User
Representation
Domain
Role
Policies
Position
Domain
Role
Role
Page 29 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Role Example
type role op (set t) {
// restarts failed equipment in target domain t
inst oblig restart { target f = t ^ {id};
on failure (id);
do f.restart () -> f.run_self_test() ;}
// other authorisation and obligation policies
…
}
Page 30 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Role Instances
Multiple operator role
instances
 Different persons
assigned to roles
 Different target
components
 Similar policies
 Role Type
 Reuse of role
specification

Page 31 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
London Site
Site policies
Paris Site
Site policies
Role Specialisation
Derive new composite policy specifications from
existing ones
 Specialise roles by adding policies
 Inheritance
type

role routerOp (…)
extends op(…), { …
}
Operator
Router Operator
Policy
Page 32 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
type
role netAdminT(…)
extends op(…), { …
}
Network
Administrator
Example Specialised Role
type role routerOp (set <routers_type> r)
extends op (r) {
// On link failure the link must be reset.
inst oblig reset { target t = r ^ {router} ;
on
link_failure (x, router)
do
t.reset (x) ; }
// other policies
}
inst
LondonOp = routerOP (londonNetwork);
ParisOp = routerOp (parisNetwork);
Page 33 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Component Roles

Group policies related to a particular type of
network component e.g. edge or core router

Use same hardware for both types of routers

Role defines policies applying to (i.e. loaded)
onto router hardware which is assigned to a role
Page 34 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Role Relationships

Relationships
Rights and duties of roles towards each other
 Usage of shared resources
 Interaction protocols
edge router
site
core
network
network
type rel qSupervision (
routerOP netOp, qEdgeRtr qAgent) {
queue config.
role (qEdgeRtr)
inst oblig report { subject qAgent ;
on timer.at (1800);
queue
do report(q_info); target netOp; }
supervision
auth+ config { subject netOp ;
router
action setStrategy; target qAgent; }
operator
}Page 35 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003

Management Structures 1

Configurations of roles and relationships in
organisational units
site network
edge router
traffic
queue config.
role (qEdgeRtr)
qos
config
traffic
shaping
Page 36 /HP-Labs Bristol Mar. 2003
admission
control
© E. Lupu, M. Sloman, 2003
queue
supervision
router
operator
Management Structures 2
type mstruct trafficT (domain site) {
import /type/qEdgRtr, /type/routerOp; /type/qSupervision
domain rtr = site/routers;
inst role netOP = routerOp (rtr); qAgent = qEdgRtr (rtr);
rel
qs = qSupervision (netOP, qAgent);
mstruct qos {
inst role
admControl {…}; trShaping {…};
rel
selectTraffic{…}; } ;
rel configAdmission {
inst auth+ { subject netOp; target qos.admControl;
action update ( ) }
}
Page 37 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Organisational Patterns
edge router
core network
London
network
tr2
edge
router
tr1
Paris
network
inst mstruct
london/tr1 = trafficT(london)
paris/tr2 = trafficT(paris)
Page 38 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Ponder Summary
Object Meta Model
Class Hierarchy
Object
BasicPolicy
auth
oblig
auth+
auth-
Page 39 /HP-Labs Bristol Mar. 2003
CompositePolicy
MetaPol
refrain
group
deleg
deleg+
© E. Lupu, M. Sloman, 2003
deleg-
role
rel
mstruct
Conflicts




Modality conflict detection and resolution
Policy priority
Semantic conflicts and meta-policies
Policy analysis tools
Page 40 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Multiple Policies May Apply


An object can be a member of multiple domains
(overlap)
Multiple policies can apply to single domain
Security Policy
Performance
Policy
testB, query

Need conflict detection and resolution
Page 41 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Modality Conflicts
Actions
+ve
-ve




Potential conflict from overlap of
subjects, targets and actions
3 types: auth+/auth-, oblig/auth-,
oblig/refrain
Note: auth+/refrain is not a conflict
Detected by syntactic analysis
Page 42 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Example Conflicts
auth+
Smith
reboot
Students
Project
auth-
Workstations
inst auth- bootWS {
subject students; target workstations; action reboot ; }
Exception:
inst auth+ projectWS {
subject smith; target workstations/project; action reboot ; }
Page 43 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Precedence
Can resolve some conflicts automatically by
specifying precedence. e.g.:



Negative policies override
Does not permit positive exceptions to negative policies.
Specified Priorities
 Hard to define priority
 Several managers may specify inconsistent priority
Evaluating a ‘distance’ between a policy and the object
to which it refers
 Refinement level – more concrete overrides?
 Time of last update – more recent overrides?
Page 44 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Domain Nesting Precedence
auth+
Smith
reboot
Students




Project
auth-
Workstations
A particular type of distance based on domain
nesting
Priority given to the policy which is more specific
for either subjects or targets
Intuitive, flexible, allows incremental specifications
and exceptions
Not always valid
Page 45 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Determined & Undetermined Cases
P2 overrides P1 for the areas in which
they overlap
P1
No Precedence between P1 or P2 can be
determined
P1
P2
P2
P1
P1
P2
P2
P1
P1
P2
P2
Page 46 /HP-Labs Bristol Mar. 2003
and symmetric ...
© E. Lupu, M. Sloman, 2003
Precedence between policies
Page 47 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
The Conflict Detection Tool
P1
P2
positive policies
negative policies
message
distinguishes:
O+/refrain, O+/A-, A+/APage 48 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Policy Analysis, Refinement and
Validation
Policy Analysis – policy analysis is insufficient



Consider constraints when detecting conflicts
Identify which situations lead to conflict
Reason with partial specifications
Policy Refinement – derive policies from SLAs and
business goals



Not automatable but can apply refinement patterns
Maintain consistency during refinement
Ensure completeness – refined policies fully implement
more abstract ones
Policy Validation – Can a policy be implemented?
Page 49 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Policy Refinement



Goal refinement
Policy Refinement
Relationship to Requirements
Engineering
Page 50 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Policy Refinement
Policies are derived from business and organisational
goals or service level agreements (SLA)
 Goals are progressively refined into operational policy
specifications  refinement hierarchy
 Leaf policies mapped onto implementation mechanisms
eg ACL or router interface
 Similar to refining requirements and going from
specification to implementation
 Cannot be fully automated
 Use requirements engineering techniques for elicitation of
non-functional requirements

Page 51 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Policy Refinement
oblig videoconf {
subject NetMan; target users/groupA; do /* setup videoconf facilities *;/
when time.between("14:00", "15:00") ; }
oblig enable { on timer.at("13:55“);
subject NetMan; do enable(); target pol/vid_reserve; }
oblig disable { on timer.at("15:00“);
subject NetMan; do disable(); target pol/vid_reserve; }
auth+ polauth { subject NetMan; action enable, disable;
target pol/vid_reserve }
oblig lower_reserve {
on request(bw, chanId);
subject edgeRouter; do reduceReserved(bw); target chan/chanId;
when bw < getReserved(chanId) ;}
oblig increase_reserve { on request(bw, chanId) ;
subject edgeRouter; do increaseReserve(min(bw,x)); target chan/chanId;
Page 52 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
when bw > getReserved(chanId)
;}
Challenges
Refinement does not preserve policy modality
e.g., an obligation may be refined to a set of
obligation, refrain, authorisation and delegation
policies
 Refinement may introduce inconsistencies
 The set of refined policies may not fully
implement the goal they were refined from
Preserve consistency
Ensure Coverage

Page 53 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Static Analysis Approach
Need both system behavioural model and policies.
 Abduction applied to Event Calculus representation.

A
C
B
Conflict specification
Behavioural model
of managed objects
Conflicts
Ponder Policies
Page 54 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Translation to Event Calculus
Analysis & Refinement: Current Status

Representation of policies in Event Calculus




A. Bandara, E. Lupu, A.Russo. Using Event Calculus
to Formalise Policy Specification and Analysis. Policy
2003, (see last slide).
Currently 2 point timeline -> Generalisation.
Stratification -> Decidable. Computable in polynomial
time.
Future Work



Generalisation to infinite discrete timeline.
Identify and express requirements patterns.
Use goal regression to elaborate plans of actions and
identify alternatives for refinement.
Page 55 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Constraints


Only potential modality conflicts are detected as
constraints may limit the applicability of a policy e.g., to a
particular time interval
Typed Constraints:
Inst auth+lineop { subject s = operators ;
actions enable, disable, reset, off ;
target Sregion ;
when time.between(0800,1800) and
s.state = ‘active’}
inst auth- lineop {subject s= operators
actions enable, disable, reset, off}
target Sregion
when time.between(1600,2400) and
s.state = ‘standby’ }
Page 56 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
time
subject
state
Semantic Conflicts




Types of conflict:
 separation of duty e.g., the same person is not allowed
to authorise payments and initiate them
 self-management e.g., a manager cannot authorise it’s
own expenses
 conflict for resources e.g., not more than 5 persons are
authorised to change the DB
Need to specify the conditions which result in conflict
Constraints on a set of policies (Meta-Policies).
Specified using Prolog, OCL
Included in composite policies such as roles or mstructs
Page 57 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Separation of Duties
/policies/accounting->exists (P1, P2 |
P1.subjects->intersection(P2.subjects)->notEmpty and
P1.actions->exists(a | a.name = ‘authorise’) and
P2.actions->exists(a | a.name = ‘initiate’) and
P1.targets->intersection(P2.targets)->exists(t |
t.isOclKindOf(payment)))
Page 58 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Implementation Issues






Policies as objects
Implementation architecture
Obligation policy agent
Authorisation policy agent
Policy deployment
Ponder compiler output
Page 59 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Protecting Policies

Basic policy is implemented as LDAP object



most primitive unit
Source text = object attribute
Can generate XML – store as another attribute
Composite policy derived from domain object
 Policy objects can be protected by authorisation
policies
Security Administrator role

auth+
Edit, enable,
disable, remove
Policy service
Page 60 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Policy Implementation
Edit, enable
disable ...
Query
subjects
& targets
Domain service
Policy service
Authorisation
Policies
Obligation
& Refrain
Policies
Actions
Target
Objects
Events
Page 61 /HP-Labs Bristol Mar. 2003
Policy Management
Agents (Subjects)
Events
Monitoring
service
© E. Lupu, M. Sloman, 2003
Query targets
Policy ManagementAgent
Generic Interface
Distribute,
Remove,
Enable,
Disable
obligation
& refrain
policies
Application Specific
Interface
Policies
Operations
on target
objects
Agent specific functions
Programming
Load,
Unload
code
Events
Execution Environment
Page 62 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Authorisation Agent
Policies
Load,
Remove,
Enable,
Disable,
policies
Map onto
operating system
or object-support
access control
mechanisms
Authentication
Page 63 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
The Life of a Policy
Policy
Spec.
write
Policy
Class
compile
instantiate
Dormant
Page 64 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Policy
Object
instantiate
The Life of a Policy (load)
Policy
Object
load
Enforcement
Objects
load
instantiate
Dormant
load
Loaded
Page 65 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Enforcement
Agents
The Life of a Policy (enable, disable, …)
Policy
Object
enable
Enforcement
Agents
enable
Access
Controllers
(Authorisation
Policies)
instantiate
Dormant
Deleted
unload
load
Loaded
enable
disable
Enabled
Page 66 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Policy
Management
Agents
(Obligation &
Refrain Policies)
Loading an Authorisation Policy

Enforcement Objects  Enforcement Agents
Policy Object
Enforcement Agents (EA)
Target Set
1 EA for each Target Object Host
1 EO per EA per Host
Page 67 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Loading an Obligation/Refrain Policy

Each Subject Object is an Enforcement Agent!
Policy Object
Subject Set
Page 68 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Enforcement Agents
Enforcement (Obligation/Refrain)
Policy Management Agent
Event Service
OEOs
OPOs
RPOs
1
2
load, enable,..
3
6
checkRefrains
register, ...
enable,disable
5
eventEngine
eventHandler
obligMethod
4
8
7
2
REOs
Access Controllers
enable,disable
ACs
checkRefrain
OPO (Obligation Policy Object)
RPO (Refrain Policy Object)
Page 69 /HP-Labs Bristol Mar. 2003
9
OEO (Obligation Enforcement Object)
REO (Refrain Enforcement Object)
© E. Lupu, M. Sloman, 2003
Policy Refinement




Goal refinement
Relationship to Requirements
Engineering
Analysis
Refinement tools
Page 70 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Policy Refinement
Policies are derived from business and organisational
goals or service level agreements (SLA)
 Goals are progressively refined into operational policy
specifications  refinement hierarchy
 Leaf policies mapped onto implementation mechanisms
eg ACL or router interface
 Similar to refining requirements and going from
specification to implementation
 Cannot be fully automated
 Use requirements engineering techniques for elicitation of
non-functional requirements

Page 71 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Policy Refinement
oblig videoconf {
subject NetMan; target users/groupA; do /* setup videoconf facilities *;/
when time.between("14:00", "15:00") ; }
oblig enable { on timer.at("13:55“);
subject NetMan; do enable(); target pol/vid_reserve; }
oblig disable { on timer.at("15:00“);
subject NetMan; do disable(); target pol/vid_reserve; }
auth+ polauth { subject NetMan; action enable, disable;
target pol/vid_reserve }
oblig lower_reserve {
on request(bw, chanId);
subject edgeRouter; do reduceReserved(bw); target chan/chanId;
when bw < getReserved(chanId) ;}
oblig increase_reserve { on request(bw, chanId) ;
subject edgeRouter; do increaseReserve(min(bw,x)); target chan/chanId;
Page 72 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
when bw > getReserved(chanId)
;}
Challenges
Refinement does not preserve policy modality
e.g., an obligation may be refined to a set of
obligation, refrain, authorisation and delegation
policies
 Refinement may introduce inconsistencies
 The set of refined policies may not fully
implement the goal they were refined from
Preserve consistency
Ensure Coverage

Page 73 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Case Study




Scenario overview
Management Structures
Roles
Policies
Page 74 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
GSM Networks
Visitor
Location
Register
Gateway
MSC
EIR
VLR
Equipment
Identity
Register
SS7
HLR
Home
Location
Register
Management Servers
Operations &
Maintenance
Centre (OMC)
Operations
Network
OMC-Radio
MSC
BSC
Base
Station
Controllers
control
Page 75 /HP-Labs Bristol Mar. 2003
BSC
BTS
BSC
© E. Lupu, M. Sloman, 2003
Help Desk
Network
Element
Administrator
Base
Transceiver
Stations
(BTS)
Mobile Switching
Centre
connection
Help Desk
BTS
Scenario Overview


OA&M of GSM networks
Problem characterised by:




large scale
large number of policies
multiple instances of roles which often work in teams
e.g., network administrators, switch administrators,
help-desk staff
Need to define:


geographical repartition and organisational structure
the roles and the rights and duties corresponding to
the those roles
Page 76 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
National Network
Help Desk
MSC
Help Desk
BTS
BTS
BTS
MSC
BTS
BTS
Network
Element
Administrator
BTS
Network
Element
Administrator
BSC BSC
Visitor
Location
Register
VLR
EIR
BSC BSC
SS7
Branches
HLR
Regions
Page 77 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Organisational Roles





Help-Desk staff (HD) provide the interface between
customers and the company (not elaborated in this
scenario).
Telephone Service Engineers (TSE) investigate faults
occurring between mobile stations and base transceiver
stations, and determine whether a base network operator
should be alerted to deal with the fault.
Base Network Operators – Switches (BNoS) are
responsible for managing the Mobile Switching service
Centre (MSC) and Visitors Location Register (VLR)
Base Network Operators – Radio (BNoR) are
responsible for Base Transceiver Systems (BTS)
Network Element Administrators (NEA) perform all onsite management tasks requested by BNoS and BNoR
Page 78 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Management Structures – Branch
Branch
NEA1
HD2
HD1
NEA2
TSE
BNoR
Customer care
Page 79 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
BNoS
Net. Elt. Managment
Branch Management Structure
mstruct branch(domain d, domain nw) {
import custcare; netelements;
inst
mstruct cc = custcare (d, nw);
mstruct ne = netelements (d, nw);
d – branch location
nw – network elts.
domain
instantiate substructures
type rel radiofail (role eng, role radio_op) { … }
// procedures for radio failures investigation
inst rel f = radiofail(cc.tse, ne.bnor);
}
create relationships
(type if not imported)
domain c = …/wales/branches/cardiff;
create instance of structure
inst cardiff = branch (c, c/nw);
Page 80 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Netelements management structure
type mstruct netelements (domain br, domain nw) {
import
administrator; switch_op; radio_op;
switch_repair; radio_repair; switch_base;
domain
r = br/roles/; a = r/nea/; s = br/rel/;
inst role a/nea1 = administrator ( ... ) ;
a/nea2 = administrator ( ... ) ;
r/bnos = switch_op (nw/bsc/, nw/msc) ;
r/bnor = radio_op (nw/bsc/) ;
inst rel
s/bnos_nea1 = switch_repair (bnos, nea1);
s/bnos_nea2 = switch_repair (bnos, nea2);
NEA1
s/bnor_nea1 = radio_repair (bnor, nea1);
NEA2
s/bnor_nea2 = radio_repair (bnor, nea2);
s/bnos_bnor = switch_base (bnos, bnor); }
BNoR
BNoS
Page 81 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Base and Switch Operators
Base rights and duties for all operators
type
role base_op (set n) {
inst oblig restart { target f = n^{id};
on failure(id); do restart()->runSelfTest(); } }
specialisation
role switch_op (set <bsc> bscd, msc m)
extends base_op (bscd) {
inst
oblig reset {
target f = bscd^{id};
on A_failure(cir, id); do block(cir); reset(cir); }
auth+ circuit { action block,reset; target bscd;}
} // switch_op
Page 82 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Radio Operator
radio operators responsible for base transceiver systems
type
role radio_op (set <bsc> bscd) extends base_op(bscd) {
inst
On cell overload, force a hand-over of connected mobiles
oblig clearCell { target f = bscd^{id};
on cellOverload(BTSid, id); do forceHO(BTSid);}
On 3 consecutive radio failures, increase BTS transmission
oblig increaseTX { target f = bscd^{id};
on 3*radioLinkFail(BTSid,id); do setTxPower(+1);}
…
}
Page 83 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Authorisation Policies
type group gen_auth (set s1, set s2,
hlr h, eir e, vlr v) {
constraint workHours = time.between(“0800”, “1800”);
Common constraint definition
inst
auth+ pt1 { subject s1; target h; when workHours
action add, traceSubscriber, lockSubscriber; }
auth- pt2 {subject s1; target e; action blackListEquipment; }
auth+ pt3 { subject s2; target v; when workHours;
action trace; checkHandover; checkRadio;} }
Page 84 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Scenario Summary

Scenario exemplifies:




O-O style specifications are a real benefit.


large number of managed objects
large numbers of distributed manager (agents)
reasonable number of policy and role types
However, it requires regular and well planned domain
structures.
Ponder approach provides an easy means for:



creating and using new policy types
structuring policies and management teams
instantiating and deploying large number of policies
Page 85 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Future Directions



Ponder future work
Conclusions
References
Page 86 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Comparison With Vendor Products
MS
Management
Security
Ponder
M
S
Tivoli
M
S
Computer
HP
Cisco
Orche-
Assoc.
Products
Assure
stream
M
M
M
S
M
S
S
S
Active
Allot
M
S
Access
Directory Packeteer
M
S
M
S
360
M
S
RSA
SolSoft
Systor
M
M
S
S
Securities
M
S
Service Level Agreement / Trust specification
SLA/Trust to policy refinement
Privacy management
OSS or workflow integration
Mobile and Ubiquitous systems
WAP
Inter domain policy negotiation
?
Policy Analysis
Automated deployment
Adaptive management
?
Roles
Provisioning
Single sign on
Web/DB access
Monitoring
control
Event Correlation
Intrusion Detection
?
Application
Management
Windows AC
QoS
Unix AC
Element Management
Firewall/ router AC
Future
Page 87 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Ponder Future Work

Policy based programmable networks








Policy aware applications
Policy based network elements – routers and firewalls
Direct implementation of policy in hardware (FPGAs)
Inter-organisational policy negotiation
Policy based response to network attacks
Refinement and analysis tools
Trust specification, analysis and refinement into
security management policy
Case studies and implementation
Page 88 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Conclusions
Security
specification
Authorisation, filter,
Refrain,delegation, role

Management
Event-triggered
Obligation, role


Large scale
Multiple
Organisations
Domains +
Composite
policies

Analysis
Declarative language

Page 89 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Trust & Security Management




What is Trust
Trust Classification
Trust Specification
Use of Trust
Page 90 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
What is Trust

A quantified belief by a trustor with respect to the
competence, honesty, security and dependability of a
trustee within a specified context
Trustor
Context: Hotel Services
Trustee
Trust relationship


Distrust useful for trust revocation or in default trusted
environments
Quantification implies various degrees of trust/distrust
Page 91 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Trust Classification
1. Access to Trustor Resources
eg MSN Messenger
MyMachine trusts MSNMess to save files
Trustor
Trustor
Trustee
Tom trusts news.com
Trustee
2. Provision of Service by Trustee eg enews deliveries, email, archive
3. Certification of trustee eg VeriSign or Brit. Medical Assoc.
4. Delegation of trust eg use
certification authority for trust
decisions
Trustor
Trustee
May delegates all decisions concerning
verification to her bank
5. Infrastructure trust eg, network, storage
Page 92 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Trust Specification
Trust Predicate
trust (trustor, trustee, actions, level, )  constraint set
trust (Helen, _hotel, print; processing, 50) 
hotelGroup ( _hotel, HolidayInn)

Distrust when level < 0
Recommend Predicate
recommend (recommendor, recomendee, actions, level) 
constraint set
recommend (Morris, _attendee, verifyCredential, medium) 
ICstaffMember (_attendee)
trust (Harry, GameCo, DownloadGames, medium) 
recommend (Tom, GameCo, DownloadGames, high)
Page 93 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Trust, Experience and Risk





Trust is not static but changes with time as a
result of experience/reputation
Reputation = evaluation of experience
Need for 3rd party recommendations c.f. PGP
Trust is related to risk and value
High risk  low trust
But high risk, low value may be medium trust
Trust framework must monitor experience,
risk and constraints in order to dynamically
update trust levels and relationships.
Page 94 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Trust-based Authorisation Policy
type auth+ Access ( domain sub-directory, string TrustValue){
subject Client;
target sub-directory;
action downloadMusic();
when trust+(FrontEnd, ClientApp, downloadMusic(ContentDatabase),
TrustValue ) };
inst auth+ AccessHigh = Access(/BMW/ContentBase, HighTrust);
inst auth+ AccessLow = Access(/BMW/ContentBase/Restricted, LowTrust);
Page 95 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Trust Refinement & Adaptive Security
Low Trust
Medium Trust
Monitoring and
reacting to unusual
behaviour
Authorisations Delegation
Page 96 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Communities of Devices
Trust based
relationships
External
services
Page 97 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Policy-driven Architecture
Trust
Specification
Context
Adaptation
policies
Trust
Evaluation
events
Adaptation


Access
Control
change
Authorisations
Page 98 /HP-Labs Bristol Mar. 2003
© E. Lupu, M. Sloman, 2003
Filtering
Selected
information
Privacy