Attachment A- B2B Gateway.docx

3.5. Business to Business (B2B) Gateway Comment by Rider, Aimee L. CIV NMLC: Shouldn’t this be its own evaluation factor where Offerors have to demonstrate how they are capable of B2B requirements? If not, why?

Some of this information looks more appropriate for the PWS than for the Offerors Instructions section. Additionally, some of the information looks as if it should be evaluated pre-award and some of the information looks like it should be handled post-award. Comment by Taylor, Richard CIV NMLC: No, not really. If it is an evaluation factor, it becomes a “pass/fail”. Technically, a company might not have a B2B relationship when they make an offer, but the awardee can go establish one. (i.e. any/all non-awardees don’t have to go through the expense/ effort/ trouble if they don’t need it).

3.5.1. All Department of the Navy (DON) information systems as defined in Department of Defense Directive (DoDD) 8500.1 shall be certified and accredited (C&A) for operation. C&A is attained via the Defense Information Assurance Certification and Accreditation Process (DIACAP) and is applicable to all DON- owned or controlled information systems that receive, process, store, display or transmit Department of Defense (DoD) information, regardless of Mission Assurance Category (MAC) classification or sensitivity, except, per DoDD 8500.1 Paragraph 2.3; IT that is considered Platform Information Technology (PIT). Regardless of whether the system or device is considered PIT or whether it is determined that it requires a full accreditation, the following DIACAP artifacts shall be included with your proposal; System Identification Profile (SIP), DIACAP Implementation Plan (DIP), and Plan of Actions and Milestones (POA&M). A template has been included with this solicitation as B2B Attachment 6, MDS2F Form and Instructions. Completion of this form in its entirety will satisfy the requirement for the SIP, DIP and POA&M. Comment by Rider, Aimee L. CIV NMLC: Will this be evaluated as part of the solicitation phase? Comment by Taylor, Richard CIV NMLC: The form, completed, is necessary.

It is inherently a pass/fail - did offeror provide it or not?

3.5.1.2. Navy PIT Designation

3.5.1.2.1. Certain medical technologies may be designated as PIT by the Navy Operational Designated Accrediting Authority (ODAA); however the PIT designation itself does not constitute an Approval to Operate (ATO). The PIT system will require a PIT Risk Analysis (PRA). The DIACAP SIP, DIP, POA&M and Risk Analysis documents are required in order to complete a PRA. Contractors will be required to scan the PIT system for vulnerabilities prior to delivery.

3.5.1.2.1.1. According to DoDD 85001, Paragraph E2.1.16.4; PIT refers to computer resources, both hardware and software, that are physically part of, dedicated to, or essential in real time to the mission performance of special-purpose systems. Medical technologies, and specifically medical imaging and monitoring systems are considered special-purpose mission technologies according to this definition.

3.5.1.2.1.2. The PIT designation issued by the ODAA may be used by the Program Manager (PM) to complete a PRA in order to prove compliance with C&A requirements, but is cautioned that the appropriate IA controls must still be built into the IT to comply with acquisition requirements. The contractor shall work with Navy Program Managers to ensure their systems meet these requirements.

3.5.1.3. The contractor shall establish appropriate administrative, technical, and physical safeguards to protect all government data, to ensure the confidentiality, integrity, and availability of government data under their control. At a minimum, this shall include provisions for personnel, electronic, and physical security.

3.5.1.4. The contractor shall propose an acceptable approach to selecting Information Awareness (I/A) controls starting from the baseline set on DoD Instruction 8500.2 B, commensurate with the system’s Mission Assurance Category (MAC) and Confidentiality Level. For medical systems, the MAC level assigned is typically MAC III sensitive. Comment by Rider, Aimee L. CIV NMLC: This language again indicates that this should be its own eval factor. Comment by Taylor, Richard CIV NMLC: Not 100% sure that making their I/A a separate factor works. It depends - are we making it that you must pass/fail IA and B2B before award or is it part of once you have the award….

It is again part of the important details for the awardee. For the proposal, we just need an acceptable plan.

3.5.2. The contractor shall comply with DIACAP requirements as specified by the DoD that meet appropriate DoD and Navy IA requirements. The contractor shall initiate the process by providing the required documentation necessary to receive an ATO. The contractor shall make their device or system delivered against this contract available for C&A testing and initiates the process well in advance of a contract delivery order. The requirements shall be met before the contractor's system is authorized to access DoD data or interconnect with any DoD network that receives, processes, stores, displays or transmits DoD data. An ATO, at a minimum, will be required before a device or system is installed. The contractor shall ensure that the proper contractor support staff is available to participate in all phases of the DIACAP process. They include but are not limited to;

3.5.2.1. Completing and maintaining all documentation necessary to obtain an ATO.

3.5.2.2. Attending and supporting DIACAP and C&A meetings with Navy IA representatives.

3.5.2.3. Supporting/conducting the vulnerability mitigation process to comply with IA controls listed in DoD Instruction 8500.2

3.5.2.3. Supporting the C&A Team during system security testing.

3.5.2.4. Contractors must confirm that their systems are locked down prior to initiating C&A testing.

3.5.3. Post-Accreditation Review

An annual IA review shall be conducted that comprehensively evaluates existing policies and processes to ensure procedural consistency and that the IS continues to operate in the manner to which it was accredited. The annual review process should account for the analysis of projected policy needs, and produce a plan for development or implementation of new policies or processes.

3.5.4. Personnel Security and User Access Control

3.5.4.1. The contractor shall comply with DoDD 8500.1, “Information Assurance (IA)”, DoD Instruction (DODI)

8500.2 “Information Assurance (IA) Implementation”, DoDD 5400.11, “DoD Privacy Program”, DoD 6025.18-R, DoD Health Information Privacy Regulation and DoD 5200.2-R, “Personnel Security Program Requirements”. Contractor responsibilities for ensuring personnel security include, but are not limited to meeting the following requirements:

Follow the Privacy Office guidelines for submittal of IT security clearances and ensure all contractor personnel are designated as IT-I, IT-II or IT-III where their duties meet the criteria of the position sensitivity designations.

3.5.4.2. Because of the unique circumstances presented by DoD and DON networks, personnel security requirements shall be followed to ensure appropriate precautions are taken prior to allowing vendor personnel access to the network. Any vendor personnel that will be accessing the medical device/system while installed on the hospital network will be required to have a National Agency Check (NAC) completed. Typically, this requires an investigation to support a “Public Trust Position” and requires the person(s) to complete and submit a Standard Form 85P (SF85P), Questionnaire for Public Trust Positions, via the Electronic Personnel Security Questionnaire (EPSQ). Questions relating to SF85Ps and the EPSQ process may be directed to 1-888-282-7682 or online at http://www.dss.mil/index.htm. Contractor personnel accessing equipment connected to the hospital network will be required to complete a System Authorization Access Request-Navy (SAAR-N) (form OPNAV 5239/14). Copies of this form can be obtained from the Navy PACS Office. Additionally, contractor personnel are required to complete the annual DoD IA training requirements.

3.5.4.3. The contractor shall initiate, maintain and document personnel security investigations appropriate to the individual’s responsibilities and required access to Sensitive Information (SI).

3.5.4.4. Immediately report to the appropriate Navy POC and deny access to any automated information system (AIS), network, or information if a contractor employee filling a sensitive position receives an unfavorable adjudication, if information that would result in an unfavorable adjudication becomes available, or if directed to do so by the appropriate Navy representative for security reasons.

3.5.4.5. Ensure that all contractor personnel receive IA training before being granted access to DoD AIS’s.

3.5.4.6. Access to the medical devices will be limited to authorized users as determined by local policy. Vendors whose systems do not yet meet the requirement for CAC authentication must indicate their willingness to do so, and offer a timeline for compliance.

3.6. Operating Systems

To ensure that medical systems attain data confidentiality, integrity, and availability levels consistent with best industry practices, the use of current Operating Systems (OS) is highly recommended. Preference shall be given to systems that employ modern operating systems, including closed source, open source, or proprietary. Medical systems will employ whenever possible, operating systems that are fully supported by the manufacturer and are commercially available.

3.7. Domain Name System Realm/Directory Services

Contractor will be required to demonstrate, if applicable whether client/server topology based medical systems can integrate with Directory Services and support LDAP authentication.

3.8 Local Privileged and Administrative User/Local System Accounts

3.8.1. Contractor shall create a single local user account with administrative/root level privileges for purposes of conducting system repairs and maintenance only. This account shall be separate and distinct from the built-in local administrative/root account provided by the Operating System and shall comply with DoD policy. All factors required to complete successful identification, authentication and authorization against the built-in local Administrative/Root level account shall be provided to the Medical Treatment Facility (MTF) Biomedical Engineering Department. In addition, the MTF will be provided with access and instructions on how to change IP addresses, host names/AE titles, etc.

3.8.2. Complete administrative system rights shall be provided to the government System Administrator for the purpose of conducting device vulnerability scans as needed.

3.9. Antimalware

3.9.1. Medical systems that make use of a file system under direct control of an operating system instance whether physical and/or virtual shall provide the appropriate antimalware safeguards consistent with current security practices. Exemption from this requirement is applicable to medical systems which make use of a proprietary file system and/or operating system for which no commercially available antimalware application exists. This exemption should be documented in the C&A Initial Technical Questionnaire.

3.9.2. Preference may be given to medical systems capable of supporting antimalware applications, within tolerable specifications, that support the use of DISA approved McAfee, and/or Symantec solutions. Systems shall be configured as to allow for the update of malware definition signatures on a scheduled basis. Scanning shall encompass the entire system (file system, operating system, real-time processes), by default. In cases where the scanning of the entire system may negatively affect the operation of the system, the Contractor shall provide a detailed list of exclusions with justifications as part of the C&A Initial Technical Questionnaire.

3.10. Malware Handling and Threat Detection

The contractor shall monitor systems for malware incidents, such as viruses, spyware, and adware and prepare incident reports to include the location of the malware, severity, and course of action taken for cleanup. In cases where complete malware removal cannot be achieved, the Contractor shall re-image the system to support cleanup efforts. The contractor will provide the Government with full access to the antimalware application logs.

3.11. Navy Business to Business (B2B) Gateway

3.11.1. All contractor systems that will communicate with DON systems will interconnect through the established Military Health System (MHS) Business to Business (B2B) gateway. For all Web applications, contractors will connect to the DISA-established Web DMZ.

3.11.1.1. The Contractor shall connect to the B2B gateway via a contractor procured Internet Service Provider (ISP) connection and assume all responsibilities for establishing and maintaining their connectivity to the B2B gateway. This will include acquiring and maintaining the circuit to the B2B gateway and acquiring a FIPS-140-2 Virtual Private Network (VPN)/Firewall device compatible with the MHS VPN device. Maintenance and repair of contractor procured VPN equipment shall be the responsibility of the contractor.

3.11.1.1.2. The Contractor shall configure their network to support access to government systems (e.g., configure ports and protocols for access).

3.11.1.1.3. The Contractor shall provide full time connections to a TIER1 or TIER2 ISP. Dial-up ISP connections are not acceptable.

3.11.1.1.4. The Contractor shall comply with DoD guidance regarding allowable ports, protocols and risk mitigation strategies.

3.12. Prior to accessing DON networks, all contractors shall complete a DD Form 2875 System Authorization Access Request (SAAR), included as B2B Attachment 3, and submit to NMLC, Code 03, Imaging Informatics Division for processing. The contractor shall complete applicable DoD IA training.

3.13. IPv6

The proposed system shall be Internet Protocol version 6 (IPv6) capable or the vendor must provide a detailed project, migration or planning documentation to show when the proposed system shall be IPv6 capable.

3.13.1. Minimum IPv6 capabilities include:

3.1.13.1.1. Conformant with the IPv6 standards profile contained in the DoD IT Standards Registry

(DISR);

3.1.13.1.2. Maintaining interoperability in heterogeneous environments with IPv4;

3.1.13.1.3. Commitment to upgrade as the IPv6 standard evolves;

3.1.13.1.4. Availability of vendor IPv6 technical support.

3.14. The contractor must be able to demonstrate or provide documentation to prove that their product is IPv6 capable. As described in the DISR IPv6 standards profile, application vendors are expected to scan and test their code for IPv6 compliance and provide a letter of compliance indicating to what degree they comply. The letter shall be in vendor format and describe the standards used for testing and the results of the scans. IPv6 'capable' is defined as having the capability of receiving, processing and forwarding IPv6 packets and/or interfacing with other IPv6 capable systems/devices and in a manner similar to IPv4. In order to demonstrate IPv6 compliance, the vendor should submit the following documentation:

3.14.1. Provide a diagram showing IPv6 core configuration, to include IPv6 addressing, internal network connectivity and topology, external network connectivity, and IPv6 traffic flow;

3.14.2. Submit a list of core components to include vendor/manufacturer IPv6 compliance;

3.14.3. Submit a report that illustrates testing of IPv6 compliance, to include test scripting, logs and results.

3.15. Information Assurance Vulnerability Management (IAVM)

3.15.1. IAVM is focused on maintaining a secure platform as new vulnerabilities and exploits are discovered and released through various software developers and security agencies. The core tool of successful IAVM is the Information Assurance Vulnerability Alert (IAVA). The DoD releases IAVAs for local action on the various platforms across the enterprise network. Each Navy Healthcare Facility is responsible for managing their local network. Most DoD IAVAs originate from a real world event such as a patch release or vulnerability notification from a software vendor (e.g. Windows or Sun patch release), or a US-CERT released from the CERT Coordination Center at Carnegie Mellon University. To have an effective IAVM program, vendors must be proactive in monitoring emerging threats. Some recommended sources for IAVM support are:

3.15.1.1. General Vulnerability alerts, all platforms: http://www.cert.org/nav/index_red.html

3.15.1.2. Microsoft security resources: http://www.microsoft.com/technet/security/bulletin/notify.mspx

3.15.1.3. SUN Microsystems Security resources: http://sunsolve.sun.com/pub- cgi/show.pl?target=security/sec

3.15.2. As part of the IAVM program, the contractor shall provide a primary and secondary point of contact for compliance actions. The point of contact shall provide, upon receipt of a vulnerability message, an acknowledgement of that receipt. The vendor shall thoroughly test all mitigations for the vulnerability, and upon applying the mitigation to the system, report compliance. Receipt and compliance messages shall occur within the stipulated time window, as stated in the vulnerability message or other official notification.

3.15.3. Any vendor interested in meeting this requirement shall have a documented process to demonstrate an organizational culture embracing security throughout the system lifecycle. The processes shall clearly demonstrate security’s role in the product development phase, and the processes the vendor employs to react to vulnerabilities, validate required patches, communicate status and required actions to their customers, and the follow up service support to address patch implementation.

3.16. Health Insurance Portability and Accountability Act (HIPAA)

The contractor shall comply with the HIPAA Act of 1996 (Public Law 104-191) requirements, specifically the administrative simplification provision s of the law and the associated rules and regulations published by the Secretary, Health and Human Services (HHS). This includes the Standards for Electronic Transactions, the Standards for Privacy of Individually Identifiable Health Information and the Security Standards.

3.17. Additional Attachments Comment by Rider, Aimee L. CIV NMLC: Are these required to be filled out with the offeror’s proposal? This is unclear. Comment by Taylor, Richard CIV NMLC: Attachment 1 appears to be a reference sheet.

3.17.1. B2B Attachment 1 contains a list of approved products available in the commercial marketplace that are compatible with a B2B with NMLC. Comment by Rider, Aimee L. CIV NMLC: Is this proper to include this attachment? It only includes products from Juniper Neworks. Are these the only approved products available in the commercial marketplace? If not, this appears to be an improper endorsement. Comment by Johnson, Gerrie M. CIV NMLC: This is the system and forms we use on all Navy contracts that require it. I am assuming that this system is required for the Navy

3.17.2. B2B Attachment 2 is a form for vendors to complete when requesting a B2B with NMLC. Comment by Taylor, Richard CIV NMLC: At time of seeking the B2B.

3.17.3. B2B Attachment 3 is a blank DD 2875, System Authorization Access Form. Comment by Taylor, Richard CIV NMLC: At time of seeking the B2B.

3.17.4. B2B Attachment 4 is a B2B Implementation Briefing for additional information regarding setting up a B2B.

3.17.5. B2B Attachment 5 is a Tricare Manual. Within this manual, sections that are highlighted represent B2B requirements.

3.17.6. B2B Attachment 6 is the Manufacturer Disclosure Statement for Medical Device Security. This form must be completed in its entirety before a B2B can be implemented. Comment by Taylor, Richard CIV NMLC: At time of seeking the B2B.

List of B2B Attachments:

B2B Attachment 1--Juniper Networks - Product Listings B2B Attachment 2--NMLC - Vendor Business to Business (B2B) Information Request Form B2B Attachment 3--DD2875-System Authorization Access Form B2B Attachment 4--B2B Implementation Briefing 2013 B2B Attachment 5--Tricare Manual (with B2B requirements highlighted) B2B Attachment 6--MDS2 Form and Instructions