SOLICITATION NOTICE
D -- "RECOVERY" D--Market Research - RFI for End to End CM
- Notice Date
- 3/12/2010
- Notice Type
- Presolicitation
- NAICS
- 541519
— Other Computer Related Services
- Contracting Office
- U.S. Department of State, FedBid.com -- for Department of State procurements only., FedBid.com, 2010 Corporate Ridge, Suite 750, McLean, Virginia, 22102
- ZIP Code
- 22102
- Solicitation Number
- 101903B035
- Archive Date
- 9/12/2010
- Point of Contact
- Lawanna A. Manning, Phone: 7038756069
- E-Mail Address
-
manninglr@state.gov
(manninglr@state.gov)
- Small Business Set-Aside
- N/A
- Description
- "THIS NOTICE IS PROVIDED FOR INFORMATION PROPOSES ONLY. THIS OPPORTUNITY IS AVALIABLE ONLY TO CONTRACTORS UNDER GSA FEDERAL SUPPLY SERVICES SCHEDULE HOLDERS" In compliance with the transparency and accountability requrirements associated with the supplemental appripriations provided by the American Recovery and Re-investment Act of 2009, Pub.L. 111-5. DESCRIPTION: The Department of State (DoS) is performing market research to determine industry interest and capabilities for implementing an End-to-End Configuration Management (EECM) solution for the Department’s Sensitive But Unclassified network called OpenNet. Specifically, this EECM capability shall provide remediation and centralized configuration management for enterprise workstations and servers to better protect OpenNet against cyber threats (i.e., refer to the “INTRODUCTION” section below for additional details). This is a Request for Information (RFI) announcement only. This is not a solicitation or request for proposal and in no way commits the Government to award a contract. The Government does not intend to award a contract(s) based solely on the submissions of this RFI, nor does it intend to pay for any costs incurred in response to this announcement. This RFI is solely intended for information and planning purposes and does not constitute a solicitation. Responses to this notice are not offers and cannot be accepted by the Government to form a binding contract. Respondents are solely responsible for expenses associated with this RFI. Respondents will not be notified of the result of the review. MARKET RESEARCH – REQUEST FOR INFORMATION (Capability Statement) Instructions: 1. The Request for Information (Capability Statement) response should be concise and focused and not exceed ten (10) pages including cover pages, table of contents etc. 2. Sale brochures, videos, and other marketing information materials are not solicited and will not be reviewed. 3. Do not submit cost or price information with the response. 4. Interested companies shall submit an electronic copy of their capability statements via email to (INSERT Contracting Officer’s Name and E-mail address). The due date and time for submission of responses is (INSERT time and Due date – 10 days after posting to FedBiz Ops) 5. No phone calls related to this Request for Information will be accepted. All correspondence shall be via email. An interested party should be able to demonstrate, in any capability statements submitted, experience with program engineering, production control and delivery of modernized information technology systems. DoS may award one or more contracts to have access to the full range of expertise required. Experience may include: both government and commercial work that the offeror has performed. Demonstrated evidence may include, but not be limited to customer names and addresses, description of work performed/delivered, description of types/complexity of systems worked on, description of strategies to accomplish the work, description of communication strategies with the customer, and significant accounting and information technology issues resolved. Interested parties should be able to demonstrate their ability to perform these evaluations with only personnel that are U.S. citizens. Finally, offerors should include an analytical comparison (in the form of a WORD matrix) of their capability in terms of the services requested in this RFI. All vendors with an appropriate product addressing the requirements set forth in the “INTRODUCTION” section are invited to submit a Capability Statement and contact information. The Capability Statement should discuss the product’s capabilities relative to the stated requirements, as well as, the product’s requirements and any other pertinent information that would enhance the understanding of the proposed EECM system. Include a brief description of the respondent’s past experience providing similar services/supplies including the number of systems sold. Additionally, respondents must have been in business supplying government customers not less than five years. Vendors must have a GSA schedule and should provide the contract number of that schedule. Any proprietary information contained in the capability statement must be marked accordingly. Interested sources may submit brief capability statements signed by a corporate official with authority to bind the company and verify that the company can provide a solution to the specifications identified herein. CONTENT: Company and Contact Information: 1. Company Name and Address; 2. Contact Name, Title, Phone Number, Fax Number, and e-Mail Address; 3. Organizational history and capabilities statement; 4. Geographic location(s) of office(s) and number of employees at each domestic and international location; 5. Current Facility Clearance Level; 6. General Services Administration (GSA) Schedule Contract Number(s); and 7. GSA Government-Wide Acquisition Contract Family and Number(s). INTRODUCTION The U.S. Department of State is seeking information and supply sources capable of providing an EECM capability from Commercial-Off-The-Shelf (COTS) sources. The candidate EECM solution must meet the following requirements: Basic Requirements 1. The system shall enforce a "default" policy if an endpoint posture assessment is "unknown" or "can't be determined 2. The system shall integrate with and make use of PKI or Kerberos enabled networks 3. The system shall leverage existing authentication databases, such as Active Directory, RADIUS, or LDAP using pass-through authentication 4. The system should provide a means of using the TPM for device authentication or reading produced and/or producing the TPM credentials for third party usage 5. The system shall support wired network end-users 6. The system supports VPN/Remote/WAN users and devices 7. The system supports both agent and agentless hosts 8. The system supports Single Sign On to Active Directory 9. The system supports Single Sign On for VPN users 10. The system supports native, Active X, and Web (HTML) client interfaces 11. The system's native client agent supports DoS approved OSs 12. The system's native agent allows customizable end-user messages Configuration Policy Compliance Requirements 1. The system shall be able to obtain information natively or from third party data sources to determine device configuration status 2. The system shall allow NAC policy compliance information to be retrieved from the device using a standardized communication method such as an Application Programming Interface (API) or other standards based mechanism 3. The system shall have the ability to be configured to obtain software updates/patches/SOE image from trusted DoS servers 4. The system shall have the configurable capability to log events 5. The system shall have the ability to be configured to log (i.e., audit mode), but not enforce NAC policies 6. The system implements a "test mode" that provides alerting or logging to prove accuracy of a NAC policy 7. The system shall provide the capability to either turn-off, or customize NAC-EECM functionality to troubleshoot problems without affecting normal network operations 8. The system shall allow end-users to receive information on a device's NAC status Network Trust Zone (VLAN) Requirements 1. The system provides quarantine functionality in the network 2. The system provides provisioning functionality in the network 3. The system shall provide remediation services for non-compliant hosts while quarantined 4. The system shall identify and provide remediation support for common DoS applications 5. The System shall update automatically to become aware of new versions of data files of common DoS applications 6. The system shall allow for secure and automated remediation using native or third party remediation software 7. The system shall support custom remediation scripts 8. The system shall allow for different remediation processes based on user role 9. The system's agent steps end-users through a SELF-REMEDIATION process if the host is not compliant using a GUI Functional Requirements 1. The solution shall operate in low bandwidth and small posts with austere/remote environments 2. The system shall be compliant with the IETF/IEEE open Network Endpoint Assessment (NEA) architecture and standards as they evolve 3. The system shall use a standards-based language/protocol to communicate policies or, if standards are not available, will provide its native language to the Government in an open-source document 4. The system must not hinder or interfere with the operation of the DoS CAC system 5. The system shall be able to employ Network Time Protocol (NTP) 6. The system shall not interfere with the operation of the Department's approved anti-virus and endpoint security solutions 7. The system shall not interfere with the Department's authorized patching and software updating/upgrading solutions 8. The system shall be Internet Protocol Version 6 (IPv6) capable 9. The system shall not significantly impact network throughput 10. The system shall not depend on a client/agent for authentication or policy compliance 11. The system must be FIPS 140-2, Level II certified 12. The system must (or able to) be on the Department's approved ITCCB Product List 13. The system must include a timely, automated, centrally managed software update and workflow process/cycle that has a minimum impact on current operations 14. The system's installed client minimizes device footprint and resource utilization at the endpoint Security Requirements 1. The system shall prevent man-in-the-middle and replay attacks 2. The system provides the ability to perform endpoint quarantine if suspicious activity occurs AFTER a system has been given access to the network Performance Requirements 1. The system shall be capable of automatic failover to backup systems 2. The system shall have the capability for manual, and optionally, automatic, recovery from failed operations to return to normal settings, operations, systems, to include log merging 3. The system shall enable the failover criteria to be configurable 4. "The system shall able to run on the Department's global network continuously with minimal impact on the end-user’s mission. The solution shall be minimally disruptive to the operational environment 5. The system shall not interfere with the subject's productivity, or system usability and functionality, shall provide minimum degradation on Central Processing Unit (CPU) performance, shall provide minimum degradation on input-output (IO) performance, and shall provide minimum degradation on network accessibility 6. The solution shall support all endpoints 7. The solution shall be easy to implement, maintain, and easy to operate Integration Requirements 1. The system shall integrate with DoS existing or future enterprise patch management solutions 2. The system shall integrate with DoS existing or future enterprise vulnerability management solutions 3. The system shall integrate with DoS existing or future configuration management solutions 4. The system shall integrate with DOS existing or future endpoint security solutions Deployment Mode Requirements 1. The system supports mixed deployments (decentralized & centralized) 2. The system supports redundant/high availability configurations 3. The system supports BOTH NAC agent client and clientless modes 4. The system supports NAC via a "transient" agent 5. The system supports a NAC "beacon" profiler for endpoint device discovery, device inventory, and classification Management Requirements 1. The system shall provide queue events when communication is lost 2. The system shall be capable of reporting alerts to multiple management consoles for all administratively specified events 3. The system shall provide detailed logs of all administratively specified events 4. The system shall have the ability to time-stamp all events using Greenwich Mean Time (GMT), to include log data, in a consistent frame of reference 5. The system shall enable administrators to define the particulars of operational data collection and storage. These shall include the intervals of data collection and the specific data to be collected 6. The system shall support a manager of managers concept of operations where individual managers can support large numbers of multiple managed elements 7. The system shall support a role-based management structure where users/operators are assigned permissions for limited control of the system 8. The system shall provide a web-based management interface to support remote administration 9. The system shall provide an easy-to-use graphical user interface (GUI) that contains status and logging information, as well as controls for modifying policies and managing devices 10. The system shall aggregate/fuse similar events into a single event record/report 11. The system shall allow configurable reporting to control how and when reports are generated, based on administrator-selected attributes/thresholds 12. The solution provides for custom generation of reports and queries 13. The system supports the export of report data in standardized formats 14. The system provides automated, formatted datafeeds to other Department enterprise tool suites 15. The system supports the sharing of data from the Department's enterprise security tool suites 16. The system supports the import of custom checklists and policies using INF, XML, OVAL or XCCDF formats, etc. 17. The system supports pre-defined benchmarks for federal and Department regulatory reporting 18. The system supports the backup and recovery of policies/configurations 19. The system shall provide in-depth, detailed information about any monitored asset, service, or function depicted on the GUI. This enables the ability to drill-down on any graphical representation (e.g., icon) to obtain specific relevant detailed information regarding its status. Clauses: 52.203-15 Whistleblower Protections Under the American Recovery and Reinvestment Act of 2009 (MAR 2009); 52.204-11 American Recovery and Reinvestment Act-Reporting Requirements (Mar 2009); 52.212-5 Contract Erms and Conditions Required to Implement Statutes or Executive Orders – Commercial Items (Apr 2009) – (Alternate II – Mar 2009).
- Web Link
-
FBO.gov Permalink
(https://www.fbo.gov/spg/State/FedBid.com/FedBid1/101903B035/listing.html)
- Record
- SN02091341-W 20100314/100312235928-13ca04e92c4ff87c9c7742d8f2bf9f77 (fbodaily.com)
- Source
-
FedBizOpps Link to This Notice
(may not be valid after Archive Date)
| FSG Index | This Issue's Index | Today's FBO Daily Index Page |