Secure Information Sharing

1. Secure Information Sharing By FawazAlsaadi & FahadAlsolami CS691 - Summer 2011

2. Content Oriented Virtual Domains for Secure InformationSharing Across Organizations

3. INTRODUCTION • Secure information sharing across different organizations is an emerging issue for collaborative software development, product design. • The external threats are taken care of by using firewalls and mail filtering appliances. • For cross organizational security virtual domain is proposed. • Virtual domain is a collection of computer resources distributed across different organization.

4. Cross organization project • Organizations A and B are collaborating on a software development project. • A project manager responsible for project management • including its information security. • Project members create documents for the project and share these documents using common services • How to enforce policy to common services?

5. Trusted Virtual Domain based Workspace Model One existing solution • A TVD is constructed as a cross organization workspace of the project by virtualizing every resource dedicated to a particular project. • Project manager can enforce given policies to all trusted resources in individual TVD. • Good: Allows project members to securely share project specific information even through the common services • Bad: In this model, all common services dedicated to a project need to be newly constructed apart from existing services. This require additional cost even if the resources are virtual.

6. CoVD Based Workspace Model For reducing such costs, • Domain virtualization using Content Oriented Virtual Domains (CoVD): • CoVD is a collection of computer resources that are connected via common services. • Allow leveraging existing common services from authorized resources. • Allows content-based policy enforcement such as encryption onto mails going through common mail services, and contents filtering for files shared in common file services

7. CoVD Based Workspace Model • The CoVD comprises project members, authorized resources, and the project policies. • Existing common services can be leveraged without any modification. • CoVD model requires no additional costs for the common services

8. CoVD Based Workspace Model • To make secure information sharing through the existing services, the policy is enforced not to the authorized resources, but to the project documents shared in common services.

9. CoVD Based Workspace Model • Example of email: • A project member of organization A writes an e-mail attached with a specification document to his or her co-worker of organization B. • CoVDautomatically encrypts the email with a project-specific shared key accordingly to the policies given by a project manager. • Because the project key is shared within the authorized resources of the CoVD, the specification documents are accessible by only the project members, even if the e-mail goes through the existing mail servers. • With this content based policy enforcement, the CoVD achieves secure information sharing through the existing common services

10. CoVD ARCHITECTURE • Requirements • Domain management a) Member management required for specifying the project members. b) Resource management is required for constructing and authenticating virtual resources used in the member environment. c) Policy management is required for specifying and distributing the project information sharing policies to the member environments. • Member environment in the workspace d) Resource virtualization is required for creating the project specific resources at low cost. e) Member authentication for allowing only the project members to use the virtual resources. f) Resource authorization for quarantine. g) The information sharing policy must be enforced on the project documents

11. CoVD ARCHITECTURE Overview • Domain management server has • Member management component (A), • Resource management component (B), • Policy management component (C)

12. CoVD ARCHITECTURE Overview • Domain management • Component (A) • The manger registers the member accounts • Component (B) • The manger constructs original images of virtual resources. Then, issues a signature to the virtual resource images and distributes a copy of the images to the virtualization platforms. • Component (C) • The manger specifies the information sharing policies for the project, and distributes them to the enforcers.

13. CoVD ARCHITECTURE Overview • Member environment in the workspace. • Each physical member environment uses a • virtualization platform (D) • member authentication component (E) • Resource authorization component (F), • Policy enforcer (G)

14. CoVD ARCHITECTURE Overview • Member environment • virtualization platform (D) • Receives a copy of the virtual resource image and creates the virtual resources for constructing a virtual member environment. • Member authentication component (E) • Authenticates the members with the accounts

15. CoVD ARCHITECTURE Overview • Member environment • Resource authorization component (F) • Checks the signature of the authorized virtual resources to confirm whether the structure of the resources is as defined by the manager. • Policy enforcer (G) • Monitors network communications • Enforces the policy on the exchanged documents

16. IMPLEMENTATION • Feasibility of the cross organizational policy enforcement was evaluated by implementing 2 core components of the CoVD architecture: • Policy management component to specify policies, and • Policy enforcers to control network data according to the policies • Widely available implementations used for other components such as: • Member management component: Microsoft Active Directory • Resource authentication component: TPM/TCG software stack • Virtualization platforms: Xen, VMWare, and Hyper-V

17. Policy management component • Allows the project manager to specify policies & consists of: • Policy editor: Allows to specify policies • A cgi to provide a web interface • Policy repository to store the specified policies • directory to store policies • Policy deployer distributes the policies to the policy enforcers on each client • web server that publishes the directory to the policy enforcer

18. Policy enforcer • Retrieves the policies using an HTTP protocol. • Deployed in the management environment which is separated from the virtual member environment. • Xen is used • Policy enforcer in the deployed in Dom0 corresponding to the management environment.

19. Policy enforcer • Design an extensible structure that allows the manager to expand the policy expression capability by adding a plug-in module. • In Dom0, policy enforcer comprises of • context handler, • condition plug-in modules • obligation plug-in modules

20. Policy enforcer • Context handler is a • Policy interpreter, which • Hooks IP packets • Calls the condition plug-in modules and obligation plug-in modules • condition plug-in module • Performs filtering according to the condition • Obligation plug-in modules according • performs required content transformation to the policies

21. Policy enforcer • Context handler • Monitors all network communication so that it enforces policies without fail. • Context handler implemented as a bridge driver that connects DomU and network interface card.

22. Policy enforcer • Context handler policy enforcement • Finds an appropriate policy by identifying the IP address and port number of IP packets • Context handler interprets the policy and calls condition plug-in modules and obligation plug-in modules • To call the plug-in modules, the context handler performs a Network Address Translation (NAT) • Each plug-in module has a virtual NIC and opens sockets on its virtual NIC. • Context handler hooks IP packets to/from the DomU and performs the NAT so that the network connection goes thorough plug-in modules

23. Policy enforcer • Context handler performs the NAT according to the policy • Step 1 (find out the policy) • Monitors the IP packets and identifies the source/destination IP address and the source/destination port number. • Context handler finds the policy according to the IP addresses and port numbers. • If the IP addresses and the port numbers do not match any policies, the context handler drops the packet.

24. Policy enforcer • Context handler performs the NAT according to the policy • Step 2 (call condition functions) • Context handler refers to the first condition plug-in module’s IP address. • Context handler changes the destination IP address into the first module's IP address. • Context handler hooks the packets from the first module • Context handler transfers the packets to the next module. • In the same way, the context handler repeats the NAT till the last condition module.

25. Policy enforcer • Context handler performs the NAT according to the policy • Step 3 (call obligation functions) • The context handler transfers the packets to obligation plug-in modules. • If the context handler hooks a packet from the last obligation module, the context handler changes the destination IP address into the server’s IP address.

26. Performance Evaluation • Use case where there is an existing mail server • Project members share project documents using this server. • Used Thunderbird as the mailer and Postfix as the server.

27. Performance Evaluation • Secure mail exchange • Assumed that project members should send mail only to other project members to prevent information leakage. • Mail is encrypted to prevent eavesdropping. • Used following policy for secure mail exchange: RecipientCheck (MailEncryption(*:*,,192.168.0.3:25) )

28. Performance Evaluation • Secure mail exchange • Project member sends a mail, • Recipient check module analyzes the SMTP protocol and identifies recipients. • Checks to see if the recipient is allowed using the allowable recipient list. • If the recipient is allowed, the module mediates the mail. Otherwise, the module drops the mail and closes the network connection to the server. • Mail encryption module also analyzes the SMTP protocol and identifies the mail body. • It encrypts the mail body using the project key

29. Efficiency Evaluation • Efficiency of the context handler and the modules were measured using the time to download a file using a WebDAV client (cadaver version 0.23.0 with neon version 0.27.2) • Used two machines Pentium D 3.4GHz CPU, 3 GB memory with onboard Intel e1000 NIC. • The two were connected via a 100 Mbps hub, • One machine was used for a server, and the other was used for a client. • Downloaded files of different sizes (1 MB, 10 MB, 50 MB, 100 MB) and measured the download time in 2 cases • Used an unmodified Xen bridge driver in case (a) • In (b) case a context handler and a plug-in module with the plug-in interface was deployed • The module was implemented using Perl, and it had a dummy security function

30. Efficiency Evaluation • The download time is proportional to file size • The overhead of case (b) is almost constant regardless of the file size. • In case (a), the regression line is time = 0.1562 * file size, • In case (b), time = 0.2166 * file size • The overhead was calculated using 0.21 66 / 0.1562 = 1.387 (38.7%) • Using system profiler (OProfile) it was identified that the overhead was caused by network communication between the context handler and the plug-in modules

31. RELATED WORK • VPN based approach • VPN approaches focus on document sharing within a single organization, while paper’s focus was on cross organizational document sharing. • Virtualization Based Policy Enforcement • The main difference in other approaches such as TVD is that this paper’s approach leverages public service to reduce the cost.

32. CONCLUSION • Proposed a method of constructing Content Oriented Virtual Domains, which leverages existing common services and enables a secure collaborative workspace. • CoVDmonitors document exchange, checks conditions, and enforces obligations according to project policies. • Implemented the policy management component and the policy enforcer, which can expand policy description capability by adding a plug-in module. • Performance evaluation showed that CoVD allows sharing the project documents safely using existing services such as e-mail.

33. Thank You

34. Secured Distributed Multi-Agent Role Based AccessControl

35. Introduction • Role Based Multi-Agent System for providing effective and secure Bank transaction services • To provide seamless access to information present in the database • Negotiation agent to access and trust negotiations, • Database agent and Interface Agent to accept and display request service results.

36. Introduction • Main Features of the system • Ease of use, • Effective communication between customers and service providers, • Isolation from resource specific details, changes in the system and internal complexity

37. Introduction • Agents developed using Java Agent • Development Framework (JADE) • Java APIs • System provides features such as • The Login Validation or User Authentication • Service Registration, • Role Agent Identification, and • User Interface for an effective interaction between customer and the system. • The role agent retrieves the information from database and sends it to the customer through an interface agent.

38. System Architecture • System accepts the customer request by interface agent. • The facilitator is used to register the service of role agents. • The role agent has the ability to forward the request to negotiator for the validation of request and account details.

39. System Architecture • The database agent possesses the capacity to retrieve the customer information. • The interface agent is used to display the customer details.

40. System Architecture • User Interface • Graphical User Interface • Mobile Agent Creation module • Server with appropriate resource is identified to process the customer request. • Facilitator coordinates the mobile agent to process customer request. • Facilitator registers the agent to access a particular service using its Agent ID. • After completion of the customer service the facilitator deregisters the service.

41. System Architecture • Loan Mobile Agent • System lists the available bank loan schemes to the customer • Checks the customer’s history • If the customer has sufficient balance, the loan is sanctioned • New loan is not entitled unless the customer pays the previous dues. • The customer balance amount gets updated when permitted to avail the loan.

42. System Architecture • Credit Card Agent • Provides access rights to the customer • Sends the customer information to interface agent. • Interface agent coordinates the Credit Card Agent to register its service with the facilitator. • Role of the agent is to process the customer request. • The role based agent checks the customer’s earlier due regarding cash or purchase. • If customer do not have due then the customer is permitted to use the credit card within the permitted limit. • If the customer has dues, credit card payment is barred

43. System Architecture • Insurance agent • Provides information to all customers about the insurance offers (i.e. access to polices, brochures and price list). • Describes the characteristics of different types of insurance and their attributes.

44. System Architecture Payment of Insurance bill 1 Electronic bill generation 2. Payment order 3. Electronic notification for sufficient money 4. Electronic notification to Insurance agent 5. Verification of money transfer

45. System Architecture • Decision Agent • Makes the decision from the role based multiagents with the coordination of a data warehouse.

46. Multi-Agent Communication • To achieve the individual objectives or dynamically coordinate the actions, software agents need to interact with one another. • Communication is at the basis of agents interactions • Foundation for Intelligent Physical Agent (FIPA) • Interaction Protocols for Agents Conversations

47. Multi-Agent Communication • Foundation for Intelligent Physical Agent (FIPA) • Specifies standard components that can be used • Determination of valid sequences of messages called INteraction Protocols (INP) regulating specific interactions to be known by all the interacting entities

48. Multi-Agent Communication • Foundation for Intelligent Physical Agent (FIPA) • Agent Communication Language (ACL) • Enables the attitudes regarding the content of exchange to be expressed. • e.g. whether the content of the communication is, an assertion, a request or some form of query • Two most deployed ACL: FIPA-ACL and Knowledge Query Manipulation Language (KQML).

49. Multi-Agent Communication • Foundation for Intelligent Physical Agent (FIPA) • FIPA-SL, Knowledge Interchange Format (KIF) content Languages (CLs) used for describing the content of the message • At the ontology level, a vocabulary and a set of agreed definitions is used to describe a specific domain in terms of objects, actions and functions

50. Multi-Agent Communication • Interaction Protocols for Agents Conversations • Typical patterns of message exchange • Represent the highest abstraction component in the Agent Communication Stack • Standard fipa-request protocol is used when the Interface agent contacts the Role Based Agent for requesting the information of customer account • Identifies the specific kind of ACL messages which the agents are expected to exchangeas shown in Figure. • The standard FIPA-request interaction protocol