Virtualization Based Security Tools

This is a Request For Information (RFI), to gain knowledge of interest and capabilities virtualization-based security solutions. THIS IS NOT A SOLICITATION FOR PROPOSALS. The Government DOES NOT intend to award a contract on the basis of the responses to this RFI. No reimbursement will be made for any costs associated with providing information in response to this synopsis or any follow-up information requests. This RFI is for planning purposes only and to gain knowledge regarding current capabilities with respecto to virtualization-based security solutions. Responses to this RFI will not be returned. Information received in response to this RFI may be used to assess alternatives available in determining how to proceed in future acquisitions, and members of the Defense Industrial Base (DIB) technology and architecture may follow up to learn more about submissions of interest. The DIB Task Force Technology and Architecture group is a joint industry/government team. Not responding to the RFI does not preclude participation in any future RFP. If a solicitation is released, it will be issued via the Federal Business Opportunities website (www.fbo.gov). It is the responsibility of the potential offerors to monitor this website for any information that may pertain to this RFI. The information provided in this RFI is subject to change and is not binding on the Government. (a) The Government does not intend to award a contract on the basis of this solicitation or to otherwise pay for the information solicited except as an allowable cost under other contracts as provided in subsection 31.205-18, Bid and proposal costs, of the Federal Acquisition Regulation (FAR). (b) Although - proposal, - contractor, and - offeror are used in this Request for Information, your response will be treated as information only. It shall not be used as a proposal. (c) This solicitation is issued for the purpose of gaining information to be used in determining the scope of future Virtualization-Based Security Tools contracts. This RFI is a part of Market Research in accordance with FAR Part 10, FAR 12.101 and FAR 12.202. Any proprietary information submitted in response to this RFI, if marked with a restrictive legend, will not be disclosed outside the Government or its support contractors except with the permission of the responder. If proprietary information is included in the response, please indicate whether it may be shown to the DIB members of the Technology and Architecture group, which includes both Government and industry partners. 1.0 Background In August 2007, the Deputy Secretary of Defense directed the Assistant Secretary of Defense for Networks and Information Integration and DoD Chief Information Officer (ASD(NII/DoD CIO)) to develop and implement a comprehensive approach for safeguarding DoD unclassified information concerning weapons systems, technology, and combat capabilities when it resides on DIB unclassified networks. To facilitate this effort, the Defense Industrial Base Cyber Security/ Information Assurance Task Force (DIB CS/IA TF) was established to work with DIB partners and DoD components to develop the processes and capabilities needed to secure this information from sophisticated adversaries. In particular, a technology and architecture team comprising DIB and Government technical experts was chartered to investigate innovative, future-looking approaches to today's problems. 1.1 Intent of the RFI It is the intent of the ASD(NII/DOD) CIO office to use this market research to explore the feasibility and maturity of virtualization-based security solutions and identify organizations which have plans to or experience in providing them. The DIB Task Force will consider whether this approach has promise for protecting DoD unclassified information on DIB networks. Specifically, the DIB Task Force is interested in exploring the availability of virtualization-based commercial solutions for the following problems in network security.: 1) Network hygiene provisioning via virtual infrastructure; 2a) Reduced-risk Internet exposure via virtual machines; 2b) Creation of a trusted enclave via virtual machines; 3) Employer-subsidized computers replacing employer-supplied computers. The technology and architecture team will use these RFI responses to gauge the maturity of virtualization as an approach and the capabilities of specific companies to provide solutions. 2.0 Information Requested 2.1 Descriptions of the problems and exemplary use cases follow below: 1) Network Provisioning: The large number of components in and resultant complexity of today's network topologies make it difficult to determine the security posture of a network, much less maintain it in a desired state. Request #1 asks for solutions using virtualization to centrally create and manage images of controlled state and use them to rapidly provision network components. Questions/Discussion: Today configuration management of network components is generally performed case-by-case, scanning components for current state and applying patches, new settings, etc to bring the component into compliance with the desired new state. The configuration management controls operate under control of the operating system being managed. With the decoupling of logical and physical aspects of many network components (servers, hosts, others?) now possible through virtualization, can we now think about replacing piecemeal configuration of guest environments with updated images? Specific issues to address: - How often to refresh? Refresh as prophylactic. - Relationship to Security Content Automation Protocol (SCAP) (see http://scap.nist.gov/ for more information). - Do you have a solution or a tool that works this way? Please describe. 2) The attack surface of modern operating systems and many applications is too large to effectively secure. It may be that the era of monolithic general purpose operating systems is nearing its end and could be replaced by a cluster of modules or virtual appliances acting in concert to perform services traditionally supplied by operating systems. Two such components, based on virtual machine technology, are described below. The first is designed for isolating risky environments to support safe Internet access and the other for isolating sensitive activity. It may be that the operating system of the future will consist of one or more of each of these components along with components yet to be described. 2a) Reduce exposure: Many of today's attacks come in through the browser or email. Some are blatant, where the user is tricked into downloading and opening a file containing malware which then installs itself on the host; other less so, exploiting flaws in the browser to allow the malicious agent through. Either way, it seems clear that isolating risky activities like browsing and email in a non-persistent virtual machine separate from the user's mission environment would make us safer, yet we are mostly not doing that. Specific issues to address: - What, if anything, is missing from making this a common approach? - How should session persistence, like bookmarks, be managed? - What might need to be done to support the selective movement of information from the safe browsing environment into the user's environment? - Do you have a solution or a tool to meet this need? What are the limitations of your tool and why do you think it is safe? 2b) Trusted Enclave: This enclave would be used for performing sensitive operations or handling sensitive information. Virtual machines (VMs) supporting this capability could be provisioned independent of the host operating system and refreshed from trusted sources when enough risk has accumulated to justify doing so. One way to do this is a - hot spares approach: provision duplicated VMs, load the application into the first one and migrate it to the second one after a certain level of risk has been reached. The first one would then be refreshed from an immutable source and when the second one has reached a risky state the process would be reversed. This could be done monolithically or surgically. Specific issues to address: - How do you move useful information between this enclave and the outside world? - What's the potential to securely connect this environment to that described above (Case 2) without communicating malicious agents? - How do you measure the level of corruption in the enclave? - What triggers the switch? - Can the VMs be seamlessly migrated back and forth? - Is it all or nothing, or can environments themselves be partitioned? - There are a number of standards and APIs which are emerging in Virtual Machine Management, Virtual Machine Control and Virtual Machine Format. Which standards do you support and which task force or standards body (IETF, DMTF, ISO, ) do you expect these standards to emerge from? 2c) Whose laptop?: It is becoming more common in businesses to replace company provided/company managed laptops with company subsidized employee purchases. One such initiative is described at http://money.cnn.com/2009/04/13/technology/fortt_choice.fortune/index.htm. In this example, the employee owns the platform and provides the local administration. The company supports remote access for the employee by supplying a managed corporate image authorized to connect to its network. Questions/Discussion: In the never ending effort to streamline costs, some in corporate America are changing how employee IT is provided. Instead of providing and managing a complete package of hardware and software for each worker, they are subsidizing the hardware and managing the software image which connect that hardware into the corporate network. These solutions may use virtualization to separate the corporate image from the user's image; they may use remote display technology to centrally maintain the corporate image. The remote connection must be protected from the device connecting into it. Specific issues to address: - What solutions are available that effectively protect a corporate managed image on an unmanaged platform? - Are there remote attestation mechanisms to provide evidence to the corporate network that the connection should be allowed? 3.0 Instructions for Responses to this Request for Information (RFI) a. Firms should respond to this Request for Information by addressing the topics listed above. The total page number should not exceed thirty (30) pages. Topic areas should be consolidated when practical, to follow the topic areas noted in section 2.0. Only attach MS Word/Excel compatible files or Adobe Acrobat PDF files in electronic correspondence. WHS will not acknowledge receipt of responses to this RFI. Please note that the DIB Task Force Technology and Architecture group is a joint industry/government team. Responses to the RFI will be made available to both government and industry members unless marked with special handling instructions indicating otherwise. We, however, recommend that responses be written so that they are releasable to DIB partners. Follow-up could then be done under an NDA if necessary. b. All responses should be submitted via e-mail address to kellie.buck.ctr@whs.mil or thomas.bordone@whs.mil. no later than 2:00 PM on July 20th, 2009. c. Points of Contact: Kellie Buck, Contract Specialist/Contractor, Phone 703-588-1329, Fax 703-588-1990, Thomas Bordone, Contracting Officer, Phone 703-588-1109, Fax 703-588-1990.