SOURCES SOUGHT
D -- Multilevel Access Reduced Sign-on (MARS) Capability
- Notice Date
- 5/11/2015
- Notice Type
- Sources Sought
- NAICS
- 541511
— Custom Computer Programming Services
- Contracting Office
- Defense Information Systems Agency, Procurement Directorate, DITCO-NCR, P.O. BOX 549, FORT MEADE, Maryland, 20755-0549, United States
- ZIP Code
- 20755-0549
- Solicitation Number
- MARS
- Archive Date
- 6/23/2015
- Point of Contact
- Walter F. Holt, Phone: 301-225-4502, Natasha L. Abbington, Phone: 301-225-4051
- E-Mail Address
-
walter.f.holt.civ@mail.mil, natasha.l.abbington.civ@mail.mil
(walter.f.holt.civ@mail.mil, natasha.l.abbington.civ@mail.mil)
- Small Business Set-Aside
- N/A
- Description
- REQUEST FOR INFORMATION Multilevel Access Reduced Sign-on (MARS) Capability Defense Information Systems Agency (DISA), Services Development Directorate, Emergent Services Division is seeking information from industry to assist with the development and planning of a potential new requirement. THIS IS A REQUEST FOR INFORMATION (RFI) NOTICE ONLY. THIS IS NOT A REQUEST FOR PROPOSALS (RFP). NO SOLICITATION IS AVAILABLE AT THIS TIME. 1. Overview/Purpose/ Description of Procurement The DISA Emergent Services Division is seeking information from potential sources with innovative commercial solutions and/or emerging technologies which will provide a capability that currently does not exist in the Department of Defense (DoD), and will meet the requirements identified under Technical Characteristics. With the advent of new technology that allows for multi-domain access from a multilevel client device, there is an increasing demand for a simplified logon solution. While the hardware infrastructure can be reduced down to one client and one wire for the end user, the current technology still requires a separate logon credential for each domain and repeated authentication at the application level. The capability desired will provide a single token logon, providing access to systems at multiple security classification levels and compartments, and will interoperate with existing commercially available multilevel access solutions. 2. Scope of Effort Warfighters require access to many different security domains, to include, but not limited to, multiple security classification levels and compartments. They require this access simultaneously, within direct view at their work station. Currently, this access requires the user to authenticate separately on each security domain (i.e., logon to each security domain individually), requiring different credentials that may consist of multiple hard tokens and/or multiple highly complex passwords. The proposed technology desired will allow operational commanders across Combatant Commands, Services, and Agencies throughout the DoD to reduce their logon requirements down to one single token to gain access to all authorized domains. DISA Emergent Services Division partners with the Office of the Assistant Secretary of Defense for Research and Engineering (ASD(R&E)) to deliver developmental and/or operational prototypes. In alignment with the ASD(R&E) timelines, proposed capabilities shall have deliverables within 12-24 months. 3. Technical Characteristics The Government is interested in deploying solutions that use standardized components that have already been certified against applicable standards and authorities such as FIPS 140-2, Common Criteria, NIAP Protection Profiles, and United Cross Domain Management Office (UCDMO) baseline. DISA Emergent Services Division is interested in systems that consist of components that can be swapped out for one another with minimal time and cost. DISA Emergent Services Division is looking for a defense-in-depth solution that will maintain appropriate security domain separation and provide multifactor authentication of the authorized human user. The solution should provide a common authenticator that can then assert to the various security domains to which that the user has been authenticated and authorized. The solution will utilize a collection of GFE multilevel end user devices (EUD) that may be thick, thin, or zero clients. The EUD provides access to all of a user's authorized domains, including video and voice. It also provides a guest remote access through an interagency portal that takes them to their home portal. From a user's perspective, the EUD provides access to multiple security domains but does not have the ability to transfer data between security domains. Initial authentication of the user should be with a hard token (CAC preferred). Applications that require PKI based operations to be performed (authentication, digital signatures, encrypt/decrypt, hashing) should not need to reach back to the initial authentication token at the EUD. The solution needs to integrate with the established PKI infrastructure for each domain. Any secondary credentials required by the solution should comply with NIST SP 800-157 and be stored in hardware-backed storage such as HSM, TPM 1.2, TPM 2.0, or FIPS 140-2 hardware module. The solution does not implement application single-sign-on (SSO) but should be an enabler for those applications using SSO with Active Directory Servers within each security domain network. The solution must: • Properly perform path validation of all certificates. • Conform to DoD X.509 Certificate Policy for both unclassified and classified systems. • PKI actions, direct or indirect, need to be captured in audit records that can integrate into existing IDS solutions. The focus is the creation of audit records not the analysis of them. • Support transition to ECC and SHA-2, especially from the EUD. • Provide communication transport that is Suite-B compliant, when required. • Maximize the use of existing standards and minimize the use of proprietary protocols. All use of proprietary protocols requires explicit Government permission. • Minimize, control, and secure information transfer between classified and unclassified networks. If a Cross Domain Solution (CDS) is used, it must be on the UCDMO baseline. • Present a common end user experience such that users can obtain network access to authorized domains from any DoD location, providing both local and remote facility guest access. This effectively supports a DoD enterprise. Notional Diagrams Figure 2 Notional Legend: The following steps are meant to convey notional ideas and are not meant to be prescriptive. DISA Emergent Services Division is researching the broader community for innovative solutions. Step 1. The user initiates an access request from a multilevel device, the EUD, which is under the control of the local command/agency/organization and located in an appropriately secured physical area (protected enclave). The user may be a local domain user or a DoD visitor. The user is identified and authenticated at the local portal using their primary authentication token, which is only available at the local portal and protected by the CDS. All communication between EUDs and portals is via CSfC VPN components. The user is presented with a list of available networks, potentially depending on the user's clearance, EUD location, and user authorization. Step 2. The user selects one or more networks for connection. Each session request contains the established identity of the user and is routed to the target connection broker, which assigns the session to a VDI server. All session communication is via CSfC VPN. Step 3. The VDI server sends an inquiry to the network's directory service to obtain a logon decision and potentially a download of VDI logon scripts and GPO settings. Step 4. The local portal AD can assert a user's successful authentication to network ADs associated with that command/agency/organization portal. If the user is a DoD visitor and if the EUD is enabled for visitors, the communication will be routed through the external portal. Both the primary token and the communication between an operational AD and the local portal AD are protected by a CDS. All session communication is via CSfC VPN. Step 5. The user's primary credential is associated with locally stored secondary credentials in each network using a common identifier. Secondary credentials may be Derived PIV credentials, userid/password, or some other credential. Secondary credentials allow each network to have control over the issuance, maintenance and termination of credentials used to access that network's resources. Step 6. In VDI and mobility use cases, hosted VMs and sessions use local PKI credentials to perform cryptographic operations such as encryption and digital signatures. The credentials are made available either by directly accessing the credentials from the key store or by loading the credentials into the VDI server. Step 7. If a network has a centralized source of authority for access management and authentication, it could provide single sign-on across application and web servers at this point. Application and web SSO is not part of this RFI but proposed solutions should be able to integrate with SSO implementations. Definition of Terms Term Definition Access Ability and means to communicate with or otherwise interact with a system, to use system resources to handle information, to gain knowledge of the information the system contains, or to control system components and functions. SOURCE: CNSSI-4009 ATO Authorization to Operate Authenticate To confirm the identity of an entity when that identity is presented. SOURCE: SP 800-32 To verify the identity of a user, user device, or other entity. SOURCE: CNSSI-4009 Authentication Verifying the identity of a user, process, or device, often as a prerequisite to allowing access to resources in an information system. SOURCE: SP 800-53; SP 800-53A; SP 800-27; FIPS 200; SP 800-30 Cross-Domain Solution (CDS) A form of controlled interface that provides the ability to manually and/or automatically access and/or transfer information between different security domains. SOURCE: CNSSI-4009; SP 800-37 CSfC Commercial Solutions for Classified Defense-in-Depth Information security strategy integrating people, technology, and operations capabilities to establish variable barriers across multiple layers and dimensions of the organization. SOURCE: CNSSI-4009; SP 800-53 Digital Signature An asymmetric key operation where the private key is used to digitally sign data and the public key is used to verify the signature. Digital signatures provide authenticity protection, integrity protection, and non-repudiation. SOURCE: SP 800-63 Domain An environment or context that includes a set of system resources and a set of system entities that have the right to access the resources as defined by a common security policy, security model, or security architecture. See Security Domain. SOURCE: CNSSI-4009; SP 800-53; SP 800-37 Hardware Security Module (HSM) A physically and logically protected hardware device that provides a secure set of cryptographic services. It includes the set of hardware, firmware, software, or some combination thereof that implements cryptographic logic, cryptographic processes or both, including cryptographic algorithms. SOURCE: PCI Security Standards Council Multilevel Device Equipment trusted to properly maintain and separate data of different security domains. SOURCE: CNSSI-4009 National Information Assurance Partnership (NIAP) A U.S. Government initiative established to promote the use of evaluated information systems products and champion the development and use of national and international standards for information technology security. The key operational component of NIAP is the Common Criteria Evaluation and Validation Scheme (CCEVS) which is the only U.S. Government-sponsored and endorsed program for conducting internationally recognized security evaluations of commercial off-the-shelf (COTS) Information Assurance (IA) and IA-enabled information technology products. SOURCE: CNSSI-4009 Network Access Access to an organizational information system by a user (or a process acting on behalf of a user) communicating through a network (e.g., local area network, wide area network, Internet). SOURCE: SP 800-53; CNSSI-4009 Suite B A specific set of cryptographic algorithms suitable for protecting national security systems and information throughout the U.S. Government and to support interoperability with allies and coalition partners. SOURCE: CNSSI-4009, as modified Token Something that the Claimant possesses and controls (typically a key or password) that is used to authenticate the Claimant's identity. SOURCE: SP 800-63 Trusted Platform Module (TPM) A tamper-resistant integrated circuit built into some computer motherboards that can perform cryptographic operations (including key generation) and protect small amounts of sensitive information, such as passwords and cryptographic keys. SOURCE: SP 800-111   4. REQUESTED INFORMATION: (1) Provide responses to the following questionnaire: - One of our goals is to identify malicious use of keys. What tools, techniques, and capabilities do you have to detect and audit malicious use of keys? - Have you ever taken a product through SABI, TSABI, and ATO? - Do you have any experience with Type 1 products? - What cross CDS capabilities do you have? - Have you successfully deployed any CDS systems to ATO? If so, what was your contribution to the architecture and to the ATO? - What is your defense-in-depth strategy for this type of solution? - Have you designed or deployed a successful PKI architecture? - What specific qualifications do you have that shows you will be successful? (2) Submit a capabilities statement which should include the following: - Provide hardware/software compatibility list for proposed solution. - Provide list of certifications (FIPS, NIAP, etc.) for identified hardware and software. - Outline a notional architecture. - Provide a cost estimate for submitted technical options. Include estimated cost of any required certification efforts. - Provide a list of milestones and deliverables, with estimated timeline. RESPONSE GUIDELINES: Interested parties are requested to respond to this RFI with a white paper. Submissions cannot exceed 15 pages, single spaced, 12-point type with at least one-inch margins on 8 1/2" X 11" page size. The response should not exceed a 5 MB e-mail limit for all items associated with the RFI response. Responses must specifically describe the contractor's capability to meet the requirements outlined in this RFI. Oral communications are not permissible. FedBizOpps will be the sole repository for all information related to this RFI. Companies who wish to respond to this RFI should send responses via email NLT June 8, 2015, 4:00 PM Eastern to carol.s.embrey.civ@mail.mil. INDUSTRY DISCUSSIONS: DISA representatives may choose to meet with potential offerors and hold one-on-one discussions. Such discussions would only be intended to obtain further clarification of potential capability to meet the requirements, including any development and certification risks. QUESTIONS: Questions regarding this announcement shall be submitted in writing by e-mail to walter.f.holt.civ@mail.mil. Verbal questions will NOT be accepted. Answers to questions will be posted to FBO. The Government does not guarantee that questions received after May 28, 2015, 4:00 PM Eastern will be answered. The Government will not reimburse companies for any costs associated with the submissions of their responses. 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", is incorporated by reference in this RFI. The Government does not intend to pay for information received in response to this RFI. Responders to this invitation are solely responsible for all expenses associated with responding to this RFI. This RFI will be the basis for collecting information on capabilities available. This RFI is issued solely for information and planning purposes. Proprietary information and trade secrets, if any, must be clearly marked on all materials. All information received in this RFI that is marked "Proprietary" will be handled accordingly. Please be advised that all submissions become Government property and will not be returned nor will receipt be confirmed. 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.
- Web Link
-
FBO.gov Permalink
(https://www.fbo.gov/spg/DISA/D4AD/DTN/MARS/listing.html)
- Place of Performance
- Address: 6914 Cooper Avenue, Fort Meade, Maryland, 20755, United States
- Zip Code: 20755
- Zip Code: 20755
- Record
- SN03726461-W 20150513/150511234556-f0dbae9046ad07393523fb8435d8e388 (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 |