Host Based Security System (HBSS) Open Architecture Capability

Request for Information (RFI) for a Host Based Security System (HBSS) Open Architecture Capability Contracting Office Address: Defense Information Systems Agency, Acquisition Directorate, DITCO-Scott, P.O. 2300 East Drive, Bldg 3600, Scott AFB, IL, 62225-5406 Description: This is a Request for Information (RFI) for a Host Based Security System (HBSS) Open Architecture Capability. THE GOVERNMENT DOES NOT INTEND TO AWARD A CONTRACT ON THE BASIS OF THIS RFI OR OTHERWISE PAY FOR INFORMATION RECEIVED IN RESPONSE TO THE RFI. This RFI is issued for information and planning purposes only and does not constitute a solicitation. All information received in response to the RFI that is marked Proprietary will be handled accordingly. The Government shall not be liable for or suffer any consequential damages for any proprietary information not properly identified. Proprietary information will be safeguarded in accordance with the applicable Government regulations. Responses to the RFI will not be returned nor will the Government confirm receipt of the RFI response. Whatever information is provided in response to this RFI will be used to assess tradeoffs and alternatives available for determining how to proceed in the acquisition process. In accordance with FAR 15.201(e), responses to this RFI are not offers and cannot be accepted by the Government to form a binding contract. The purpose of this Request for Information (RFI) is to perform market research from public and private industries on the availability and maturity of a non-developmental Host Based Security System (HBSS) Open Architecture capability. Non-developmental is defined as software distributions that are considered to be in the "General Available" phase of a software release life cycle (i.e. Pre-alpha, Alpha, Beta, Release Candidate, Release To Manufacture (RTM), General Available (GA)). For the purposes of this RFI, non-developmental includes: Commercial off-the-Shelf (COTS); Government off-the-Shelf (GOTS); and Open Source Solutions that leverage existing standards. Non-developmental software can be tailored through scripting and configuration changes to meet unique requirements of the local operational environment, but there should not be extensive code changes (i.e. Government unique GA that is not applicable in the commercial industry). If the Government determines that GA solutions are not available, the Government will seek a GOTS developmental effort. Sources Sought: This Sources Sought Synopsis is requesting responses to the following criteria from all sources. Please note that personnel with current DoD Secret clearances (minimum) and specific personnel with current DoD Top Secret clearance will be required at contract award. Responses must demonstrate the company's ability to perform in accordance with the Limitations on Subcontracting clause (FAR 52.219-14). Late responses will not be considered. Responses should provide the business's DUNS number and CAGE code. Additionally, responses should include recent (within the past three years or work that is on-going) and relevant experience (work similar in type, scope, and complexity) to include contract numbers, project titles, dollar amounts, and points of contact with telephone numbers where the responder performed the relevant work. Provide a list of the current contract vehicles your services may be procured from, to include the General Service Administration (GSA), Federal Supply Schedule (FSS) and any other government contract vehicle. Marketing brochures and/or generic company literature will not be considered. Not addressing all the requested information may result in the Government determining the responder is not capable of performing the scope of work required. Background: Currently, network security implementation is to use a variety of agents installed on host machines, including agents for Anti-Virus (AV), Anti-Spyware (AS), Host Intrusion Prevention System (HIPS), Network Access Control (NAC), rootkit detection, device control, configuration auditing, configuration management, and patch management. To simplify the task of managing these agents and the policies and behaviors applied through these agents, security software vendors have recently started packaging these capabilities to utilize Common Management Frameworks (e.g. McAfee ePO is the common management framework that manages McAfee AV, AS, HIPS, etc). This framework provides a system administrator improved network operations efficiency and a cyber commander consolidated situational awareness of all agents on a host from one management console instead of an individual console for each agent. While this Common Management Framework (CMF) has reduced the level of resources required to manage a portfolio of security agents, it reduces the freedom of organizations to select "best of breed" security products to address individual requirements for specific host-based agents-decisions instead are based on whether a vendor is integrated into the current management framework or which vendor is best integrated. For example: There are many different vendors' Anti-Virus (AV) solutions out in the market place. Most vendors' AV products are based on propriety agent-server architectures. The AV agent is installed on a host machine and communicates to a server to obtain the latest definition update. A different vendor's AV agent would not be able to communicate with and be managed by a different vendor's AV server. This poses several challenges to a large enterprise such as the DoD, of which smaller components have unique operational requirements that a single vendor AV solution cannot optimally fulfill. To address these limitations, some integrated solution vendors have started to work with other security companies to integrate other vendors products, or have created integration programs to allow other vendors to integrate products into their proprietary framework. While this has improved the marketplace, integrated solution vendors still have an upper hand as they control the level of supported integration, reserving access to some framework features for their own products; furthermore, integrated solution vendors can control access to framework integration by charging fees for licensing or integration testing. In addition, frameworks can limit the functionality of the agents attached to them. DISA currently has an HBSS solution that includes a variety of host-based security capabilities. The current capability is provided by McAfee with a proprietary framework and integrated capabilities. The goal of this RFI is to determine the feasibility of a future acquisition of an "Open Architecture" framework for host-based security solutions. Desired Capability: The Government's desired capability is an HBSS open architecture solution that is available to all vendors and capability developers, that would promote a competitive, level marketplace for individual host-based security products. This would allow individual host-based security capabilities to be independently developed or acquired, but seamlessly integrated into an open framework with minimum to zero modification. The Government would like industry to provide innovative and cost effective alternatives. The Government envisions solutions taking the form of an existing architecture for system management; or host security with an unrestricted Application Program Interface (API) for integration; a set of standards for consolidated management of independent host security tools; an open source management framework; or any other solution that provides consolidated management of host security tools. Critical requirements of a HBSS open architecture solution would include: A common interface for installing and uninstalling host-based security agents A common interface for managing and applying security policies of security agents in a hierarchical architecture; however, not necessarily a common nomenclature, format, or definition of a "policy" A common mechanism for host to server communication A common mechanism for reporting security agent results, status, and other information in a multi-tiered hierarchical architecture The use of industry-defined data standards and protocols where appropriate Requested Information: This outline is intended to minimize the effort of the respondent and structure the responses for ease of analysis by the government. Respondents are free to develop their response accordingly, but should answer the fundamental questions asked to help the government analyze and understand the proposed solution. Vendor Solution (limited to 25 pages, including diagrams and spreadsheets) Please provide information/whitepaper(s)/answers to the below questions. PDF format is preferred for electronic submissions. 2.1.1 Describe any existing open architecture solution that you as a company have developed that have potential to meet the desired HBSS Open Architecture capabilities. 2.1.2 Has this solution been applied to the computer security commercial marketplace or any marketplace? 2.1.3 Describe any capabilities (control, reporting, deployment, etc) that are inherent or part of your open architecture solution? 2.1.4 What restrictions if any are placed on module/agent developers (technical or business)? 2.1.5 What is the model for updating the open architecture? 2.1.6 What licensing model is used for the product? Are there ENTERPRISE license provisions? 2.1.7 Describe your current pricing model. If available, provide DoD Enterprise (unlimited use) pricing. Do you have pricing available on existing vehicles (GSA, DISA or DoD IDIQ, etc.)? 2.1.8 Has this product been successfully deployed and partially/fully functional anywhere within the DoD? If yes, where? Please provide the Government point of contract. 2.1.9 What if any standards (Industry, academia, government, etc) were used in the development of the open architecture? 2.1.10 Describe any open architecture products that you as a company are working on but have not deployed, that have potential to meet the desired HBSS Open Architecture capabilities. What is the roadmap on software release life cycle? 2.1.11 What are the advantages and disadvantages of your solution when compared to other potential solutions (e.g. single vendor, small business, GOTS, vendor consortium, standards organization, open source)? 2.1.12 If you do not have a solution or have only a partial solution, are you interested in an open source development/consortium? Please explain how your company could play a part or contribute to such an effort. Additional Information (limited to 4 pages, including diagrams and spreadsheets) Provide any other materials, suggestions, and discussions deemed appropriate to help the government analyze market maturity and viability of an HBSS Open Architecture capability. 2.2.1 Responses should include the (1) business name and address and (2) name of company representative and their business title. 2.2.2 Describe any of the company's current open architecture implementations, including management and operational approach, requirements, processes, and any relevant lessons learned. List major government and commercial clients. Responses: Firms who wish to respond to this should send responses via email by COB 07 June 2010. The response should not exceed a 5 MB mail limit for all items associated with the RFI response. Interested vendors should forward their capabilities and other information to be considered to PEO_IANACQUISITION@disa.mil. Proprietary information and trade secrets, if any, must be clearly marked on all materials. All information received that is marked Proprietary will be handled accordingly. Please be advised that all submissions become Government property and will not be returned. All government and contractor personal reviewing RFI responses will have signed non-disclosure agreements and understand their responsibility for proper use and protection from unauthorized disclosure of proprietary information as described 41 USC 423. The Government shall not be held liable for any damages incurred if proprietary information is not properly identified Points Of Contact: All inquires and questions related to this RFI should be sent to the following Points of Contact: Diane Phan, HBSS Open Architecture PM, 301-677-4463, diane.phan@disa.mil.