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 n n n 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) Target Manager (Subject) Subject Page 3 /HP-Labs Bristol Mar. 2003 © E. Lupu, M. Sloman, 2003
Example Policies n n n 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 n Need to specify and modify policies without coding into automated agents n Policies are persistent n But can be dynamically modified Change system behaviour without modifying implementation – not new functionality n Page 5 /HP-Labs Bristol Mar. 2003 © E. Lupu, M. Sloman, 2003
Ponder Policy Framework n n Domains Primitive policies u Authorisation u Obligation u Filters u Delegation n n Composite Policies Object orientation Page 6 /HP-Labs Bristol Mar. 2003 © E. Lupu, M. Sloman, 2003
Ponder Policy Based Solutions n n 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 n People Page 8 /HP-Labs Bristol Mar. 2003 Hardware © E. Lupu, M. Sloman, 2003 Components Software Components
Domains Hierarchy n Sub-domains & overlapping domains A D B E C B A Page 9 /HP-Labs Bristol Mar. 2003 © E. Lupu, M. Sloman, 2003 C D E
Domains and Policies Policy Managers Manager Agents Managed Objects Impractical to specify policy for individual objects in large systems with many objects specify policy for domains n Can change domain membership without changing policy n 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 n n Ponder declarative notation for specifying policy Primitive policies u u 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 n n 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 n n 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 n Clear specification of responsibility, rights and duties “job description” © E. Lupu, M. Sloman, 2003
Authorisation Policy n Defines what a subject is permitted or not permitted (prohibited) to do to a target u n 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 n 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 video. Channel; action setup; when time. between (start, end); } inst kids. Video = video (/family/kids, “ 1400”, “ 1900”); adult. Video = video (/family/adults, “ 2000”, “ 2400”); Page 16 /HP-Labs Bristol Mar. 2003 © E. Lupu, M. Sloman, 2003
Filters n Transformations on parameters of positive authorisation policies, where it is not practical to provide different operations to reflect permitted parameters inst auth+ employee. Access { subject employees + managers ; target <DB> employee. DB ; action get. Emp (emp. ID) ; if (subject = employees) result = reject (result, salary, home. Addr); } Page 17 /HP-Labs Bristol Mar. 2003 © E. Lupu, M. Sloman, 2003
Negative Authorisation n Used for revocation of access rights inst auth- revoke { subject /users/Joe. Bloggs; target /resources/database ; action - ; // any action when time. date > 30: 9: 2002 } n 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 n Default Negative Everything forbidden unless explicitly authorised inst auth- gateway { subject s=sys. Admin; target gateways; action load, enable, disable ; when (s. location Computer. Room) ; } auth+ gateway { subject s=sys. Admin; target gateways ; action load, enable, disable ; when (s. location = Computer. Room) ; } n Default Positive Anything permitted unless explicitly forbidden Page 19 /HP-Labs Bristol Mar. 2003 © E. Lupu, M. Sloman, 2003
Obligation Policy n n n 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 n 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) ; <switch. T> 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 n refrain polite. Behaviour { subject Agroup ; target AGroup. NY + DGroup. Boston ; 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 n Specify which actions a subject can delegate to a grantee u Must be a subset of subjects, actions and targets in an authorisation policy auth+ eg del ble ena Page 23 /HP-Labs Bristol Mar. 2003 reset, enable, disable + auth le nab e © E. Lupu, M. Sloman, 2003
Delegation Example inst auth+ service. Man { subject br. Manager; target br. Services ; action reset. Schedule, enable, disable; } inst deleg+ s. Deleg (service. Man) { subject; br. Manager; grantee br. Engineer ; action reset. Schedule ; } Note: deleg- forbids delegation Page 24 /HP-Labs Bristol Mar. 2003 © E. Lupu, M. Sloman, 2003
Composite Policies n n n 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 n Defines a syntactic scope for specifying a set of related policies to be instantiated at the same time + constraints on the policies type group service. Fail (set <manager> m, set <service> s) { constraint c = time. between(“ 0800”, ” 1800”); inst auth+ schedule. Reset { subject m ; target s; action reset. Schedule; when c; } oblig fail. Reset { subject m; target s; on failure do reset. Schedule; when c; } } Page 26 /HP-Labs Bristol Mar. 2003 © E. Lupu, M. Sloman, 2003
User Representation Domain Adapter URD n n n auth+ 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 n E. g. , network operator, network manager, finance director, ward-nurse n Specify policy in terms of roles rather than persons do not have to re-specify policies when person assigned to new role n Page 28 /HP-Labs Bristol Mar. 2003 © E. Lupu, M. Sloman, 2003
Manager Roles Target Managed Objects Adapter Agent auth+ connect auth User Representation Domain Role Policies Position Domain 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 n Different persons assigned to roles n Different target components n Similar policies Role Type n Reuse of role specification n Page 31 /HP-Labs Bristol Mar. 2003 © E. Lupu, M. Sloman, 2003 London Site policies Paris Site policies
Role Specialisation Derive new composite policy specifications from existing ones n Specialise roles by adding policies Inheritance type n role router. Op (…) extends op(…), { … } Operator Router Operator Policy Page 32 /HP-Labs Bristol Mar. 2003 © E. Lupu, M. Sloman, 2003 type role net. Admin. T(…) extends op(…), { … } Network Administrator
Example Specialised Role type role router. Op (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 London. Op = router. OP (london. Network); Paris. Op = router. Op (paris. Network); Page 33 /HP-Labs Bristol Mar. 2003 © E. Lupu, M. Sloman, 2003
Component Roles n Group policies related to a particular type of network component e. g. edge or core router n Use same hardware for both types of routers n 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 n Relationships Rights and duties of roles towards each other u Usage of shared resources u Interaction protocols edge router site core network type rel q. Supervision ( router. OP net. Op, q. Edge. Rtr q. Agent) { queue config. role (q. Edge. Rtr) inst oblig report { subject q. Agent ; on timer. at (1800); queue do report(q_info); target net. Op; } supervision auth+ config { subject net. Op ; router action set. Strategy; target q. Agent; } operator } Page 35 /HP-Labs Bristol Mar. 2003 © E. Lupu, M. Sloman, 2003 u
Management Structures 1 n Configurations of roles and relationships in organisational units site network edge router traffic queue config. role (q. Edge. Rtr) 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 traffic. T (domain site) { import /type/q. Edg. Rtr, /type/router. Op; /type/q. Supervision domain rtr = site/routers; inst role net. OP = router. Op (rtr); q. Agent = q. Edg. Rtr (rtr); rel qs = q. Supervision (net. OP, q. Agent); mstruct qos { inst role adm. Control {…}; tr. Shaping {…}; rel select. Traffic{…}; } ; rel config. Admission { inst auth+ { subject net. Op; target qos. adm. Control; action update ( ) } } Page 37 /HP-Labs Bristol Mar. 2003 © E. Lupu, M. Sloman, 2003
Organisational Patterns edge router core network core London network tr 2 edge router tr 1 Paris network inst mstruct london/tr 1 = traffic. T(london) paris/tr 2 = traffic. T(paris) Page 38 /HP-Labs Bristol Mar. 2003 © E. Lupu, M. Sloman, 2003
Ponder Summary Object Meta Model Class Hierarchy Page 39 /HP-Labs Bristol Mar. 2003 © E. Lupu, M. Sloman, 2003
Conflicts n n 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 n n An object can be a member of multiple domains (overlap) Multiple policies can apply to single domain Security Policy Performance Policy test. B, query test. A, test. B, query, stop, start n Need conflict detection and resolution Page 41 /HP-Labs Bristol Mar. 2003 © E. Lupu, M. Sloman, 2003
Modality Conflicts Actions +ve -ve n n 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 auth- Project Workstations inst auth- boot. WS { subject students; target workstations; action reboot ; } Exception: inst auth+ project. WS { 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. : u u u Negative policies override Does not permit positive exceptions to negative policies. Specified Priorities t Hard to define priority t Several managers may specify inconsistent priority Evaluating a ‘distance’ between a policy and the object to which it refers t Refinement level – more concrete overrides? t 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 n n auth- Project 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 P 2 overrides P 1 for the areas in which they overlap P 1 No Precedence between P 1 or P 2 can be determined P 1 P 2 P 2 P 1 P 1 P 2 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 P 1 P 2 positive policies Page 48 /HP-Labs Bristol Mar. 2003 negative policies © E. Lupu, M. Sloman, 2003 message distinguishes: O+/refrain, O+/A-, A+/A-
Policy Analysis, Refinement and Validation Policy Analysis – policy analysis is insufficient u u u Consider constraints when detecting conflicts Identify which situations lead to conflict Reason with partial specifications Policy Refinement – derive policies from SLAs and business goals u u u 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 n n n 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) n Goals are progressively refined into operational policy specifications refinement hierarchy n Leaf policies mapped onto implementation mechanisms eg ACL or router interface n Similar to refining requirements and going from specification to implementation Cannot be fully automated Use requirements engineering techniques for elicitation of non-functional requirements n Page 51 /HP-Labs Bristol Mar. 2003 © E. Lupu, M. Sloman, 2003
Policy Refinement oblig videoconf { subject Net. Man; target users/group. A; do /* setup videoconf facilities *; / when time. between("14: 00", "15: 00") ; } oblig enable { on timer. at("13: 55“); subject Net. Man; do enable(); target pol/vid_reserve; } oblig disable { on timer. at("15: 00“); subject Net. Man; do disable(); target pol/vid_reserve; } auth+ polauth { subject Net. Man; action enable, disable; target pol/vid_reserve } oblig lower_reserve { on request(bw, chan. Id); subject edge. Router; do reduce. Reserved(bw); target chan/chan. Id; when bw < get. Reserved(chan. Id) ; } oblig increase_reserve { on request(bw, chan. Id) ; subject edge. Router; do increase. Reserve(min(bw, x)); target chan/chan. Id; Page 52 /HP-Labs Bristol Mar. 2003 © E. Lupu, M. Sloman, 2003 when bw > get. Reserved(chan. Id) ; }
Challenges Refinement does not preserve policy modality e. g. , an obligation may be refined to a set of obligation, refrain, authorisation and delegation policies n Refinement may introduce inconsistencies n The set of refined policies may not fully implement the goal they were refined from Preserve consistency Ensure Coverage n Page 53 /HP-Labs Bristol Mar. 2003 © E. Lupu, M. Sloman, 2003
Static Analysis Approach n Need both system behavioural model and policies. n Abduction applied to Event Calculus representation. 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 n Representation of policies in Event Calculus u u u n 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 u u u 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 n n 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 n n Types of conflict: u separation of duty e. g. , the same person is not allowed to authorise payments and initiate them u self-management e. g. , a manager cannot authorise it’s own expenses u 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 (P 1, P 2 | P 1. subjects->intersection(P 2. subjects)->not. Empty and P 1. actions->exists(a | a. name = ‘authorise’) and P 2. actions->exists(a | a. name = ‘initiate’) and P 1. targets->intersection(P 2. targets)->exists(t | t. is. Ocl. Kind. Of(payment))) Page 58 /HP-Labs Bristol Mar. 2003 © E. Lupu, M. Sloman, 2003
Implementation Issues n n n 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 n Basic policy is implemented as LDAP object u u u most primitive unit Source text = object attribute Can generate XML – store as another attribute Composite policy derived from domain object n Policy objects can be protected by authorisation policies Security Administrator role n 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 Policy service Authorisation Policies Domain service 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 Management. Agent Generic Interface Distribute, Remove, Enable, Disable obligation & refrain policies Load, Unload code Application Specific Interface Policies Operations on target objects Agent specific functions Programming 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 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 instantiate Dormant Deleted unload Loaded enable disable Enabled Page 66 /HP-Labs Bristol Mar. 2003 © E. Lupu, M. Sloman, 2003 Access Controllers (Authorisation Policies) Policy Management Agents (Obligation & Refrain Policies)
Loading an Authorisation Policy n 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 n 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, . . event. Handler oblig. Method 7 2 REOs check. Refrain OPO (Obligation Policy Object) RPO (Refrain Policy Object) 5 event. Engine 4 8 Access Controllers enable, disable Page 69 /HP-Labs Bristol Mar. 2003 register, . . . enable, disable 6 check. Refrains 3 ACs 9 OEO (Obligation Enforcement Object) REO (Refrain Enforcement Object) © E. Lupu, M. Sloman, 2003
Policy Refinement n n 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) n Goals are progressively refined into operational policy specifications refinement hierarchy n Leaf policies mapped onto implementation mechanisms eg ACL or router interface n Similar to refining requirements and going from specification to implementation Cannot be fully automated Use requirements engineering techniques for elicitation of non-functional requirements n Page 71 /HP-Labs Bristol Mar. 2003 © E. Lupu, M. Sloman, 2003
Policy Refinement oblig videoconf { subject Net. Man; target users/group. A; do /* setup videoconf facilities *; / when time. between("14: 00", "15: 00") ; } oblig enable { on timer. at("13: 55“); subject Net. Man; do enable(); target pol/vid_reserve; } oblig disable { on timer. at("15: 00“); subject Net. Man; do disable(); target pol/vid_reserve; } auth+ polauth { subject Net. Man; action enable, disable; target pol/vid_reserve } oblig lower_reserve { on request(bw, chan. Id); subject edge. Router; do reduce. Reserved(bw); target chan/chan. Id; when bw < get. Reserved(chan. Id) ; } oblig increase_reserve { on request(bw, chan. Id) ; subject edge. Router; do increase. Reserve(min(bw, x)); target chan/chan. Id; Page 72 /HP-Labs Bristol Mar. 2003 © E. Lupu, M. Sloman, 2003 when bw > get. Reserved(chan. Id) ; }
Challenges Refinement does not preserve policy modality e. g. , an obligation may be refined to a set of obligation, refrain, authorisation and delegation policies n Refinement may introduce inconsistencies n The set of refined policies may not fully implement the goal they were refined from Preserve consistency Ensure Coverage n Page 73 /HP-Labs Bristol Mar. 2003 © E. Lupu, M. Sloman, 2003
Case Study n n 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 SS 7 HLR Home Location Register Management Servers Operations & Maintenance Centre (OMC) Operations Network OMC-Radio MSC Mobile Switching Centre 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) BSC Base Station Controllers connection Help Desk BTS
Scenario Overview n n OA&M of GSM networks Problem characterised by: u u u n 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: u u 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 BTS BTS Network Element Administrator BSC Branches Regions © E. Lupu, M. Sloman, 2003 BTS Network Element Administrator BSC Page 77 /HP-Labs Bristol Mar. 2003 BTS
Organisational Roles n n n 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 (BNo. S) are responsible for managing the Mobile Switching service Centre (MSC) and Visitors Location Register (VLR) Base Network Operators – Radio (BNo. R) are responsible for Base Transceiver Systems (BTS) Network Element Administrators (NEA) perform all onsite management tasks requested by BNo. S and BNo. R Page 78 /HP-Labs Bristol Mar. 2003 © E. Lupu, M. Sloman, 2003
Management Structures – Branch NEA 1 HD 2 HD 1 NEA 2 TSE BNo. R Customer care Page 79 /HP-Labs Bristol Mar. 2003 © E. Lupu, M. Sloman, 2003 BNo. S 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/nea 1 = administrator (. . . ) ; a/nea 2 = administrator (. . . ) ; r/bnos = switch_op (nw/bsc/, nw/msc) ; r/bnor = radio_op (nw/bsc/) ; inst rel s/bnos_nea 1 = switch_repair (bnos, nea 1); s/bnos_nea 2 = switch_repair (bnos, nea 2); NEA 1 s/bnor_nea 1 = radio_repair (bnor, nea 1); NEA 2 s/bnor_nea 2 = radio_repair (bnor, nea 2); s/bnos_bnor = switch_base (bnos, bnor); } BNo. R BNo. S 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()->run. Self. Test(); } } role switch_op (set <bsc> bscd, msc m) specialisation 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 clear. Cell { target f = bscd^{id}; on cell. Overload(BTSid, id); do force. HO(BTSid); } On 3 consecutive radio failures, increase BTS transmission oblig increase. TX { target f = bscd^{id}; on 3*radio. Link. Fail(BTSid, id); do set. Tx. Power(+1); } … } Page 83 /HP-Labs Bristol Mar. 2003 © E. Lupu, M. Sloman, 2003
Authorisation Policies type group gen_auth (set s 1, set s 2, hlr h, eir e, vlr v) { constraint work. Hours = time. between(“ 0800”, “ 1800”); Common constraint definition inst auth+ pt 1 { subject s 1; target h; when work. Hours action add, trace. Subscriber, lock. Subscriber; } auth- pt 2 {subject s 1; target e; action black. List. Equipment; } auth+ pt 3 { subject s 2; target v; when work. Hours; action trace; check. Handover; check. Radio; } } Page 84 /HP-Labs Bristol Mar. 2003 © E. Lupu, M. Sloman, 2003
Scenario Summary n Scenario exemplifies: u u u n O-O style specifications are a real benefit. u n 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: u u u 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 n n n Ponder future work Conclusions References Page 86 /HP-Labs Bristol Mar. 2003 © E. Lupu, M. Sloman, 2003
Comparison With Vendor Products Page 87 /HP-Labs Bristol Mar. 2003 © E. Lupu, M. Sloman, 2003
Ponder Future Work n Policy based programmable networks u u u n n n 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 n Security specification Authorisation, filter, Refrain, delegation, role n Management Event-triggered Obligation, role n n Large scale Multiple Organisations Domains + Composite policies n Analysis Declarative language Page 89 /HP-Labs Bristol Mar. 2003 © E. Lupu, M. Sloman, 2003
Trust & Security Management n n What is Trust Classification Trust Specification Use of Trust Page 90 /HP-Labs Bristol Mar. 2003 © E. Lupu, M. Sloman, 2003
What is Trust n 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 l l 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 My. Machine trusts MSNMess to save files Trustor Trustee Tom trusts news. com Trustee 2. Provision of Service by Trustee eg enews deliveries, email, archive 3. Certification of trustee eg Veri. Sign 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) hotel. Group ( _hotel, Holiday. Inn) u Distrust when level < 0 Recommend Predicate recommend (recommendor, recomendee, actions, level) constraint set recommend (Morris, _attendee, verify. Credential, medium) ICstaff. Member (_attendee) trust (Harry, Game. Co, Download. Games, medium) recommend (Tom, Game. Co, Download. Games, high) Page 93 /HP-Labs Bristol Mar. 2003 © E. Lupu, M. Sloman, 2003
Trust, Experience and Risk n n n Trust is not static but changes with time as a result of experience/reputation Reputation = evaluation of experience Need for 3 rd 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 Trust. Value){ subject Client; target sub-directory; action download. Music(); when trust+(Front. End, Client. App, download. Music(Content. Database), Trust. Value ) }; inst auth+ Access. High = Access(/BMW/Content. Base, High. Trust); inst auth+ Access. Low = Access(/BMW/Content. Base/Restricted, Low. Trust); 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
Скачать презентацию Policy Based Network Management Events Monitor Events Manager
4d76f9b63d8ed80ec60976407a4758e4.ppt