MODIFICATION
D -- Request for Information (RFI) for an Information Assurance Vulnerability Management (IAVM) DoD-Wide Enterprise License
- Notice Date
- 11/25/2003
- Notice Type
- Modification
- Contracting Office
- Defense Information Systems Agency, Acquisition Directorate, DITCO-Scott, 2300 East Drive Bldg 3600, Scott AFB, IL, 62225-5406
- ZIP Code
- 62225-5406
- Solicitation Number
- Reference-Number-RFI201
- Response Due
- 12/5/2003
- Archive Date
- 12/20/2003
- Point of Contact
- Anne Keller, Contract Specialist, Phone 618-229-9504, Fax 618-229-9440, - Karen Kincaid, Contract Specialist, Phone 618-229-9707, Fax 618-229-9508,
- E-Mail Address
-
kellera@scott.disa.mil, kincaidk@scott.disa.mil
- Description
- D--Request for Information (RFI) for an Information Assurance Vulnerability Management (IAVM) DoD-wide Enterprise License SUBJECT This document is a Request for Information (RFI) for an Information Assurance Vulnerability Management (IAVM) enterprise-wide capability designed to resolve the vulnerability management issues and configuration management concerns across the Department of Defense (DoD). This capability should address the following vulnerability processes: (1) assessment, (2) compliance, (3) reporting, and (4) remediation. Responses are due to this RFI by 16:00 hrs Eastern Standard Time (EST) on 5 December 2003. DESCRIPTION The Defense Information Systems Agency (DISA), at the request of the United States Strategic Command (USSTRATCOM) and in support of National Security goals established by the President, is seeking information from industry that will assist in the development and deployment of an Information Assurance Vulnerability Management (IAVM) enterprise-wide capability across the Department of Defense (DoD). This capability should fully integrate Information Assurance Vulnerability Alert (IAVA) vulnerability identification, verification, reporting, and remediation, while providing a cost effective training method to employ the technology. Emphasis should include the capability to employ these tools in all operating environments, such as specified in the Defense Information Infrastructure / Common Operating Environment (DII COE). Specifically, this RFI seeks the following information: ?Description of a conceptual architecture to include logistical tail requirements such as training, maintenance, installation, technical support ?Technical feasibility assessments ?Approximate cost information (i.e., order of magnitude, ballpark estimates, etc.) for core architecture and possible alternatives ?Schedule estimates (capability ready for deployment) ?Ideas and suggestions that provide alternative approaches to designing, developing, acquiring, deploying and managing this IAVM solution ACQUISITION STRATEGY While the government is soliciting information from all of industry, the government intends to satisfy this requirement by placing a task order under an existing multiple award ID/IQ contract. The existing contract the Government intends to use is the Information Assurance (IASSURE) contracts. Information on this contract, including contract terms and conditions, ordering procedures and prime contractors can be found at http://www.disa.mil/acq/contracts/iachar.html. The IASSURE contract has 11 prime contractors and has the flexibility of prime contractors being able to add subcontractors to their team at any time. Companies interested in becoming a subcontractor under the IASSURE contract should contact one of the 11 prime contractors directly. Point of contact for the companies can also be found on the above IASSURE website. REQUIREMENTS This section enumerates the basic minimum functional requirements for this IAVM capability. (1) Automated Vulnerability Identification and Reporting System Administrators (SA?s) must have tools that automate the tasks of asset identification, IAVA identification, and IAVA reporting. These tools must also provide the SA with step-by-step instructions appropriate for the platform to facilitate ease of installation and configuration operations. In addition, adequate help facilities (help pages) should be imbedded within the product to provide vulnerability information concerning the tasks above and possible remediation techniques. Tool should have a remote management capability. Having the above capabilities would greatly reduce the burden placed upon SA?s. Tools for asset identification, IAVA identification, and IAVA reporting should also be able to run on ?Microsoft, major Unix based, Linux, and Cisco operating systems and should be able to scan Nortel, Foundry, Enterasys, Cabletron, and Marconi network infrastructure devices?. New vulnerabilities surface on a regular basis and these tools must keep abreast of these changes. New vulnerability alerts must be continually updated to be able to validate the solutions and links required for remediation of all vulnerabilities. All DoD IAVAs are currently stored in a vulnerability database, and new ones are added as they are released. Storage of all information in an SQL-addressable database should be supported and allow direct custom queries, or export / linking capability to other databases. Reports should be available on any machine with a DoD approved web browser. These tools should include differential reporting capabilities based on host or vulnerability with customizable scans for IAVA compliance and service configurable scans. Tool should also have a hierarchical reporting capability. Department of Defense (DoD) Information Assurance Vulnerability Alerts (IAVAs) are only available to .mil sites and not the commercial marketplace. The IAVM tools must be able to be configured to check for updates over the network every time they are run. In addition to adding vulnerability checks, the tools should validate the solutions and links provided in the screens and reports of the product with each update, minimizing the possibility that the user may encounter a broken link. These tools should also include the ability to identify vulnerabilities associated with Routers, Switches and network printers. Differential reporting capabilities based on Host or Vulnerability should be included. (2) Vulnerability Remediation A key consideration in this IAVM capability is that your proposed suite of vulnerability assessment, compliance and tracking tools must be interoperable with multiple remediation tools. These remediation tools should support the largest number of possible operating systems and applications that DoD uses. Based on the product you propose please identify the remediation tools in which your product is interoperable. (3) Field Proven Tools Scanning for vulnerabilities must quickly determine IAVA compliance on a network. Coupled with a central reporting capability, an enterprise solution should provide an effective means to enforce IAVA compliance. Any selected vulnerability discovery tool at the SA level should be able to be utilized ?under? the security routers in an organization's top-level architecture as well as within smaller enclaves that may be protected by firewalls and other security devices that are part of the DoD defense-in-depth posture. Enterprise tools must work in deployable, tactical, and isolated units in remote theaters, with a small (e.g., 256 KBps) satellite link with up to 600ms delay. (4) Non-Disruptive to Normal Operations These IAVM tools must be able to be run on live networks during normal operating hours without affecting the user's mission. These tools must be able to be used during normal operating hours so there is no need to scan at night while users are away and there is a worry about machines being turned off during off-duty hours. Basically these tools should not be disruptive to the operating environment. (5) Accountability and Enforcement Requirement for this part of the IAVM capability should be that whenever a System Administrator performs a network IAVA scan, a status report should be sent to one or more enterprise IAVM data repositories. Examples of information that should be presented in the status report are as follows: (First and foremost is the IAVA compliance data on network assets within the System Administrator?s purview) ?The time and date the scan was performed should be available ?The version of the products used to perform the scan should be available The complete data set must also allow a Security Manager to monitor IAVA compliance by showing: ?If the System Administrator scanned his network ?When they scanned the network ?If the System Administrator scanned using the most up-to-date tool, and hence scanned for the most recent IAVAs ?What IAVAs are still outstanding? ?What IAVAs have been applied? (6) Training/Technical Support for IAVM Implementation Past experience within DoD deploying IA tools has proven that without training, a large percentage of tools remain ?on the shelf? and do not get used, resulting in a poor return on investment. In addition, most IAVM mechanisms are powerful tools that, if not properly employed, have the potential to harm a network with a single click. To provide tool and IAVA specific training on particularly complex IAVA ?fixes,? a capability must be provided for virtual, interactive, on-demand IA training to SAs from their duty location/organization computers. Students should be able to log into a ?virtual interactive classroom? using a number of teaching tools (e.g., streaming video/audio, online classroom chat, web boards, and virtual servers). Students should also be able to log into a virtual classroom from anywhere in the world. It is imperative that students should learn to run IAVM tools and do compliance reporting on a virtual network before ever touching their real network. This capability should compliment training presented at formal DoD IA training schools by training specific technical IAVA requirements. Whenever changes occur in the tools the training should be updated, reducing the lag time that now occurs in updating/improving individual technical skills. This capability should be available to the Government in the following: ?Availability of an enterprise license ?Availability of enterprise maintenance ?24 X 7 X 365 day technical support: Because this tool will be fielded world-wide please submit information on how you would provide technical support for both CONUS and OCONUS theaters and in multiple environments (i.e., Garrison environment, tactical environment, ships, aircrafts?etc) (7) Enterprising View of Vulnerabilities The Security Manager in an organization should be provided with an enterprise view of the DoD security posture. Query capabilities, such as ?Show me the status of an ?X IAVA on ?X platform?, should be provided within an enterprise view by the IAVM capability. The intent of the DoD network architecture should allow multiple IAVM tools to be deployed throughout the enterprise, while maintaining a central repository for vulnerability information. Communications to the central repository should be encrypted. In addition, all interactions with the enterprise database through the standard user interface should be encrypted. (8) National Information Assurance Partnership (NIAP) Certification Process This capability must have completed or initiated the NIAP Certification process (GOAL: Evaluation Assurance Level (EAL) 4 certification) SUMMARY The goal of this RFI is to seek information that will assist in the development and deployment of an IAVM enterprise-wide capability. This effort?s intent is to give DoD a tool suite to proactively, efficiently, and effectively manage their IAVM Program, which will reduce the workload on both system administrators (SA) and network managers (NM) alike. SAMPLE RESPONSE OUTLINE Following is a suggested outline and suggested page counts for a response to this RFI. This outline is intended to minimize the effort of the respondent(s) and structure the responses for ease of analysis by the government. Section 1 - Conceptual Technical Architecture ?Briefly describe your architectural concept and its corresponding logistical tail such as training, maintenance, installation, and technical support. Discuss the capability for the architecture to meet IAVM needs outside CONUS. (2 to 3 pages for architecture description and logistical tail with one diagram identifying the brand/type of equipment that would typically be deployed) Section 2 ? Technical Feasibility Assessment Briefly describe the technical feasibility of your architecture and the design tradeoffs involved as matched against the functional requirements stated above. (1 page) Section 3 ? Cost and Schedule Estimates Provide cost estimates for the architecture developed. Also, discuss cost drivers, cost tradeoffs, and schedule considerations (2 pages) Section 4 ? Alternate Approaches Ideas and suggestions that provide alternative approaches to designing, developing, acquiring, deploying and managing this IAVM solution. Section 5 ? Corporate Expertise Briefly describe your company, your products and services, history, ownership, financial information, and other information you deem relevant. (no suggested page count) In particular, please describe any projects you have been involved in that are similar in concept to what is described in this RFI, including management and operations approach, security requirements, security assurance processes, and any relevant lessons learned (1 page per project). Section 6 ? Business Size Status Size standards define whether a business entity is small or large and thus eligible for Government programs and preferences reserved for ``small business'' concerns. Size standards have been established for types of economic activity, or industry, generally under the North American Industry Classification System (NAICS). Please identify size standard in this RFI so that you can appropriately represent yourself as either small or large. INFORMATION EXCHANGE MEETINGS DISA?s Chief Information Assurance Executive (CIAE) may hold an information exchange meeting to discuss this RFI with interested potential respondents. If you wish to request a meeting, please respond to the POCs provided in the contact information, below. DISCLAIMER THIS RFI IS NOT A REQUEST FOR PROPOSAL (RFP) AND IS NOT TO BE CONSTRUED AS A COMMITMENT BY THE GOVERNMENT TO ISSUE A SOLICITATION OR ULTIMATELY AWARD A CONTRACT. RESPONSES WILL NOT BE CONSIDERED AS PROPOSALS NOR WILL ANY AWARD BE MADE AS A RESULT OF THIS SYNOPSIS. All information contained in the RFI is preliminary as well as subject to modification and is in no way binding on the Government. FAR clause 52.215-3, Request for Information or Solicitation for Planning Purposes (Oct 1977), is incorporated by reference into this RFI. All information received in response to this RFI that is marked Proprietary will be handled accordingly. Responses to the RFI will not be returned. In accordance with FAR 15.202(e), responses to this notice are not offers and cannot be accepted by the Government to form a binding contract. Responders are solely responsible for all expenses associated with responding to this RFI. CONTACT INFORMATION Following is the Point of Contact(s) (POCs) for this RFI, including the information exchange meeting: Mr. Bill Keely Deputy Director, CIAE (703) 882-1502 keelyb@ncr.disa.mil MAJ Jeffrey Bruce Systems Officer (703) 882-1838 bruce2j@ncr.disa.mil Ms. Helena Robinson Systems Analyst (703) 882-1646 robinsoh@ncr.disa.mil Please submit responses via e-mail in Microsoft Office format by 16:00 PM Eastern Standard Time (EST) on 5 December 2003, to the POC at: bruce2j@ncr.disa.mil or robinsoh@ncr.disa.mil.
- Record
- SN00476493-W 20031127/031125211601 (fbodaily.com)
- Source
-
FedBizOpps.gov Link to This Notice
(may not be valid after Archive Date)
| FSG Index | This Issue's Index | Today's FBO Daily Index Page |