Anupam Joshi and Tim Finin Ebiquity UMBC

 Constraining Information Flow in Social Networks using Policies and Context  Probing Policy secured systems to recover policy  SOA based Infrastructure  Securing Clouds with Policy 2

3

 Increase in the user generated content on web  Rise in the online interactions and content sharing among users  More dynamic context  Need to provide precise control over the conditions under which users can share their personal information 4

 Availability of GPS functionality on phone devices like iPhone, HTC-G1 and network based positioning methods on internet  Social network maps friends and their locations using Maps API on the web  Content sharing relative to dynamic context (location and time)  Privacy is an important issue with the current systems like Google latitude, Loopt, Brightkite 5

6

Static knowledge about user profile, and networks of friends Knowledge about dynamic user context like current activity, location Privacy enforcement rules Reasoning Engine Network Privacy Control Framework Content Preferences Content Aggregator Social Media Policy network ontology Database 7

 Policy network ontology  Integrates Rein and AIR policy ontology  Rein policies to provide access control and AIR policies to provide justification to the inferences made  Policies specified using N3 rules and Turtle  Reasoning engine  CWM, a forward chaining rule engine ▪ Pychinko, a forward chaining rule engine, written in Python, that implements Rete algorithm and allows for efficient processing of very large rule bases  Supports a significant subset of the math, string, time and logic built-ins 8

9 Policy(N3) Resource (User-location) Meta-Policy Policy Language (loc-access) Policy Language (loc-access) policy language meta-policy Request Requester Credentials Location-Access Answer Valid InValid access requester ans IsA Policy Network Ontology Request Ontology

Privacy Policy follows Deny-Access approach. It specifies authorization logic -- Authentication is separate  What information user is willing to share  With whom  Friends  Group of friends  Under what conditions  Day and time of the week  Location of the user, specifying the area in which user can be seen  Accuracy level of the (location) information 10

Example policies can be :  Share my location with teachers on weekdays only if I am in the university campus and only between 9 am and 6 pm  Share exact location with members of family group all the time, in all locations  Do not share my location if I am at any of the sensitive locations  Do not share my activity status with teachers on weekends  Share my activity status with only close friends 11

Example of location access control policy: Share my location with teachers on weekdays only if I am in the university campus and only between 9 am and 6 pm 12

Example of location access control policy: Share exact location with members of family group all the time, in all locations 13

14 Example of location access control policy: Do not share my location if user is at any of the sensitive locations

15 Example of activity access control policy: Do not share my activity status with teachers on weekends

16 Example of activity access control policy: Do not share my location if user is at any of the sensitive locations

17 Example of Accountability Policy: Checks the compliance of location request with user's policy

 User shares her protected resources and defines the privacy preferences  System follows pull mechanism. All the different types of information sharing activities among participants are established by the privacy control module in the system.  Whenever any participant makes a query, it is sent to the privacy control module which in turn processes the query by reasoning over the policy networks associated with the resource, and returns the valid answer to the query.  Generalization is applied for the valid answers. 18

 Client device is location aware device like GPS enabled phones or wi-fi enabled laptops  Google maps to plot user and her friends  User interface to define privacy preferences  Connects with Facebook accounts to fetch profile information and find networks of friends  Creates and stores policy ontology in persistent memory and reloads when required by reasoning engine 19

Privacy Configuration User Interface 20

Summary of features of our system and their comparison with the state of the art systems 21

22

 Problem: A system whose access policy is known is more vulnerable to attacks and insider threat Attackers may infer likely policies from access observations, partial knowledge of subject attributes, and background knowledge  Objective: Strengthen policies against discovery  Approach: Explore techniques to propose policy theories via machine learning, including ILP and SVMs  Results: promising initial results for simple Role Based Access Control policies

24

 Practically everyone’s plans are to move to Cloud based systems  Everyone thinks about security for clouds, but almost no one is doing it.  A lot of it is technology, but a lot is management as well  Much of the technology work is focused on isolation at the hypervisor level, but this is not enough  Policies driven security can be of great help in both the technological and management planes

 Most existing work focuses on Isolation for Virtualization  You don’t always want to isolate, sometimes it is good (i.e. efficient) to share  Trusting the virtualized service provider on the cloud  Amazon disclaims any data loss, Facebook wants to own your data …  Constrain what the cloud can do  Don’t replicate outside of US jurisdiction, don’t co-locate with a job run by my competitor, …

 Use computational policies to  Leverage Hypervisor level isolation functions to provide granular isolation  Allow users to specify what kind of security they need at the virtualization level ▪ Sharing and isolation requirements  Allow users to describe how their data is shared/used  Allow clouds to specify what security / Isolation they offer

Goal: self configuring network routers running in a coalition envi- ronment demonstrating constraints on border gateway protocol

29

 An event-based model allows components to share context  Shared semantic models for descriptions, communication and policies  Initial prototype uses Apache Axis2 SOA Framework  Adding a shared Blackbook based component for situation awareness, policy reasoning and enhanced agent-based protocols for advertising, neg- otiation and argumentation service calls & interactions discoveryreleaseuse Blackbook policy reasoner DL reasoner back- ground knowledg eand LOD triple store context and situ- ation awareness Blackbook

Identify functional and technical specifications Determine domain, data type and it’s acceptable quality levels “Request for Service” SERVICE CLOUD CONSUMER Service Discovery Engine List of service providers with advertised service, service levels and cost Service Certification Quality of Service (QoS) contracts between primary service providers and dependent services Service Level Agreement (SLA) between consumer and primary service provider Service composed Dependant services Service packaged, delivered – one time or periodically as needed Service payment Service consumed Service Monitoring

Class Contract Class: Service Level Agreement  SLA Name  Description  SLA Metrics  Penalty Class Contract Negotiation Class : Quality of Service (QOS)  QOS Name  Description  QOS Metrics  Penalty is part of results in Class Dependent Service Sub- Contract Class Service Contract subClass of Class Provider Negotiation Class Consumer Negotiation subClass of results in is part of Class : Provider List  Provider  Service details  Service availability  Service Cost Is used in Class : Request for Service  Service Domain  Exp_Svc_Begin_Date  Exp_Svc_End_Date  RFS_Respond_by_dt  Cost_constraint Is used in