SOLICITATION NOTICE
D -- RECOVERY - D- Market Research - RFI Network Access Control
- 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
- 101903B036
- Archive Date
- 9/20/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 PURPOSES ONLY. THIS OPPORTUNITY IS AVALIABLE ONLY TO CONTRACTORS UNDER GSA FEDERAL SUPPLY SERVICES SCHEDULE HOLDERS". In compliance with the transparency and accountability requirements associated with the supplemental appropriations provided by the American Recovery and Re-investment Act of 2009, Pub.L.111-5. DESCRIPTION Department of State (DoS) is performing market research to determine industry interest and capabilities for implementing a Network Access Control (NAC) solution for OpenNet. Specifically, this capability shall provide OpenNet with new network access control capabilities including Secure Enclaves and 802.1x Port Security (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 intent 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 of their capability (in the form of a WORD matrix) 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 potential requirements, the product’s requirements and any other pertinent information that would enhance the understanding of a NAC system solution. Include a brief description of the respondent’s past experience providing similar services/supplies including the number of units 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 a NAC capability from Commercial-Off-The-Shelf (COTS) sources. The candidate NAC solution must meet the following requirements: Basic Requirements 1. The system provides user authentication and authorization to existing user database repositories. 2. The system supports multiple user roles and allows different admission policies to be applied to each role. 3. The system shall authenticate all (network enabled) devices before allowing access to the network. 4. The system shall support in-line blocking as an enforcement method if an endpoint device is in use. 5. The system shall deny access to devices that fail authentication. 6. The system shall enforce a "default" policy if an endpoint posture assessment is "unknown" or "can't be determined. 7. The system shall prevent unauthenticated devices from interacting with each other. 8. The system shall integrate with and make use of PKI or Kerberos enabled networks. 9. The system shall leverage existing authentication databases, such as Active Directory, RADIUS, or LDAP using pass-through authentication. 10. The solution must provide port-based access control in all environments. 11. The system shall allow an administrator to override the authentication assessment and allow or deny a device to enter the authorized network. 12. The system shall be able to detect the physical attachment of any device to the network. 13. The system shall provide the administrator a means of configuration of authorized MAC addresses for non-windows devices like VOIP phones and printers. 14. 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. 15. The system shall support wired network end-users 16. The system supports VPN/Remote/WAN users and devices. 17. The system supports both agent and agentless hosts 18. The system supports Single Sign On to Active Directory 19. The system supports Single Sign On for VPN users 20. The system supports native, Active X, and Web (HTML) client interfaces 21. The system's native client agent supports DoS approved OSs 22. The system's native agent DOES NOT make admission control decision if the endpoint host has been comprised or the native agent disabled 23. The system's native agent allows customizable end-user messages 24. The system shall support a common policy platform for all users 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 configuration policy compliant devices to connect to networks. Exceptions permitted under S1.7 and S2.5 of this document. 3. The system shall deny access to the network for devices that fail policy compliance. 4. The system shall limit network access to the remediation service if the device is out of compliance. 5. The system shall allow an administrator to override the configuration policy assessment and allow or deny a device to enter the network.. 6. The system shall allow security managers and administrators the ability to create, manipulate, and maintain multiple device NAC policies. 7. The system shall support a distributed NAC policy server architecture for enforcement, with the capability for centralized policy creation, distribution, management, data collection, auditing and reporting. 8. The system shall be capable of being configured for both distributed NAC policy and localized NAC policy enforcement administration. 9. 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. 10. The system shall have the ability to be configured to obtain software updates/patches/SOE image from trusted DoS servers. 11. The system shall have the configurable capability to log events. 12. The system shall have the ability to be configured to log (i.e., audit mode), but not enforce NAC policies. 13. The system implements a "test mode" that provides alerting or logging to prove accuracy of a NAC policy. 14. The system shall provide the capability to either turn-off, or customize NAC-EECM functionality to troubleshoot problems without affecting normal network operations. 15. The system shall allow end-users to receive information on a device's NAC status. 16. The system shall allow administrators to receive information on a device's NAC status. 17. The system shall be able to perform regular re-assessments of network devices with the ability to schedule by time or event. 18. The system's agent allows for the display of the Department's Acceptable Use Policy. Network Trust Zone (VLANs) 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 or 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 provides support for guest or visitor access. 8. The system can provide unique user credentials for each guest/visitor. 9. The system can provide start/stop access times for guest/visitor access. 10. The system provides support for Foreign Affairs Network (FAN) enclaves to include support for rendering identities from other federal agency AD or LDAP servers 11. The system can provide start/stop access times for guest/visitor access. 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 solution shall be infrastructure vendor agnostic and not require uniform router and/or switch restrictions. 13. The system must (or able to) be on the Department's approved ITCCB Product List. 14. The system must include a timely, automated, centrally managed software update and workflow process/cycle that has a minimum impact on current operations. 15. The system's installed client minimizes device footprint and resource utilization at the endpoint. 16. The system provides multiple enforcement methods simultaneously. 17. The system shall be compliant with the IEEE 802.1X standard Security Requirements 1. The system shall continue to operate in the face of Denial of Service attacks. 2. The system shall be able to fail open or fail closed, depending on configured policy. 3. The system shall prevent man-in-the-middle and replay attacks. 4. The solution shall protect against subversive network access activity that uses static IP or MAC address. 5. Manager to Manager and Manager to Managed items communications must be protected using SSL, SSH or FIPS approved algorithms. 6. The system shall mitigate attempts from non-windows devices like printers and VOIP phones which may attempt to circumvent the solution via unauthorized traffic through authorized ports. 7. The system shall mitigate all attempts at circumventing the NAC device authentication, remediation and compliance policies via connection sharing, port forwarding or network address translation. 8. The system provides detection protection for zero-day and other newly discovered vulnerabilities that do not have a patch made publicly 9. 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 be 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 can automatically create exception lists 2. The system can maintain a history of networked devices, including IP and MAC addresses 3. The system shall integrate with DoS existing or future enterprise patch management solutions. 4. The system shall integrate with DoS existing or future enterprise vulnerability management solutions. 5. The system shall integrate with DoS existing or future configuration management solutions. 6. The system shall integrate with DOS existing or future endpoint security solutions. Deployment Mode Requirements 1. The system supports in-band mode. 2. The system supports out-of-band mode. 3. The system supports decentralized deployments (Layer 2 connectivity). 4. The system supports centralized deployments (Layer 3 connectivity). 5. The system supports mixed deployments (decentralized & centralized). 6. The system supports redundant/high availability configurations. 7. The system can quarantine non-compliant hosts within the access switch. 8. The system allows access VLAN assignment based on user role. 9. The system provides port level access control. 10. The system supports VoIP environments. 11. The system supports BOTH NAC agent client and clientless modes. 12. The system supports NAC via a "transient" agent. 13. 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 redirection of logs to a RADIUS server. 18. The system supports reusable policy creation. 19. The system supports pre-defined benchmarks for federal and Department regulatory reporting. 20. The system supports the backup and recovery of policies/configurations 21. 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 Terms 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/101903B036/listing.html)
- Record
- SN02091259-W 20100314/100312235826-9c701bf906a2f7c413b406c725f5bcd0 (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 |