Enforcing Security Policies Through Negotiation in Panoply

1
Enforcing Security Policies Through Negotiation
in Panoply
Peter Reiher, Leonard Kleinrock, V. Ramakrishna,
Kevin Eustice (UCLA http//lasr.cs.ucla.edu/pano
ply) NSF Grant CNS 0427748

• The Panoply Middleware
• Secure and scalable management of ubiquitous
  computing interactions and infrastructure

• Secure and Spontaneous Interoperation
• Drawbacks of previous ubicomp frameworks
• Inflexible, tied to a location, and dependent on
  custom hardware and software
• Must address general ubiquitous computing
  problems
• Heterogeneity of devices and networks
• Divergent knowledge and capability
• Different, possibly incompatible, security
  policies
• Solution a fusion of several concepts
• Decentralized interactions of self-managing
  groups spheres
• Policy management
• Ensures flexible runtime control of device and
  application behavior
• Dynamically maintains system constraints,
  including security and access requirements
• Decentralized policy resolution through automated
  negotiation, guided by local policies of each
  group

Panoply Architecture

• Spheres of Influence
• Automatically discovers and organizes devices
  into groups, or spheres, based on
• Social groups (e.g., organizations, friends,
  etc.)
• Physical location or proximity
• Task
• Network
• Manages
• Network connectivity
• Service discovery
• Location and social context

Connection to any related Spheres
Relation Manager
Sphere Interface
Doorman
Applications
Sphere Manager
Policy Manager
Sphere State Member Table Event Registry
Location Sphere

• Functions
• Secure group management discovery, formation and
  reconfiguration
• Scoping event interest and dissemination
• Group collaboration primitives

Messaging Interface (to other sphere components
remote computers)

• Policy Management
• Negotiation protocol a bi-directional sequence
  of messages consisting of requests,
  counter-requests, and offers, resulting in an
  agreement consistent with local policies
• Front end manages multiple simultaneous threads
  with negotiators
• Runs a protocol state machine per thread for
  sending and receiving of negotiation messages
• Listens for events that indicate system state
  changes and triggers database state modification
• Controller interprets negotiation messages based
  on type and content and frames appropriate
  responses
• Maintains queues of requests received and sent,
  and stores alternatives
• Computes counter-requests and offers (positive or
  negative)
• Uses pluggable helper functions to handle
  external objects
• Policy engine maintains a database of system
  state and policy rules
• Prolog-based policy language
• Logical querying mechanisms
• Allows addition and deletion of database entries

FRONT END
Protocol State Machine
Multi-Threading Message Switching
Event Listener
CONTROLLER
Negotiation Heuristics Metrics
Security Trust Model
Semantic Interpretation of Messages
POLICY ENGINE
Policy Database
Logical Knowledge Engineering Mechanisms
External Sphere Interactions and Membership

• Internal Event Mediation and Access Control
• Access to protected services is only possible
  through events
• Events are examined for compliance with policy
  before applications can act on them
• An attempt at access triggers negotiation if
  compliance cannot be proved

Formation of Sphere Relationship and Agreement
Personal Sphere P
I want to join you !
PM Checks Event for Compliance
Physical Sphere L

• First line of Defense QED
• Incoming device quarantined from the rest of the
  group
• Device examined for out-of-date software,
  vulnerable running services, and presence of
  malware
• Device decontaminated of vulnerabilities if found

Event reaches Sphere Manager (SM) from remote
sphere S
SM sends referral to Policy Manager (PM) for
policy compliance
Yes
Event passes to application
Negotiation Successful?
No
Negotiate with S
No
Yes

• Next step Negotiation
• Ls membership policy ltAnyone who possesses a
  valid voucher to join the group, and is willing
  to stop services on vulnerable ports, including
  port 25, may joingt
• Ps policies
• ltI will expose my group voucher only to those
  spheres who possess a valid UCLA or ACM vouchergt
• ltI am willing to shut off services on port 25 to
  be able to join Lgt
• L possesses both an ACM voucher and a UCLA
  voucher but currently has a policy of not making
  its UCLA membership public

Event dropped
L
P

• Example Smart Party
• Dynamic music playlists, dependent on guests
  collective preferences
• Spheres represent the party, individual rooms, as
  well as every guest
• A playlist can be modified through a control
  event
• Party sphere policy ltonly party host spheres are
  allowed to modify playlistsgt
• Scenario Control event CE arriving at party
  sphere triggers negotiation
• Two alternative negotiation scenarios to the right

Party Sphere
Member Sphere
1. REQUEST ltMembershipgt
2. REQUEST ltShow valid group vouchergt ltYou must
turn off services on port 25gt
1. REQUEST ltPass CEgt
2. REQUEST ltShow Host vouchergt
3. REQUEST ltUCLA vouchergt
4. OFFER ltDenied No UCLA vouchergt
5. REQUEST ltACM vouchergt
6. OFFER ltProof ACM vouchergt
3. OFFER ltHost Vouchergt
3. OFFER ltDenygt
7. OFFER ltProof group vouchergt ltI have
firewalled off port 25gt
4. OFFER ltCE passedgt
4. OFFER ltCE droppedgt
6. OFFER ltGroup membershipgt