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 Protection—Access controls; K.6.4 [Management of Computing and Information Systems] System Management—Centralization / Decentralization; K.6.5 [Management of Computing and Information Systems]: Security and Protection—Unauthorized 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. CCSW’10, October 8, 2010, Chicago, Illinois, USA. Copyright 2010 ACM 978-1-4503-0089-6/10/10...$10.00.

7

Because the project key is shared within the authorized resources of the CoVD. Figure 1: Cross organization project 2. we can utilize the Trusted Virtual Domain method. In this case. even if the e-mail goes through the existing mail servers. this model requires no additional costs for the common services. or with authorization software running on the resources. and existing common services can be leveraged without any modification. In this model. A project manager is responsible for project management including its information security. as shown in figure 3. how to enforce information sharing policies to common services is a crucial issue. a workspace is constructed with a CoVD that comprises project members. For example. the project manager can enforce his own policies to all resources of the project members and common services. but to the project documents shared in common services. However. Another example is where the members in both organizations share source code using a file sharing service. As shown in figure 2. In these examples. the specification documents are accessible by only the project members. we can identify a cost problem in this workspace model. the policy is enforced not to the authorized resources. and amazon storage service S3.1 Problem Definition Figure 1 shows an example of a cross organization project. or others. Please note that the resource authorization may be performed with Trusted Platform Modules as in the TVD. These common services may be in the company or may be in the cloud such as gmail. With this contentbased policy enforcement. Also. CONTENT ORIENTED VIRTUAL DOMAINS 2. authorized resources used by the members.2. Different from the TVD based one. to share specification documents of the software. Figure 2: TVD based workspace model 2.2 TVD based Workspace Model For the aforementioned issue. we can construct a TVD as a cross organization workspace of the project by virtualizing every resource dedicated to a particular project. we can identify that such common services play an essential role for information sharing in cross organization projects. This implies that we need to pay additional costs for the services no matter which resources are virtual and which are physical. we propose a workspace model based on Content Oriented Virtual Domains. where all common services dedicated to a project need to be newly constructed apart from existing services. additional costs can not be ignored in many cases. They may also share the bug information using a bug tracking system. the CoVD achieves secure information sharing through the existing common services. CoVD automatically encrypts the email with a project-specific shared key accordingly to the policies given by a project manager. which would usually be hard to archive. organization projects are often temporal. so the project members can securely share project specific information even through the common services. For example.3 CoVD Based Workspace Model For the cost problem. 8 . from the policy manager's view. Project members create documents for the project and share these documents using common services. Note that common services are also virtualized or physically separated from existing resources for common services. Because cross Figure 3: Content oriented virtual domain based workspace model To make secure information sharing through the existing services. 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. Here. 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. we assume organizations A and B have physically separated networks and are collaborating on a software development project. or B. Because the TVD method can enforce given policies to all trusted resources in individual TVDs.

we can use a Microsoft Active Directory. In the case of file sharing between divisions in a company. (f) Resource authorization is required for quarantine. 3. but here we assume a use case where project members share project documents using a file server via a network. (e) Member authentication is required for allowing only the project members to use the virtual resources. and for the resource authentication component. To meet requirements (a) to (c).1 Requirements The CoVD described in section 2 comprises the project members. a resource management component (B). (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. 3. We believe that the CoVD architecture can be applied to various types of information sharing. the manager constructs original images of virtual resources. (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. the access control is enough for secure information sharing. and distributes them to the 4. applications. With component (A). and Hyper-V are available. and a policy management component (C). and web filtering for web services. (2) Member environment in the workspace (d) Resource virtualization is required for creating the project specific resources at low cost. and (G) policy enforcers to control network data according to the policies. It also constructs a management environment for the following components. ARCHITECTURE 3. The component may work with an existing ID management server to retrieve the member account. each physical member environment uses a virtualization platform (D). there exist implementations widely available. we also require many content based policy enforcements such as virus scan for file sharing services. the domain management server has to have a member management component (A). The original images can include OSes. Figure 4: Architecture of CoVD To meet requirements (d) to (g). risk is lower than it is an Internet case. In a case where the existing services are located in the same intranet. (b) Resource management is required for constructing and authenticating virtual resources used in the member environment. we can use a TPM/TCG software stack. IMPLEMENTATION 4. a resource authorization component (F). and also uses a member authentication component (E).2 Architecture Overview Figure 4 shows the proposed architecture of the CoVD. In this case.Content-based policy enforcement is not restricted to the aforementioned cryptographic manners.1 Implementation Overview In order to evaluate the feasibility of the cross organizational policy enforcement. content filtering is practically secure. we implement 2 core components of the CoVD architecture: (C) a policy management component to specify policies. The manager specifies the attributes (IP address and available protocols) of common services and the physical/virtual resources. Then. (1) Domain management (a) Member management is required for specifying the project members. the authorized resources. where (D) The virtualization platform receives a copy of the virtual resource image and creates the virtual resources for constructing a virtual member environment. the manager issues a signature to the virtual resource images and distributes a copy of the image to the virtualization platforms. With component (C). Xen. For the other components. As virtualization platforms. VMWare. enforcers deployed in the physical environment of the project members. the manager specifies the information sharing policies for the project. and the project policies. and document files for the project. which comprises a domain management server used by a project manager and physical member environments used by project members. a policy enforcer (G). Not only are encryption and filtering required. (c) Policy management is required for specifying and distributing the project information sharing policies to the member environments. For the member management component. 9 . (g) The information sharing policy must be enforced on the project documents. We can identify the requirements for the management of these components and for the managed member environments comprising these components. the manager registers the member accounts. With component (B). (G) The policy enforcer monitors network communications and enforces the policy on the exchanged documents.

168. The action corresponds to the server IP address (192. we implement a policy management component which comprises a policy editor. To be more precise. A policy editor provides the project manager with a Graphic User Interface for specifying policies. The policy repository stores the specified policies. The obligation plug-in module corresponds to an obligation function and performs required content transformation.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 policy enforcer should be deployed in the management environment which is separated from the virtual member environment. For this requirement.2. To enforce policies. First. Subject is a member ID such as an IP address of the member environment. the policy deployer distributes the policies to the policy enforcers on each client. In the Dom0. and a policy deployer.. In order to call the plug-in modules. Then..0. ConditionFunction_N(. In the figure. we implemented the context handler as a bridge driver.) ). Each plug-in module has a virtual NIC and opens sockets on its virtual NIC.0. which means “send a mail to the server with the adress.222) and the SMTP port (25). which monitors all network communication so that it enforces policies without fail. the context handler performs the NAT according to the policy as the following steps. Beside Dom0. Action ). Figure 7: Structure of the policy enforcer Figure 8: Context handler and plug-in modules Next. we design an extensible structure that allows the project manager to expand the policy expression capability by adding a plug-in module.. the subject corresponds to any source IP address and source port (*:*). Object is a set of documents such as e-mails and files. the policy enforcer comprises a context handler. the context handler finds an appropriate policy by identifying the IP address and port number of IP packets. In the Xen architecture. 10 . the context handler can monitor all network traffic as a bridge. Then. Then.168..) Figure 5: Policy Format Figure 6 describes an example policy for mail exchange.2 Policy management component To allow the project manager to specify policies.192. .(ObligationFunction_1( Subject.. the context handler performs a Network Address Translation (NAT) (Figure 8). For this requirement.” The object is implicitly specified as mail. the policy editor is a cgi to provide a web interface and the policy repository is a directory to store policies. a recipient check condition and an encryption obligation are specified. condition plug-in modules and obligation plug-in modules (Figure 7). the bridge driver connects DomU (the virtual member environment) and a physical Network Interface Card (NIC). the context handler interprets the policy and calls condition plug-in modules and obligation plug-in modules. we use Xen and deploy the policy enforcer in the Dom0 corresponding to the management environment. a policy repository. Here we employ the following policy model. 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. If the IP addresses and the port 4.(ConditionFunction_1( ObligationFunction_N(. RecipientCheck( MailEncryption(*:*.. DomU corresponding to the virtual member environment is deployed. 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. 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 denote the condition as a function that returns the object when the condition is true. Also.4. In this prototype. Therefore. The condition plug-in module corresponds to a condition function in figure 5 and performs filtering according to the condition. Then. the context handler finds the policy according to the IP addresses and port numbers. which means “any project member”. the context handler hooks IP packets to/from the DomU and performs the NAT so that the network connection goes thorough plug-in modules. Object. Action is allowed operations such as sending or receiving documents. we design the context handler. The context handler is a policy interpreter.3 Policy Enforcer As described in 3.. Condition is defined over the attributes of the objects such as the recipient of e-mails.

the context handler repeats the NAT till the last condition module. 25 ( Unm odii xen brdge a) fed i tm e = 0. In case (a). we used an unmodified Xen bridge driver. it encrypts the mail body using the project key. we sent a mail to a non-project member.3:25) ) Figure 10: A policy for secure mail exchange To send a mail using the existing mail server.. 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. The two were connected via a 100 Mbps hub.1 Performance Evaluation To evaluate the policy enforcement. which means that the recipient check module dropped the mail. module permitted the mail. First. and it had a dummy security function. Step 3 (call obligation functions): The context handler transfers the packets to obligation plug-in modules. Then. 50 MB. and the mail encryption module encrypted the mail.2166 / 0. the module mediates the mail. Then the context handler changes the destination IP address into the first module's IP address. and the other was used for a client. Next.2166 * file size. and one was used for a server. We used Thunderbird as the mailer and Postfix as the server. Step 2 (call condition functions): The context handler refers to the first condition plug-in module’s IP address.4GHz CPU. we assumed that project members should send mail only to other project members to prevent information leakage.0. 100 MB) and measured the download time in 2 cases.0 with neon version 0. i 2166*fl ze i esi Figure 9: Secure mail exchange In this use case. in case (b). 5.1562 = 1.27. time = 0. and then the context handler transfers the packets to the next module. 5. We used two machines with a Pentium D 3. 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. the context handler changes the destination IP address into the server’s IP address. 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. First. the recipient check module and the mail encryption module work as follows. The module was implemented using Perl. 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. Recipient check module: recipient matches the project member list Mail encryption module: encrypt mail Figure 11: Log of recipient check and encryption Next.2 Efficiency Evaluation To assess the efficiency of the context handler and the modules. we downloaded some files that had different sizes (1 MB. In case (a). We then calculated the overhead using the following expression. the context handler hooks the packets from the first module. we assumed a use case where there is an existing mail server and where project members share project documents using this server (Figure 9). the context handler drops the packet. it checks to see if the recipient is allowed using the allowable recipient list. The optimization is our future work. in order to enforce recipient check and mail encryption.168. Moreover.0.23. RecipientCheck ( MailEncryption(*:*. the mail must be encrypted to prevent eavesdropping.387 (38.168. The recipient check module output the following log (Figure 12). 3 GB memory and an onboard Intel e1000 NIC. we deployed a context handler and a plug-in module with the plug-in interface. we sent a mail to a project member whose mail address was allowed by the allowable recipient list. Thus.2).3) and also specified the SMTP port (25) as the destination port. the regression line is time = 0. 10 MB. the module drops the mail and closes the network connection to the server. In the same way. Then. we measured the time to download a file using a WebDAV client (cadaver version 0. Then the modules output following log (Figure 11). When a project member sends a mail. which means that the recipient check Time (sec) 15 10 5 0 0 20 40 60 80 100 120 File size (MB) Figure 13: File size and download time 11 . If the recipient is allowed. 0.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. and in case (b). The mail encryption module also analyzes the SMTP protocol and identifies the mail body. EVALUATION 5. If the context handler hooks a packet from the last obligation module.numbers do not match any policies. Moreover. The recipient check module analyzes the SMTP protocol and identifies recipients. we described following policy (Figure 10) and deployed the policy to the sender’s context handler.192.1562 * file size. Otherwise. we specified the IP address of the existing mail server as destination IP (192.

7.sun.hp.2 Virtualization Based Policy Enforcement Many studies virtualization.com/software/solaris/trusteds olaris/index. European Multilaterally Secure Computing Base (EMSCB) [10] separates the security and resource management function from the legacy OS using virtualization. IEEE/ACM transactions on networking. “Towards A Usage-based Security Framework for Collaborative Computing Systems”. “Trusted Virtual Domains: Secure Foundations for Business and IT Services” TBM Research Report RC23792. Version 1. Reiner Sailer.org/developers/trusted_net work_connect/specifications TPM Main Specification. http://www. Trusted network connect (TNC) [5] has been proposed by the Trusted Computing Group (TCG). org/resources/tpm_main_specification Reiner Sailer et al. We evaluated its performance and concluded that CoVD allows us to share project documents safely using existing services such as e-mail. REFERENCES [1] Anthony Bussani et al. sHype [7] is a policy enforcer of the TVD.6.trustedcomputinggroup.3. Both the TVD and our approach share the project content in the domain. which can expand policy description capability by adding a plug-in module.6. attempted enforcing access control using Bussani et al.trustedcomputinggroup. 2005 Xinwen Zhang. “Building an Application-Aware Ipsec Policy System”. NetTop [11] enables multi-level security (MLS) using virtual machines and SELinux. TCG aims to measure the integrity of the computer using a hardware security chip named Trusted Platform Module (TPM) [6]. ACSAC Proceedings of the 21st Annual Computer Security Applications Conference. 548-554. which leverages existing common services and enables a secure collaborative workspace. December 2007 TCG Architecture Overview. http://www. ERM-TVD deploys an ERM controller on each client of the TVD and controls content workflows in a domain. sHype enforces mandatory access control according to the type enforcement policy and the Chinese wall policy. 2005 Yacine Gasmi. [4] [5] [6] [7] [8] [9] [10] Ahmad-Reza Sadeghi et al. “Building a MAC-Based Security Architecture for the Xen Open-Source Hypervisor”.g. Vieweg Verlag. which enforces the application security policy for each application.html?jumpid=ex_R2548_go/nettop [12] Trusted Solaris. proposed a Secure Message Router (SMR) that provides end-to-end secure channel establishment and content routing between TVDs.NO. Michiharu Kudo . Michiharu Kudo . Conference on Computer and Communications Security . BLP policy. STC'08 Yuji Watanabe. A prototype has been implemented on Microsoft Windows for controlling office documents. and it controls information flow between OSs according to the label. “Flexible and Secure Enterprise Rights Management based on Trusted Virtual Domain”. Lecture Notes in Computer Science.xml [13] Yasuharu Katsuno. Yuji Watanabe. 2006 [2] [3] 6. TNC performs remote attestation using TCG integrity measurement technology. To enforce the security policy. Yin proposed an application-aware IPsec policy system[4]. 2008. 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.2004 Heng Yin et al. Trusted Solaris [12] assigns a label to each virtual OS to enable multi-level security. Takuya Mishina. SMR translates a node specific message (e. MAC policy) into interoperable messages and performs routing between virtual user environments. http://www. and it constructs a private network by encrypting the communication channel. “Bridging the Gap Between Inter-communication Boundary and Internal Trusted Components”. our approach leverages a public service to reduce the cost and supports the condition and obligation for secure communication using the service.com/enterprise/cache/48 852-0-0-225-121. RELATED WORK 6. Gasmi has proposed the Enterprise Rights Management (ERM) system on TVD (ERM-TVD)[8]. et al. proposed a Trusted Virtual Domain (TVD) [1] based on access control between trusted resources. These VPN approaches focus on document sharing within a single organization. . Sanehiro Furuichi. However. Application-Level Distributed Coalition (ALDC) [13] enforces Chinese wall policy using application programming interface (API) hooking. We implemented the policy management component and the policy enforcer. Only the authenticated resource can join the TVD. 2004. Volume 11 . and the user can safely share the project content in the TVD. Datenschutz und Datensicherheit (DUD) 9/2004. and Hiroshi Maruyama. The CoVD monitors document exchange. volume 4189. and enforces obligations according to project policies. Issue 1. Vol 15. [11] HP NetTop. as described in 2. ACM Transactions on Information and System Security.www7. pp. Watanabe et al. checks conditions. 8.4. “Chinese-wall process confinement for practical distributed coalitions”.Open Trusted Computing for You and Me”. the system translates the application security policy into the IP sec policy and establishes IPsec communication channel for each application. http://h71028. “Attestation-based Policy Enforcement for Remote Access”. SACMAT '07 12 . while we focus on cross organizational document sharing. and it is implemented on Xen. To create a strong quarantine network. Sachiko Yoshihama. CONCLUSION In this paper we proposed a method of constructing Content Oriented Virtual Domains. “European Multilateral Secure Computing Base .1 VPN based approach Virtual Private Network (VPN) is a kind of overlay network.