1 / 32

MURI Update

Anupam Joshi and Tim Finin Ebiquity UMBC. MURI Update. http://ebiquity.umbc.edu/. Threads. Constraining Information Flow in Social Networks using Policies and Context Probing Policy secured systems to recover policy SOA based Infrastructure Securing Clouds with Policy.

manton
Download Presentation

MURI Update

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Anupam Joshi and Tim Finin Ebiquity UMBC MURI Update http://ebiquity.umbc.edu/

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

  3. Constraining Information Flow in Social Networks using Policies and Context

  4. Motivation • 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

  5. Mobile geo-social networking systems • 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

  6. iConnect Platform

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

  8. Components of Privacy Framework • 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

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

  10. Policy Description 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

  11. Example Policies 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 

  12. Example Policies Contd. 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

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

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

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

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

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

  18. Policy Execution • 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.

  19. Implementation details • 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

  20. Policy GUI Privacy Configuration User Interface

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

  22. Inferring Policies

  23. Inferring RBAC Policies • Problem: A system whose access policy is known is more vulnerable to attacks and insider threat Attackers may infer likely policies fromaccess observations, partial knowledgeof subject attributes, and backgroundknowledge • Objective: Strengthen policiesagainst discovery • Approach: Explore techniques topropose policy theories via machinelearning, including ILP and SVMs • Results: promisinginitial results forsimple Role Based Access Control policies

  24. Policy for Clouds

  25. Introduction • 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

  26. Problems • 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, …

  27. Proposed Solution • 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

  28. Policy-based Automated Wide-Area Network Configuration and Management Goal: self configuring network routers running in a coalition envi-ronment demonstrating constraints on border gateway protocol

  29. SOA Framework

  30. AIS Service Oriented Architecture service calls & interactions • An event-based model allowscomponents to share context • Shared semantic models fordescriptions, communicationand policies • Initial prototype uses ApacheAxis2 SOA Framework • Adding a shared Blackbook based component for situation awareness, policy reasoning and enhanced agent-based protocols for advertising, neg-otiation and argumentation discovery release use Blackbook policy reasoner DL reasoner back-ground knowledgeand LOD triple store context and situ-ation awareness Blackbook

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

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

More Related