Content Oriented Virtual Domains for Secure Information Sharing Across Organizations

Takayuki Sasaki, Masayuki Nakae, Ryuichi Ogawa

NEC Corporation 1753 Shimonumabe, Nakahara-Ku, Kawasaki, Kanagawa, Japan, +81-44-431-7685

{t-sasaki@fb, m-nakae@bp, r-ogawa@bq}.jp.nec.com ABSTRACT

Secure information sharing across different organizations is an emerging issue for collaborative software development, product design, etc. Virtual domains have been proposed for this issue so far. A virtual domain is a collaborative workspace comprising virtual computer resources dedicated to a particular collaborative activity, and it is subject to information sharing policies that restrict the scope of information sharing within the domain. This paper proposes a method of constructing Content Oriented Virtual Domains, which leverages existing common services such as e-mail, Web, and file servers, therefore enabling us to construct a secure collaborative workspace at lower cost than existing methods that require such services to be reconstructed in the same domain. This paper also shows an experimental implementation of the method and its performance evaluation results. However, these measures can not easily be applied to crossorganization activities because there are few points allowing to enforce project specific security policies. For example, the project manager of a collaborative software development project needs to enforce policies that allow only project members to share projectspecific information such as software specification documents. To achieve this, the manager of an organization has to enforce a policy on the members (and their computing resources) and also common services such as e-mail and file sharing services that may be managed by third parties other than the organizations in collaboration. Generally, enforcing project specific policies onto third parties' services is difficult. For this issue, some studies [1,2] have proposed the idea of virtual domains (also called virtual organizations). A virtual domain is defined as a collection of computer resources distributed across different organizations, and it is subject to a particular set of information sharing policies that restrict the scope of information sharing within the domain. As a method to construct the virtual domains, Bussani et al. [1] proposed Trusted Virtual Domains (TVDs), which comprise trusted resources that are authorized by a hardware token called a Trusted Platform Module. By applying this method to a cross organization project, every project member can safely share information using only the trusted resources in the domain. However, the TVD method allows the member to use only the authorized resources. We have to construct additional resources that provide the services in the same TVD. This is too expensive for most projects, because of the need to construct and manage the additional resources. For reducing such costs, this paper proposes a domain virtualization method named Content Oriented Virtual Domains (CoVD). The CoVD is defined as a collection of computer resources that are connected via common services. This method allows us to leverage existing common services from authorized resources. To make secure information sharing through common services, we use content-based policy enforcement such as encryption onto mails going through common mail services, and contents filtering for files shared in common file services. The rest of this paper is structured as follows. Section 2 describes a CoVD workspace model. Section 3 describes the architecture of the CoVD, and Section 4 shows its implementation. Section 5 presents an evaluation of performance, and section 6 discusses related work. Finally, section 7 concludes the paper.

Categories and Subject Descriptors

D.4.6 [Operating Systems]: Security and ProtectionAccess controls; K.6.4 [Management of Computing and Information Systems] System ManagementCentralization / Decentralization; K.6.5 [Management of Computing and Information Systems]: Security and ProtectionUnauthorized access.

General Terms: Security. Keywords

Authorization, virtualization, security architecture, information sharing.

1. INTRODUCTION
Secure information sharing across different organizations is a crucial issue for collaborative software development, product design, etc. So far, most organizations have taken countermeasures such as firewalls, and mail filtering appliances to protect against information leakage out of individual organizations.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. CCSW10, October 8, 2010, Chicago, Illinois, USA. Copyright 2010 ACM 978-1-4503-0089-6/10/10...$10.00.

2. CONTENT ORIENTED VIRTUAL DOMAINS 2.1 Problem Definition

Figure 1 shows an example of a cross organization project. Here, we assume organizations A and B have physically separated networks and are collaborating on a software development project. A project manager is responsible for project management including its information security. Project members create documents for the project and share these documents using common services. For example, to share specification documents of the software, a project member of organization A sends e-mail to a member of organization B through e-mail services that may be provided by organizations A and, or B, or others. Another example is where the members in both organizations share source code using a file sharing service. They may also share the bug information using a bug tracking system. These common services may be in the company or may be in the cloud such as gmail, and amazon storage service S3. In these examples, we can identify that such common services play an essential role for information sharing in cross organization projects. Also, from the policy manager's view, how to enforce information sharing policies to common services is a crucial issue, which would usually be hard to archive.

organization projects are often temporal, additional costs can not be ignored in many cases.

Figure 2: TVD based workspace model

2.3 CoVD Based Workspace Model

For the cost problem, we propose a workspace model based on Content Oriented Virtual Domains, as shown in figure 3. In this model, a workspace is constructed with a CoVD that comprises project members, authorized resources used by the members, and existing common services can be leveraged without any modification. Different from the TVD based one, this model requires no additional costs for the common services. Please note that the resource authorization may be performed with Trusted Platform Modules as in the TVD, or with authorization software running on the resources.

Figure 1: Cross organization project

2.2 TVD based Workspace Model

For the aforementioned issue, we can utilize the Trusted Virtual Domain method. As shown in figure 2, we can construct a TVD as a cross organization workspace of the project by virtualizing every resource dedicated to a particular project. Note that common services are also virtualized or physically separated from existing resources for common services. Because the TVD method can enforce given policies to all trusted resources in individual TVDs, the project manager can enforce his own policies to all resources of the project members and common services, so the project members can securely share project specific information even through the common services. However, we can identify a cost problem in this workspace model, where all common services dedicated to a project need to be newly constructed apart from existing services. This implies that we need to pay additional costs for the services no matter which resources are virtual and which are physical. Because cross Figure 3: Content oriented virtual domain 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. For example, suppose that a project member of organization A writes an e-mail attached with a specification document to his or her co-worker of organization B. In this case, CoVD automatically 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 contentbased policy enforcement, the CoVD achieves secure information sharing through the existing common services.

Content-based policy enforcement is not restricted to the aforementioned cryptographic manners. In a case where the existing services are located in the same intranet, content filtering is practically secure. In the case of file sharing between divisions in a company, risk is lower than it is an Internet case. In this case, the access control is enough for secure information sharing. Not only are encryption and filtering required, we also require many content based policy enforcements such as virus scan for file sharing services, and web filtering for web services.

enforcers deployed in the physical environment of the project members.

3. ARCHITECTURE 3.1 Requirements

The CoVD described in section 2 comprises the project members, the authorized resources, and the project policies. We can identify the requirements for the management of these components and for the managed member environments comprising these components. (1) Domain management (a) Member management is 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. (2) Member environment in the workspace (d) Resource virtualization is required for creating the project specific resources at low cost. (e) Member authentication is required for allowing only the project members to use the virtual resources. (f) Resource authorization is required for quarantine. (g) The information sharing policy must be enforced on the project documents.

Figure 4: Architecture of CoVD To meet requirements (d) to (g), each physical member environment uses a virtualization platform (D), and also uses a member authentication component (E), a resource authorization component (F), a policy enforcer (G), where (D) The virtualization platform receives a copy of the virtual resource image and creates the virtual resources for constructing a virtual member environment. It also constructs a management environment for the following components. (E) The member authentication component authenticates the members with the accounts provisioned by the member management component or mediates an authentication protocol to the existing authentication server. (F) The resource authorization component checks the signature of the authorized virtual resources to confirm whether the structure of the resources is as defined by the manager. (G) The policy enforcer monitors network communications and enforces the policy on the exchanged documents.

3.2 Architecture Overview

Figure 4 shows the proposed architecture of the CoVD, which comprises a domain management server used by a project manager and physical member environments used by project members. To meet requirements (a) to (c), the domain management server has to have a member management component (A), a resource management component (B), and a policy management component (C). With component (A), the manager registers the member accounts. The component may work with an existing ID management server to retrieve the member account. With component (B), the manager constructs original images of virtual resources. The original images can include OSes, applications, and document files for the project. Then, the manager issues a signature to the virtual resource images and distributes a copy of the image to the virtualization platforms. The manager specifies the attributes (IP address and available protocols) of common services and the physical/virtual resources. With component (C), the manager specifies the information sharing policies for the project, and distributes them to the

4. IMPLEMENTATION 4.1 Implementation Overview

In order to evaluate the feasibility of the cross organizational policy enforcement, we implement 2 core components of the CoVD architecture: (C) a policy management component to specify policies, and (G) policy enforcers to control network data according to the policies. We believe that the CoVD architecture can be applied to various types of information sharing, but here we assume a use case where project members share project documents using a file server via a network. For the other components, there exist implementations widely available. For the member management component, we can use a Microsoft Active Directory, and for the resource authentication component, we can use a TPM/TCG software stack. As virtualization platforms, Xen, VMWare, and Hyper-V are available.

4.2 Policy management component

To allow the project manager to specify policies, we implement a policy management component which comprises a policy editor, a policy repository, and a policy deployer. A policy editor provides the project manager with a Graphic User Interface for specifying policies. The policy repository stores the specified policies. Then, the policy deployer distributes the policies to the policy enforcers on each client. In this prototype, the policy editor is a cgi to provide a web interface and the policy repository is a directory to store policies. The policy deployer is a web server that publishes the directory to the policy enforcer and the policy enforcer retrieves the policies using an HTTP protocol. Here we employ the following policy model. Subject is a member ID such as an IP address of the member environment. Object is a set of documents such as e-mails and files. Action is allowed operations such as sending or receiving documents. Condition is defined over the attributes of the objects such as the recipient of e-mails. Here we denote the condition as a function that returns the object when the condition is true. Obligation is a pre-process or post-process for safely using common services such as mail encryption and logging. Its policy format is shown in figure 5. ConditionFunction_N(...(ConditionFunction_1( ObligationFunction_N(...(ObligationFunction_1( Subject, Object, Action )...) )...) Figure 5: Policy Format Figure 6 describes an example policy for mail exchange. In the figure, the subject corresponds to any source IP address and source port (*:*), which means any project member. The action corresponds to the server IP address (192.168.0.222) and the SMTP port (25), which means send a mail to the server with the adress. The object is implicitly specified as mail. Also, a recipient check condition and an encryption obligation are specified. RecipientCheck( MailEncryption(*:*, ,192.168.0.222:25) ) Figure 6: Example policy

which hooks IP packets and calls the condition plug-in modules and the obligation plug-in modules according to the policies. The condition plug-in module corresponds to a condition function in figure 5 and performs filtering according to the condition. The obligation plug-in module corresponds to an obligation function and performs required content transformation.

Figure 7: Structure of the policy enforcer

Figure 8: Context handler and plug-in modules Next, we design the context handler, which monitors all network communication so that it enforces policies without fail. For this requirement, we implemented the context handler as a bridge driver. In the Xen architecture, the bridge driver connects DomU (the virtual member environment) and a physical Network Interface Card (NIC). Therefore, the context handler can monitor all network traffic as a bridge. To enforce policies, the context handler finds an appropriate policy by identifying the IP address and port number of IP packets. Then, the context handler interprets the policy and calls condition plug-in modules and obligation plug-in modules. In order to call the plug-in modules, the context handler performs a Network Address Translation (NAT) (Figure 8). Each plug-in module has a virtual NIC and opens sockets on its virtual NIC. Then, the context handler hooks IP packets to/from the DomU and performs the NAT so that the network connection goes thorough plug-in modules. To be more precise, the context handler performs the NAT according to the policy as the following steps. Step 1 (find out the policy): The context handler monitors the IP packets and identifies the source/destination IP address and the source/destination port number. Then, the context handler finds the policy according to the IP addresses and port numbers. If the IP addresses and the port

4.3 Policy Enforcer

As described in 3.2, the policy enforcer should be deployed in the management environment which is separated from the virtual member environment. For this requirement, we use Xen and deploy the policy enforcer in the Dom0 corresponding to the management environment. Beside Dom0, DomU corresponding to the virtual member environment is deployed. First, we design an extensible structure that allows the project manager to expand the policy expression capability by adding a plug-in module. In the Dom0, the policy enforcer comprises a context handler, condition plug-in modules and obligation plug-in modules (Figure 7). The context handler is a policy interpreter,

10

numbers do not match any policies, the context handler drops the packet. Step 2 (call condition functions): The context handler refers to the first condition plug-in modules IP address. Then the context handler changes the destination IP address into the first module's IP address. Next, the context handler hooks the packets from the first module, and then the context handler transfers the packets to the next module. In the same way, the context handler repeats the NAT till the last condition module. 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 servers IP address.

module permitted the mail, and the mail encryption module encrypted the mail. Recipient check module: recipient matches the project member list Mail encryption module: encrypt mail Figure 11: Log of recipient check and encryption Next, we sent a mail to a non-project member. The recipient check module output the following log (Figure 12), which means that the recipient check module dropped the mail. Recipient check module: recipient does not match Figure 12: Log of mail reject Those results demonstrate that project members can share information safely in the CoVD using the mail service.

5. EVALUATION 5.1 Performance Evaluation

To evaluate the policy enforcement, we assumed a use case where there is an existing mail server and where project members share project documents using this server (Figure 9). We used Thunderbird as the mailer and Postfix as the server.

5.2 Efficiency Evaluation

To assess the efficiency of the context handler and the modules, we measured the time to download a file using a WebDAV client (cadaver version 0.23.0 with neon version 0.27.2). We used two machines with a Pentium D 3.4GHz CPU, 3 GB memory and an onboard Intel e1000 NIC. The two were connected via a 100 Mbps hub, and one was used for a server, and the other was used for a client. First, we downloaded some files that had different sizes (1 MB, 10 MB, 50 MB, 100 MB) and measured the download time in 2 cases. In case (a), we used an unmodified Xen bridge driver, and in case (b), we deployed a context handler and a plug-in module with the plug-in interface. The module was implemented using Perl, and it had a dummy security function. Figure 13 shows that we can identify that the download time is proportional to file size and that 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. We then calculated the overhead using the following expression. 0.2166 / 0.1562 = 1.387 (38.7%) Using a system profiler (OProfile) we identified that the overhead was caused by network communication between the context handler and the plug-in modules. The optimization is our future work.
25 ( Unm odii xen brdge a) fed i tm e = 0. i 1562 * fl ze i esi 20 ( CH +pl n i er ace b) ug-i nt f + a m odul e tm e = 0. i 2166*fl ze i esi

Figure 9: Secure mail exchange In this use case, we assumed that project members should send mail only to other project members to prevent information leakage. Moreover, the mail must be encrypted to prevent eavesdropping. Thus, we described following policy (Figure 10) and deployed the policy to the senders context handler. RecipientCheck ( MailEncryption(*:*,,192.168.0.3:25) ) Figure 10: A policy for secure mail exchange To send a mail using the existing mail server, we specified the IP address of the existing mail server as destination IP (192.168.0.3) and also specified the SMTP port (25) as the destination port. Moreover, in order to enforce recipient check and mail encryption, we specified that a recipient check module block mail to non-project members and that a mail encryption module encrypt the body of the mail. When a project member sends a mail, the recipient check module and the mail encryption module work as follows. The recipient check module analyzes the SMTP protocol and identifies recipients. Then, it 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. The mail encryption module also analyzes the SMTP protocol and identifies the mail body. Then, it encrypts the mail body using the project key. First, we sent a mail to a project member whose mail address was allowed by the allowable recipient list. Then the modules output following log (Figure 11), which means that the recipient check

Time (sec)

15

10

0 0 20 40 60 80 100 120

File size (MB)

Figure 13:

File size and download time

11

6. RELATED WORK 6.1 VPN based approach

Virtual Private Network (VPN) is a kind of overlay network, and it constructs a private network by encrypting the communication channel. Sailer proposed a remote client access control enforcement architecture [3] that allows the organization manager to enforce the organization policies onto a computer connected with the VPN. Yin proposed an application-aware IPsec policy system[4], which enforces the application security policy for each application. To enforce the security policy, the system translates the application security policy into the IP sec policy and establishes IPsec communication channel for each application. Trusted network connect (TNC) [5] has been proposed by the Trusted Computing Group (TCG). TCG aims to measure the integrity of the computer using a hardware security chip named Trusted Platform Module (TPM) [6]. To create a strong quarantine network, TNC performs remote attestation using TCG integrity measurement technology. These VPN approaches focus on document sharing within a single organization, while we focus on cross organizational document sharing.

7. CONCLUSION
In this paper we proposed a method of constructing Content Oriented Virtual Domains, which leverages existing common services and enables a secure collaborative workspace. The CoVD monitors document exchange, checks conditions, and enforces obligations according to project policies. We implemented the policy management component and the policy enforcer, which can expand policy description capability by adding a plug-in module. We evaluated its performance and concluded that CoVD allows us to share project documents safely using existing services such as e-mail.

8. REFERENCES
[1] Anthony Bussani et al, Trusted Virtual Domains: Secure Foundations for Business and IT Services TBM Research Report RC23792, 2005 Xinwen Zhang, Towards A Usage-based Security Framework for Collaborative Computing Systems, ACM Transactions on Information and System Security, Volume 11 , Issue 1, 2008. Reiner Sailer, Attestation-based Policy Enforcement for Remote Access, Conference on Computer and Communications Security ,2004 Heng Yin et al, Building an Application-Aware Ipsec Policy System, IEEE/ACM transactions on networking, Vol 15,NO.6, December 2007 TCG Architecture Overview, Version 1.4, http://www.trustedcomputinggroup.org/developers/trusted_net work_connect/specifications TPM Main Specification, http://www.trustedcomputinggroup. org/resources/tpm_main_specification Reiner Sailer et al. , Building a MAC-Based Security Architecture for the Xen Open-Source Hypervisor, ACSAC Proceedings of the 21st Annual Computer Security Applications Conference, 2005 Yacine Gasmi, et al, Flexible and Secure Enterprise Rights Management based on Trusted Virtual Domain, STC'08 Yuji Watanabe, Sachiko Yoshihama, Takuya Mishina, Michiharu Kudo , and Hiroshi Maruyama. Bridging the Gap Between Inter-communication Boundary and Internal Trusted Components, Lecture Notes in Computer Science, volume 4189, 2006

[2]

[3]

6.2 Virtualization Based Policy Enforcement

Many studies virtualization. attempted enforcing access control using Bussani et al. proposed a Trusted Virtual Domain (TVD) [1] based on access control between trusted resources. Only the authenticated resource can join the TVD, and the user can safely share the project content in the TVD. sHype [7] is a policy enforcer of the TVD. sHype enforces mandatory access control according to the type enforcement policy and the Chinese wall policy, and it is implemented on Xen. Gasmi has proposed the Enterprise Rights Management (ERM) system on TVD (ERM-TVD)[8]. ERM-TVD deploys an ERM controller on each client of the TVD and controls content workflows in a domain. Watanabe et al. proposed a Secure Message Router (SMR) that provides end-to-end secure channel establishment and content routing between TVDs. SMR translates a node specific message (e.g. BLP policy, MAC policy) into interoperable messages and performs routing between virtual user environments. Both the TVD and our approach share the project content in the domain. However, as described in 2.3, our approach leverages a public service to reduce the cost and supports the condition and obligation for secure communication using the service. European Multilaterally Secure Computing Base (EMSCB) [10] separates the security and resource management function from the legacy OS using virtualization. NetTop [11] enables multi-level security (MLS) using virtual machines and SELinux. Trusted Solaris [12] assigns a label to each virtual OS to enable multi-level security, and it controls information flow between OSs according to the label. Application-Level Distributed Coalition (ALDC) [13] enforces Chinese wall policy using application programming interface (API) hooking. A prototype has been implemented on Microsoft Windows for controlling office documents.

[4]

[5]

[6] [7]

[8] [9]

[10] Ahmad-Reza Sadeghi et al. European Multilateral Secure Computing Base - Open Trusted Computing for You and Me, Datenschutz und Datensicherheit (DUD) 9/2004, Vieweg Verlag, pp. 548-554, 2004. [11] HP NetTop, http://h71028.www7.hp.com/enterprise/cache/48 852-0-0-225-121.html?jumpid=ex_R2548_go/nettop [12] Trusted Solaris, http://www.sun.com/software/solaris/trusteds olaris/index.xml [13] Yasuharu Katsuno, Yuji Watanabe, Sanehiro Furuichi, Michiharu Kudo , Chinese-wall process confinement for practical distributed coalitions, SACMAT '07

12