Q and A FOR DAS RFP HT001424R0025_ 08122024.docx

QUESTIONS FOR RFP HT0014-24-R-0025

1. Can you tell me who is the manufacturer of the DAS ? eg Commscope, JMA, etc It is defined for WRNMMC in the inventory of the PWS, in PART 7, APPENDIX F Current Equipment Locations and Inventory. At WR it’s mainly JMA Teko, at Dalecarlia it is 2 Comba repeaters 1 Node A repeater Corning Mobile Access Head End with one remote.

Also, we will send an updated inventory, as-builts, and documentation for both sites and update the PWS.

Adding language to the PWS about an exception related to DaleCarlia, to state “The government reserves the right to replace the equipment in Dalecarlia under a separate acquisition. The contractor shall provide the same O&M support as described in the PWS regardless of what vendor performs the potential equipment replacement. The contractor will have the opportunity for acceptance of the new equipment after confirming operational status.”

2. Can the government provide DAS System as-builts and existing DAS system information?

We will send an updated inventory, as-builts, and documentation for both sites and update the PWS.

3. Can the Government provide Building floor plans and/or drawings?

We can show to vendors during a combined vendor walkthrough, but can only provide the files to the awardee.

4. Can the Government provide inside plant fiber and power maps for both facilities?

We can show inside plant layout (not fully up to date) to vendors during a combined vendor walkthrough, but can only provide the files to the awardee..

5. Can the Government provide Total Sq footage for existing DAS coverage at each facility?

No. This should not be necessary for a proposal to support the existing system because we are providing the inventory which has locations.

6. Is the existing system networked together or two separate systems?

WRNMMC and Dalecarlia are separate systems.

7. The Original Sources Sought Document included all the objectives, including the desire to replace the Andrew (CommScope) ION-B. Is this still valid and why was that information not included in this solicitation?

A refresh was completed since that earlier Sources Sought and we no longer have CommScope equipment. We will send an updated inventory, as-builts, and documentation for both sites and update the PWS.

8. Do you have existing carrier lease agreements, or access to these, and do you expect the new contractor to assume responsibility for these, or create new carrier agreements these?

There are no carrier lease agreements. The carriers are responsible for their equipment.

9. CLIN 0003, 0004- It requests FFP for Professional Services in support RMF ATO Standalone Authorization – Why is RMF ATO a part of this requirement?

DHA Cybersecurity standards require a Standalone version of the RMF ATO be completed on standalone requirements. See attachment.

10. CLIN 0005- Can the government provide details on what this requirement is?

Optional CLIN 0005 Transition-in (no-cost bid if Incumbent. See Section 1.6.1.1 Transition-in period) As stated in the Section 1.6.1.1 Transition-In section, “If the incoming contractor partner is the incumbent prime contractor or has a partnership with the incumbent prime contractor which allows the continuation of the existing staff and support contracts, the contractor’s proposal shall not include a cost for the Transition-in Period.” This is because if the incumbent wins, the overlapping transition-in period would be unnecessary because they would just be continuing their existing support.

11. CLIN 001 and 002 lists warranty as one of the functions to be addressed. Please describe the warranties being referred to, since there is no DAS system hardware/software required within the solicitation.

This refers to management of the warranty service of the complete system solution, including all hardware and software and labor. See section 5.1.3.1 and 5.1.3.2. See the inventory table in the PWS in “PART 7, APPENDIX F Current Equipment Locations and Inventory” through the end of the PWS for the latest equipment listing. Once the incoming contractor performs the baseline survey and confirms the operational status of the system, they will be responsible for continuation of break/fix/replace warranty service as detailed in the PWS, especially 5.1.3.2. UPDATING PWS to remove force majeur responsibility from contractor.

12. CLIN 0003, 0004 - If Professional Services are actually required to support RMF ATO- can you define the Scope and/or Responsibilities?

“Professional Services” refers to all the support services the contractor is proposing for the O&M contract. This contract does not specify a number of FTEs, but rather expects the vendor to propose the staffing approach that they think will most efficiently and effectively address the requirements. Any subcontracts the vendor chooses to enter into to fill gaps in their expertise, etc. are the responsibility of the vendor to fund and manage in compliance with the PWS requirements.

13. Is this new requirement or recompete? If recompete, please provide incumbent contract # and contract vehicle?

It is a recompete. The prior vehicle was WITS-3 ) Washington Interagency Telecommunications System-3) which is a GSA vehicle. Current awardee is Lumen, contract is GS11T088BJD6002.

14. Inventory of system per building?

WRNMMC inventory is in the PWS in PART 7, APPENDIX F Current Equipment Locations and Inventory. Also, we will send an updated inventory, as-builts, and documentation for both sites and update the PWS.

15. Maintenance history?

Will send the maintenance history that is available, but please note that the contractor will complete a baseline survey after contract award, and will confirm operational status of equipment. The government will be responsible for remediating any pre-existing issues and then turning functional equipment back over to the contractor for sustainment.

16. Site walk schedule?

A one-time group site walk and Q&A for all interested contractors will be arranged via the Contract Office in conjunction with WRNMMC ITD.

17. In regards to the titled solicitation on Sam.gov, may we know the incumbent contractor and/or contract # that we would coordinate for the transition-in if awarded this effort?

This will be provided on award.

18. Since there is no designated CLIN for hardware purchase, does the government plan to have an ODC CLIN for the purchases for hardware technical refresh?

No. There is no planned equipment to be refreshed under this PWS. Any future refresh will require additional acquisition process to be completed either as a modification or a separate contract. The contractor will be responsible for all hardware warranty services including replacement of any failed or faulty devices after the initial baseline survey and the contractor acceptance of the operational status of the system, excluding force majeur. Any contractor-provided repair or replacement parts that are attached to the system become the property of the government.

19. Can the government provide the name of the Incumbent and contract number?

The prior vehicle was WITS-3 ) Washington Interagency Telecommunications System-3) which is a GSA vehicle. Current awardee is Lumen, contract is GS11T088BJD6002.

20. Can the government confirm if a Secret FCL is required prior to submission or will the government sponsor a FCL upon award?

Quotes from the contract: 4.2 The contractor shall possess and maintain a SECRET facility clearance from the Defense Security Service. The Contractor’s employees, performing work in support of this contract shall have been granted a SECRET security clearance from the Defense Industrial Security Clearance Office. 6.1.1 “Staff performing hands-on privileged roles involving administration of the servers, devices, and software included in the DAS solution shall be required to have a minimum of a DoD Secret/Confidential Clearance Eligibility (Revised Federal Investigative Standards (FIS) Tier 3 (T3)) prior to reporting to work, and shall maintain this level of clearance throughout the period of performance.” Since the contractor staff require clearance to be in place prior to starting work, the contractor needs to have the Secret Facility to be operational at the time of award in order to process those staff. There is not time in the transition to establish a new Secret Facility.

21. Can the government confirm if there is any ION-B equipment to be covered? ION-B is mentioned in the RFP, but is not listed in the parts list?

WRNMMC inventory is in the PWS in PART 7, APPENDIX F Current Equipment Locations and Inventory. We will send an updated inventory, as-builts, and documentation for both sites and update the PWS.

22. Can the government confirm if the contractor will be responsible for replacement parts if required? Or does the government have spare parts on hand?

Contractor will be responsible for replacement parts and spare parts. The contractor will have access to any spare parts already on hand at contract award. We will send an updated inventory, as-builts, and documentation for both sites and update the PWS. Any contractor-provided repair or replacement parts that are attached to the system become the property of the government.

23. Some of remotes listed are for 800/900mhz LMR and paging. Can the government confirm if the contractor is responsible for the paging system along with cellular?

The paging systems interface with the DAS at the DAS head-end, and the pager signals are amplified via the DAS, and the DAS PWS requires these interfaces, but the actual paging systems are maintained separately.

image1.emf

DHA Stand Alone Authorization.pdf

For Official Use Only

DEFENSE HEALTH AGENCY

CYBER SECURITY DIVISION

RISK MANAGEMENT FRAMEWORK

STAND-ALONE INFORMATION SYSTEM AND

CLOSED/RESTRICTED NETWORK ASSESSMENT

AND AUTHORIZATION GUIDE

V1.0

Stand-Alone Information System and

Closed/Restricted Network Assessment and Authorization Guide v1.0

November 2017 i

REVISION AND HISTORY PAGE

Revisions and version changes to this document are recorded within the following table. New versions are published when changes to the document equate to 10 percent or greater of the document’s content, or if a change requires immediate implementation. This record is maintained throughout the life of the document.

This document will be reviewed at a minimum annually.

Version Date Description of Change Author

1.0 22NOV17 Original Release DHA CSD ii

TABLE OF CONTENTS

1.0 INTRODUCTION

1.1 PURPOSE

1.2 ROLES AND RESPONSIBILITIES

1.2.1 AUTHORIZING OFFICIAL (AO)

1.2.2 SECURITY CONTROL ASSESOR (SCA)

1.2.3 SECURITY CONTROL ASSESOR REPRESENTATIVE (SCAR)

1.2.4 VALIDATORS

1.2.5 ISSM

1.2.6 PM

1.2.7 ISO

1.3 RISK MANAGEMENT FRAMEWORK (RMF)

1.3.1 RISK VS. COMPLIANCE

2.0 DEFINITIONS

2.1 GENERAL

2.2 TYPES

2.2.1 TYPE I (STAND-ALONE SYSTEM – NO MEDIA)

2.2.2 TYPE II (STAND-ALONE SYSTEM – WITH MEDIA)

2.2.3 TYPE III (STAND-ALONE NETWORK)

2.2.4 TYPE IV (CLOSED/RESTRICTED NETWORK)

2.3 SPECIAL CONSIDERATIONS

2.3.1 WIRELESS

2.3.2 SENSORS

2.3.3 SIMPLEX/UNIDIRECTIONAL CONNECTIONS

2.4 SUPPLEMENTAL GUIDANCE

3.0 PROCESSES

3.1 SYSTEM DESIGN/DEVELOPMENT

3.1.1 CRN DESIGNATION APPROVAL

3.1.2 ENTERPRISE SECURITY SERVICE GUIDANCE

3.1.2.1 DoD Public Key Enabling (PKE)

3.1.2.2 Host Based Security System

3.1.2.3 Defense Enterprise Email

3.1.2.4 Assured Compliance Assessment Solution

3.1.2.5 Vulnerability Scanning

3.1.2.6 Ports, Protocols, and Services Management

3.1.3 LIFECYCLE PLANNING

3.2 SYSTEM REGISTRATION

3.2.1 DHA PORTFOLIO MANAGEMENT SYSTEM

iii

3.2.2 EMASS

3.3 ASSESS & AUTHORIZE

3.3.1 ASSESSMENT PROCEDURES

3.3.2 CONTROL APPROVAL CHAIN

3.3.3 PACKAGE APPROVAL CHAIN

3.3.4 AUTHORIZATION

3.4 RISK ASSESSMENT

3.4.1 RISK EQUATION

3.4.2 CRITICAL CONTROLS

3.4.2.1 Critical Security Concepts:

3.4.3 RESIDUAL RISK ACCEPTANCE

3.4.4 NOT APPLICABLE CONTROLS

APPENDIX A: REFERENCES

APPENDIX B: CRITICAL CONTROLS

APPENDIX C: DEFINITIONS

APPENDIX D: ACRONYM LIST

LIST OF TABLES

Table 1: FREQUENCY MATRIX

LIST OF FIGURES

Figure 1: LIKELIHOOD CALCULATION

Figure 2: RISK CALCULATION

FOR OFFICIAL USE ONLY

1.0 INTRODUCTION

1.1 PURPOSE

The purpose of this guide is to provide the operational procedures for authorizing Department of

Defense (DoD) Information Systems (IS) and Platform Information Technology (PIT) Systems (ref

(c)) that are physically or logically disconnected from the rest of the DoD Information Network

(DoDIN) or Medical Community of Interest (Med-COI). These systems pose minimal risk to the rest of the MED-COI.

Though disconnected, these DHA IS and PIT Systems are still required to proceed through the Risk

Management Framework (RMF) Assess and Authorize (A&A) process. The risks associated with these systems are generally limited to the system level and not the DoDIN/MED-COI level. This document is intended to provide cost and time savings by reducing the involvement of

DoDIN/MED-COI level activities for disconnected systems.

IT that does not meet the definitions of DoD IS or PIT Systems (e.g. PIT, IT Services, and IT

Products) is not required to follow the A&A process and therefore will generally not need to follow the guidance in this guide. Please see ref (c) for definitions of DoD IS, PIT Systems, PIT, IT

Services, and IT Products.

This guide is not intended to be used to determine if a system is DoD Information Technology (IT) or whether that DoD IT is a DoD IS or PIT. System categorization must already have been completed in accordance with ref (i).

This document will provide a way forward under the Risk Management Framework (RMF) to authorize Stand-alone Information Systems (SIS) and Closed/Restricted Networks (CRN). Owners of SIS and CRN are permitted to use the standard “full” A&A process instead of the process in this guide if they so choose. Additionally, if a system has a current authorization and it is determined that this guide may apply, it is not necessary to re-authorize using this guide until re-authorization

(6-9 months prior to ATD).

Nothing in this document alters or supersedes the existing authorities and policies of the Director of

National Intelligence regarding the protection of sensitive compartmented information (SCI), as directed by Executive Order 12333 and other laws and regulations. The application of the provisions and procedures of this document to information technologies processing SCI is encouraged where they may complement or cover areas not otherwise specifically addressed.

1.2 ROLES AND RESPONSIBILITIES

1.2.1 AUTHORIZING OFFICIAL (AO)

The AO retains all roles and responsibilities documented in DoDI 8510.01.

1.2.2 SECURITY CONTROL ASSESOR (SCA)

The SCA is responsible for performing all activities reserved for the SCA in DoDI 8510.01.

1.2.3 SECURITY CONTROL ASSESOR REPRESENTATIVE (SCAR)

The SCAR is responsible for reviewing A&A packages on behalf of the SCA to ensure that the package meets standards and to provide a summary recommendation on the control and system risk to the SCA.

1.2.4 VALIDATORS

The DHA Validator is responsible for validating the control assessment of the ISO/PM in the standard A&A process.

1.2.5 ISSM

The ISSM is responsible for performing all activities reserved for the ISSM in DoDI 8510.01. With the review and approval of the responsible AO, the ISSM is responsible for ensuring all products, services and PIT have completed the appropriate evaluation and configuration processes prior to incorporation into or connection to an IS or PIT system.

1.2.6 PM

The PM is responsible for performing all activities reserved for the ISSM in DoDI 8510.01.

1.2.7 ISO

The ISO is responsible for performing all activities reserved for the ISSM in DoDI 8510.01. In coordination with the ISSM and Program ISSM, is responsible for conducting a risk assessment for each vulnerability IAW the methodology described in Section 3.4.1, Risk Equation.

1.3 RISK MANAGEMENT FRAMEWORK (RMF)

The RMF created by National Institute of Standards and Technology (NIST) is a six-step process for managing risk across an enterprise. DoDI 8510.01 adopts its use as the DoD standard and process for assessing the risk of a system and authorizing the system for use within the DoDIN. One of the primary tenets of the RMF is the concept of risk analysis. Risk is determined not only by determining compliance with written standards, but also the relevance of threats to the system and the impact of vulnerabilities if exploited.

1.3.1 RISK VS. COMPLIANCE

This guide will outline the method for reasonably evaluating the risk associated with SIS and CRNs which may not meet the same security objectives as connected information systems. Given that

SIS and CRN operate in a disconnected environment, failure to meet certain security objectives may not dramatically increase the risk to the system. SIS and CRNs do not inherently have a larger tolerance for risk than connected systems. Rather, the disconnected nature of SIS and CRNs reduces the likelihood that vulnerabilities will be exploited, thereby significantly reducing the risk.

There are many different situations in which SIS or CRN are implemented. The system owner will need to consider the mission requirements and focus on the risk to the organization, assets, individuals, other organizations, and the Nation during the security categorization and security control selection process.

2.0 DEFINITIONS

2.1 GENERAL

A SIS or CRN has no external connectivity and does not have the ability to access network infrastructure (e.g. DoDIN, MED-COI, Internet) or services (e.g. Web services, DNS, enterprise email) other than for transport purposes and must utilize a DoD-approved encryption solution to ensure cryptographic isolation. It must be established in compliance with applicable DISA STIGs using FIPS 140-2 validated or NSA-approved encryption devices. It may host multiple connected systems to include servers and workstations that are not interconnected to any other network or system and do not transmit, receive, route, or interchange information outside the network such as a classroom topography or network training facility. The system management and maintenance devices for SIS and CRN systems, if not a part of the SIS or CRN system authorization, will be treated as connected unless artifacts from the RMF process properly document their SIS or CRN status as stated above.

SIS and CRN may be configured to process any information type but must be categorized like any other MHS IS in accordance with DoD, DHA, and NIST guidance. This includes applying all applicable overlays such as Classified or PII overlays. Any system intended to process SCI must refer to the Director of National Intelligence, Executive Order 12333, and all appropriate

Intelligence Community regulations.

The use of external media by SIS and CRN must be IAW all written DoD and DHA guidance (e.g.

CTO, DISA STIG).

2.2 TYPES

Lessons learned from the field have identified four separate types of information systems (IS) relevant to this guide. Stand-alone IS are identified by Type I, Type II, and Type III SIS and are all physically separate from all other networks. Type IV is cryptographically isolated CRN. SIS and

CRN are not externally connected to live operational networks such as the DREN, NIPRNet, SIPRNet, tactical networks, or other Government or commercial networks, except as noted in the following definitions.

2.2.1 TYPE I (STAND-ALONE SYSTEM – NO MEDIA)

A single IS that is not connected to any other system or network such as Internet, ISP, MED-COI, NIPRNet or SIPRNet. This IS must not transmit, receive, route, or interchange information outside of the system. A single purpose printer directly connected to the IS is acceptable; however, no other external media devices are approved for operation or configuration on this system type. The system must operate in a single mode: cleared for public distribution, sensitive but unclassified, or classified. If operating as a classified system, the classified system overlay must be applied. The system may be designed to process any information type, but all applicable overlays must be applied.

2.2.2 TYPE II (STAND-ALONE SYSTEM – WITH MEDIA)

A single information system that is not connected to any other system or network such as Internet, ISP, MED-COI, NIPRNet or SIPRNet is considered to be stand-alone. The IS must not transmit, receive, route, or interchange information outside of the system. The system may have removable or external media capability which includes but is not limited to electrically erasable/programmable flash media (for example, USB drives, and compact flash), external magnetic media (for example, floppy disk, and external hard drive) and optical drives (for example CD, CD-R), or a single purpose printer. As stated in section 2.1, all DoD guidance to include CTOs apply and JTF-GNO CTO 10-

004A, pertaining to removable flash media applies. The PM must ensure the implemented control set minimizes risk associated with having external media available and being handled by privileged users. The system must operate in a single mode: cleared for public distribution, sensitive but unclassified, or classified. If operating as a classified system, the classified system overlay must be applied. The system may be designed to process any information type, but all applicable overlays must be applied.

2.2.3 TYPE III (STAND-ALONE NETWORK)

An enclave consisting of multiple, interconnected devices which are not connected to any other system or network such as Internet, ISP, MED-COI, NIPRNet, or SIPRNet. A Type III IS must be physically isolated (i.e. “air-gapped”) from the network perspective and may include external media capability. The IS must not transmit, receive, route, or interchange information outside of the system except through external media. The system must operate in a single mode: cleared for public distribution, sensitive but unclassified, or classified. If operating as a classified system, the classified system overlay must be applied. The system may be designed to process any information type, but all applicable overlays must be applied. Type III SIS may be composed of two or more separately managed IS that fall under the purview of different AOs and are separately authorized to operate. In this case, all connected systems must otherwise qualify as a SIS or CRN and must be supported by Memoranda of Agreement (MOA), Service Level Agreements (SLA), or

Interconnection Security Agreements (ISA) that clearly define all parties’ security responsibilities, specifically including network isolation.

2.2.4 TYPE IV (CLOSED/RESTRICTED NETWORK)

A closed system enclave that is not logically connected to any other global system or network such as the Internet, commercial ISP, DREN, SDREN, NIPRNet, or SIPRNet, but cryptographically tunnels over one or more of these networks for transport purposes. The Type IV CRN traffic must be encrypted end-to-end over the transport network using DoD Approved cryptographic means (see ref (f)) appropriate to the information type being transported. Approved cryptography includes, but is not limited to Federal Information Processing Standard (FIPS) 140-2 accredited Internet Protocol

Security (IPsec) for FOUO information or NSA Type 1 encryption (e.g. TACLANE) for classified information. Tunneling/Routing protocols such as Multiprotocol Label Switching (MPLS) or

Generic Routing Encapsulation (GRE) may be used but only in conjunction with an approved encryption technology, as those generic routing technologies do not inherently provide security for confidentiality. The Type IV CRN must not receive ANY services from the transport network other than physical transport. The boundary or gateway device between the Type IV CRN and the transport network must be configured to prevent any traffic originating outside the Type IV CRN from interacting with the CRN. Likewise, the boundary or gateway device must prevent any traffic originating within the Type IV CRN from interacting with the transport (or any other) network.

Remote administration of the Type IV CRN from outside the Type IV CRN is not authorized.

The system must operate in a single mode: cleared for public distribution, sensitive but unclassified, or classified. If operating as a classified system, the classified system overlay must be applied.

The system may be designed to process any information type, but all applicable overlays must be applied. Type IV CRN may be composed of two or more separately managed IS that fall under the purview of different AOs and are separately authorized to operate. In this case, the system must be supported by MOA, SLA, or ISA that clearly define all parties’ security responsibilities. Non-cryptographic segregation techniques such as sub-netting or virtual local area network (VLAN) technologies do not provide adequate protections to consider a system or network to be a CRN.

Under no circumstances will non-cryptographic means be considered sufficient to designate a system or network as a Type IV CRN.

2.3 SPECIAL CONSIDERATIONS

2.3.1 WIRELESS

The use of wireless technologies does not preclude an IS from being designated a SIS or CRN.

However, wireless technologies must maintain the isolated nature of the SIS or CRN. In other words, wireless technology may be used internally to the SIS or CRN, but cannot connect to any device outside of the SIS or CRN. Wireless technology must prevent all devices not part of the

SIS or CRN from connecting. Any wireless used in a SIS or CRN must be implemented in accordance with all standing DoD instructions and NIST guides regarding wireless technologies.

All wireless transmissions must be encrypted using DoD approved cryptography.

2.3.2 SENSORS

Certain systems may be disconnected and yet utilize receive-only sensors such as barometric pressure sensors, thermometers, or GPS receivers. Receive-only sensors retrieve data about the physical world and are only capable of communicating with the SIS or CRN. Systems with receive-only sensors are authorized to be categorized as a SIS or CRN if those systems otherwise meet the

SIS or CRN definitions.

2.3.3 SIMPLEX/UNIDIRECTIONAL CONNECTIONS

The following section is for systems that meet one of the four definitions above except for a single, one-way data connection to the DoDIN, Internet, or other network. Data may flow into the SIS or

CRN or data may flow out of the SIS or CRN, but not both. These types of connections are called simplex or unidirectional connections.

Some systems may meet the definition of one of the SIS or CRN Types discussed above except for a simplex or unidirectional connection into or out of the system. Such connections are inconsistent with the explicit definition of a SIS or CRN. However, in the given instance, system or network, the unidirectional communication will be either out of the CRN or into the CRN, but NOT both. In the context of this definition, the term “connection” has the very specific meaning of one way data flow to a system or network with no return data flow. Since all data flowing out of or into the CRN is strictly unidirectional there is no bi-directional exchange of information so the normal definition of connection does not apply. Unidirectional communication consists of many signal types, which include, but are not limited to: unidirectional analog video, audio or telemetric signals, unidirectional digital video, audio, or telemetric signals, unidirectional serial communication, unidirectional

Internet Protocol data, unidirectional International Telecommunication Union data, etc. These systems must establish a secure one way boundary to mediate the data flow regardless of data type.

Generically this boundary is commonly referred to as a data diode or simplex bridge. A data diode consists of one or more devices that can both mediate the data flow and ensure that malicious code, viruses, etc. are not allowed to transit the boundary. The required assurance level for the data diode varies dramatically, depending on many variables. For instance, a system that is sending information from the DoDIN to a CRN potentially requires an assurance that the flow is unidirectional, where sending information from a CRN to the DoDIN requires the data is both unidirectional and is free from malicious code. Simple methodologies such as digital to analog conversion are sufficient in many scenarios. In other scenarios proxy servers with a full suite of antivirus and other malicious code detecting tools must screen the traffic prior to transmitting it.

The uses and implementations of unidirectional connections are unique. DHA Cybersecurity

Division must review all proposed instances of CRNs with unidirectional connections to determine the level of validation required. If DHA determines a more rigorous examination is required, one of the SCAR’s or DHA testing labs designed to analyze such implementations will be required, prior to the implementation of an approved solution. Requests must be submitted to the SCAR Functional leads.

https://info.health.mil/apps/HIT/services/SitePages/escMenu.aspx

2.4 SUPPLEMENTAL GUIDANCE

The SIS and CRN type definitions in this document were purposely constructed without the use of term Authorization Boundary because an Authorization Boundary is an administrative definition often centered on a Program Managed System or physical boundary (i.e. NEC) rather than a technical term to describe the logical entity of a SIS or CRN. However, that does not mean authorization boundaries are not important when establishing SIS or CRNs. This document was designed to balance the inherently reduced risks of SIS and CRNs with the standard Cybersecurity requirements of the DHA and DoD in an enterprise environment regardless of authorization boundaries.

There are several reasons this guide was published. First, typically, SIS and CRNs represent a lower risk to MHS information because they cannot be accessed from the large enterprise networks of the DoDIN (NIPR, SIPR, MED-COI, etc.) and commercial environment (Internet), thus reducing exposure. Because of these restrictions they also do not have access to normal

DoDIN services such as enterprise Active Directory (AD), Assured Compliance Assessment

Solution (ACAS), and Host Based Security System (HBSS), enterprise Anti-Virus (AV), enterprise Online Certificate Status Protocol (OCSP), etc. However, because SIS and CRN cannot access required enterprise services, their levels of compliance are reduced.

Therefore, the key to determining a SIS or CRN of any kind is the closed nature of the system.

In the past, limiting SIS and CRNs to one authorization boundary has resulted in the unintended consequence of excluding many systems that would otherwise fit into one of the defined categories. As an example within the simulation community, multiple program managers might bring separately authorized systems together to run a simulation on a SIS or CRN. Often there are only a few administrators that have access to these systems, therefore the exposure, except from insider threat, and are very low. However, care must be taken when bringing together separately authorized systems into one SIS or CRN. All parties must ensure that there are no external connections in one of the other systems. Also, since there is the potential for one or more parties to manipulate this system to relieve themselves of otherwise legitimate requirements, all parties need to be vigilant and ensure their security requirements are all reasonably similar. They must ensure that no one party is exposing the other separately authorized systems to undue risk.

Type IV CRNs are particularly problematic as they are designed to exist at multiple physical locations and might include multiple different authorization boundaries. In these situations, MOU’s/SLA’s must clearly define all parties’ security responsibilities. Typically, there should not be a significant difference between the various parties’ security requirements. Additionally, as an internal distributed network grows in physical/logical size, serious consideration must be given to implementing internal security controls with internal infrastructure, such as multifactor authentication, ACAS, HBSS, Centralized AV updates, etc. While there is no specific standard, CRNs that have more than 500 users must seriously consider implementing one or more of the services discussed above (e.g. HBSS, multifactor authentication, ACAS). In terms of authorization boundaries, this may mean that smaller separately authorized systems in the CRN will potentially need to use security/infrastructure services provided by the larger system(s).

Simply conglomerating a group of separately authorized systems into a giant CRN does NOT relieve system owners of the responsibility to implement otherwise required enterprise infrastructure, such as AD, multifactor authentication, HBSS, ACAS, AV, etc. This must always be a decision based on the risk analysis of the system including exposure of the system, severity of vulnerabilities in the system, the probability of exploitation of those vulnerabilities, and countermeasure practicality.

For further information on DoD risk analysis standards, please see ref (g) and the Risk

Management Framework Knowledge Service (https://rmfks.osd.mil/default.aspx).

3.0 PROCESSES

3.1 SYSTEM DESIGN/DEVELOPMENT

As with all Information Systems, SIS and CRN must have their security authorization path planned as early in development as possible. Be sure to consider the practical benefits and limitations of having a system disconnected from the DoDIN before setting down the path of a

SIS or CRN. This section will provide some guidance on the design of a system determined to be appropriate as a SIS or CRN.

Keep in mind that this is not a system or security engineering document. Please refer to the

NSA’s System Security Engineering Process, the Information Assurance Technical Framework, and NIST Cybersecurity Framework for more information on system and security engineering.

3.1.1 CRN DESIGNATION APPROVAL

The Information System Security Manager (ISSM) for a system must be involved early in the concept and design. They must provide input and assist with the decision making process when considering a SIS or CRN. However, the final approval for designating a system as a SIS or

CRN falls to the AO. Once the system concept is developed and has been registered in the

Enterprise Mission Assurance Support Service (eMASS), the ISO/PM will seek confirmation of the system’s designation as a CRN. This will be accomplished by processing a Security Plan

(SP) Approval Package in eMASS. The RMF roles must be assigned as documented in section

3.3.3. The system record in eMASS must be named in accordance with section 3.2.2. For detailed procedures on eMASS registration and the A&A process, please see the DHA A&A

Guide.

The Implementation plan will need to be completed for the record prior to processing an SP approval. The plan must be completed in accordance with standing RMF and eMASS guidance with the following caveat: There is no option under the eMASS Implementation Status for a control that the system owner does not plan to implement. Therefore, any control that the

ISO/PM does not intend to implement based on resource constraints, mission impact, or technical limitation must be marked as “Planned” in the Implementation Plan. The comments must state that the control will NOT be implemented and provide a rationale that explains why implementing that control will cause unacceptable degradation of mission or increase in project cost. The

Estimated Completion date must be set to approximately one year from the date that the

Implementation Plan is completed. Each “Planned to Not Implement” control must be reviewed during the annual security review required by the Federal Information Security Management Act

(FISMA). The review must determine if the rationale for not implementing the control is still valid and if so, the Estimated Completion date can be set to the next year. Controls that the

ISO/PM does not intend to implement must NOT be marked “Not Applicable”. It is important to note the Critical Controls list discussed in Section 3.4.2. The controls in this list cannot be

“Planned to Not Implement” without further mitigations beyond physical or cryptographic isolation.

In addition to the implementation plan, the following items must be included in the Artifacts section of the SP Approval Package:

• Concept of operation (CONOPS) o Information to be processed o Operating environment (logical and physical) o Data transfer to/from the SIS or CRN (reports extracted via CD’s, visual use only, physically printing data, etc.)

o Types of users on the system (Privileged / Regular users) o Expected number of users o Vulnerability Scanning/Reporting Plan o Public Key Infrastructure / Multifactor Authentication Plan o Other Special Security Considerations o Explanation of Risk Mitigations

• Detailed Architectural Diagram (Boundary)

• Detailed Hardware / Software Inventory Reports (these may only be conceptual if early in design process)

• System-Level Continuous Monitoring Plan

• Rationale for making the system a SIS or CRN (can be part of CONOPS)

• Any approvals for exceptions granted by MHS CIO/J-6 (e.g., Approval of Alternative

Multifactor Authentication Solution)

The PM/ISSM will then submit the package through the SP Package Approval Chain (PAC). It is critical that the PM/ISSM select the correct package type during this step. If the incorrect type is selected, the Validator must return the package.

Personnel in each stage of the PAC review the documentation, seeking clarification from the

PO/ISSM when necessary. If the system has already been built, partially or completely, the

PM/ISSM must physically/technically review the system itself. The review must address the following questions:

• Does the system meet the technical definition of SIS or CRN?

• Are there any special security concerns that are not addressed?

• Does the rationale support keeping the system disconnected?

• Does the rationale for non-planned controls support non-implementation?

NOTE: Please ensure that the above bulleted questions are addressed in the CONOPS.

If all stages approve, the AO will sign the SP Approval package. The following statement must be included in the comments section when the package is signed:

“I approve this system to be processed as a Type [#] [Stand-Alone Information

System / Closed/Restricted Network] given the intended implementation detailed in this Security Plan. Any changes to the Implementation Plan must be coordinated with the Program ISSM. Significantly changing the boundary or creating connections to another system not previously detailed in this

Security Plan will require a re-evaluation of the system status as a [Stand-

Alone Information System/Closed Restricted Network].”

NOTE: The SCA will forward the above comment to the AO.

3.1.2 ENTERPRISE SECURITY SERVICE GUIDANCE

Given the disconnected nature of SIS and CRN, certain enterprise services are not capable of being implemented on SIS or CRN. Forcing such systems to create connections to the DoDIN solely to reach enterprise services would dramatically increase the risk to the systems in question and the DoDIN in general.

Many of the regulations and orders requiring these services do not account for disconnected or isolated systems and cannot be overridden by an operational guide. Additionally, though access to the enterprise service may be impossible while maintaining isolation, the function that the enterprise service provides may still be necessary to protect the system. This section provides implementation guidance, not explicit requirements. Ultimately, the feasibility and benefit of implementing these security services is dependent on the system. However, the decision to implement a particular service or not must be backed by risk analysis, not just financial or operational considerations. As a guide cannot waive requirements, official waivers for the requirements must be sought by the ISO/PM when not implemented.

3.1.2.1 DoD Public Key Enabling (PKE)

Without a connection to the DoDIN, a SIS or CRN cannot implement multifactor authentication using the DoD Public Key Infrastructure (PKI) without significantly increased cost and complexity. Creating a dedicated or special link to the DoDIN for the sole purpose of reaching the DoD PKI would expose the SIS or CRN and the DoDIN to unnecessary risk. Therefore, IAW DoDI.8520.02 SIS and CRN are not required to implement DoD PKE.

DoDI.8520.02 applies to:

• “OSD, the Military Departments, the Office of the Chairman of the Joint Chiefs of Staff and the Joint Staff, the Combatant Commands, the Office of the Inspector General of the

Department of Defense, the Defense Agencies, the DoD Field Activities, and all other organizational entities within the DoD (hereinafter referred to collectively as the “DoD

Components”). DoDI 8520.02, May 24, 2011.”

• “All unclassified and classified DoD information systems and networks (e.g., Nonclassified Internet Protocol Router Network (NIPRNET), SIPRNET, Defense

Research and Engineering Network (DREN), Secret Defense Research and Engineering

Network (SDREN)), web servers, and e-mail systems).”

• “All users accessing unclassified and classified DoD information systems (e.g., DoD web-based systems, DoD websites, DoD web servers) and networks (e.g., NIPRNET, SIPRNET, DREN, SDREN).”

DoDI.8520.02 “does NOT apply to sensitive compartmented information and other information systems operated within the DoD that fall under the authority of the Director of National

Intelligence in accordance with Intelligence Community Directive 503 (Reference (i)). This

Instruction also does NOT apply to Top Secret collateral systems, special access programs, and stand-alone networks with no connection to the Global Information Grid (GIG).”

3.1.2.2 Host Based Security System

Host Based Security System (HBSS) is a centrally managed security suite of software applications used within the DoD to monitor, detect, and defend DoD IS. SIS and CRN are incapable of interacting with the central monitoring and reporting function of HBSS. However, there are other modules within the HBSS suite that can provide valuable security functions in a stand-alone mode.

Type I and II SIS are not generally capable of supporting a full HBSS implementation for the simple reason that HBSS requires a separate server. Adding a separate server would drastically change the topology of the system, most likely disqualifying that system from meeting the Type

I or II definitions. There are a number of modules that can potentially be implemented in a disconnected or stand-alone mode and will operate without an HBSS server. These modules provide host specific security features and may be desirable for reducing risk in some Type I and

II SIS.

According to the HBSS program manager the following modules can be implemented without an

HBSS server:

• Antivirus/Antispyware

• McAfee Agent

• Asset Baseline Monitor

• Device Control Module

• Host Intrusion Prevention System

These modules require regular updates that normally are distributed by the HBSS server.

Updating them in a stand-alone configuration may require special purpose scripting or procedures. Any ISO/PM intending to implement stand-alone modules should contact the HBSS program office for assistance.

Type III SIS and Type IV CRN are enclaves and are therefore technically capable of fully implementing HBSS including the server. The HBSS server would not be capable of connecting to MHS centralized HBSS reporting, but will still function to monitor the SIS or CRN and provide updates to the endpoints.

This guide has neither the authority nor intention of providing a blanket waiver or exemption from implementing HBSS. All SIS and CRN that determine that implementing HBSS in any fashion is infeasible and that the risks of doing so are acceptable must seek a waiver.

All SIS and CRN are encouraged to update the modules of HBSS at a frequency based on the

Frequency Matrix below. The frequency is determined by the SIS or CRN Type of the system and the system categorization high water mark. The high water mark is the highest impact level in the categorization of the system. For example, a SIS or CRN with a categorization of confidentiality – High, integrity – Low, and availability – Low would have a high water mark of

HIGH.

3.1.2.3 Defense Enterprise Email

SIS and CRN are not required or authorized to utilize Defense Enterprise Email (DEE). Creating a dedicated or special link to the DoDIN for the purpose of reaching DEE services would expose the SIS or CRN and the DoDIN to unnecessary risk.

3.1.2.4 Assured Compliance Assessment Solution

Type I and II SIS only constitute a single IS and generally cannot support implementing Assured

Compliance Assessment Solution (ACAS). Therefore Type I and II SIS are not recommended to implement ACAS as part of the boundary.

Type III SIS and Type IV CRN are capable of utilizing an instance of ACAS for vulnerability scanning. This scanner can either be an integral part of the authorization boundary or a separate scanning machine used for several different SIS and/or CRN. Instructions for implementing a stand-alone instance of ACAS can be found on the DoD Patch Repository

(https://patches.csd.disa.mil/) under ACAS > ACAS Software > ACAS Stand-alone Guidance.

Any ISO/PM intending to implement stand-alone modules should contact the ACAS program office for assistance. The ISO/PM must ensure that the scanner definitions file is up to date at the time of the scan.

The implementation of ACAS on a SIS or CRN must be determined early in the life cycle, recorded as part of the Security Plan, and approved by the AO. Waivers or exemptions for any deviations from written policy must be sought in accordance with those policies.

3.1.2.5 Vulnerability Scanning

SIS and CRN are encouraged to determine system vulnerabilities at a frequency based on the

Frequency Matrix below. The frequency is determined by the SIS or CRN Type of the system and the system categorization high water mark. The high water mark is the highest impact level in the categorization of the system. For example, a SIS or CRN with a categorization of confidentiality – High, integrity – Low, and availability – Low would have a high water mark of

HIGH.

The system vulnerabilities can be determined either via an automated scan or through manual review. If an automated scan is used, the ISO must ensure that the scanner’s definition file has been updated as of the date the scan is performed. If a manual review is used, the ISO must ensure that all hardware/software present in the system are reviewed for vulnerabilities. This includes any Commercial Off-the-Shelf (COTS) software included in the system such as

Microsoft Office or Adobe Acrobat. Regardless of assessment method, the system must be checked for vulnerabilities due to configuration IAW DISA STIGs and hardware/software design vulnerabilities IAW the DoD Information Assurance Vulnerability Management (IAVM)

Program ref (j).

A report containing all current vulnerabilities must be provided to the system ISSM and uploaded into the system eMASS record. The vulnerabilities must be assigned to security controls. The

ISO, in coordination with the ISSM and Program ISSM, will conduct a risk assessment for each vulnerability IAW the methodology described in section 3.4.1. A POA&M will be created and recorded in eMASS for each vulnerability based on the risk assessment.

Low Moderate High

Type I 1 year 6 months 90 days

Type II 1 year 6 months 60 days

Type III 6 months 90 days 30 days

Type IV 90 days 60 days 30 days

Table 1: FREQUENCY MATRIX

3.1.2.6 Ports, Protocols, and Services Management

Ports, Protocols, and Services Management (PPSM) registration is not required for Type I, II, and

III SIS. Any internal ports, protocols, and services (PPS) used within the SIS should recorded as part of the system documentation, but does not need to be reported to the PPSM office. Type

IV systems must complete PPSM registration to address PPS allowed via the encrypted tunnel.

3.1.3 LIFECYCLE PLANNING

The entire lifecycle of the system must be considered when designating a system as a SIS or

CRN. It must be determined whether the system will remain in its disconnected state permanently or if there are plans to connect to the DoDIN or Internet, for any reason, at some point in the future. Information System Owners (ISO) for tactical systems must be especially aware of the potential uses of a system “in-garrison” versus in the field.

If a system is planned to be connected at some point in the future, careful consideration must be made regarding the timeline of that potential connection and the A&A cycle. If a system will persist as a SIS or CRN for a significant period of time, it may make operational, financial, or security sense to authorize the system initially as a SIS or CRN and later pursue authorization as a standard Information System. If such a circumstance is applicable to a system, it must be recorded in the Security Plan.

3.2 SYSTEM REGISTRATION

3.2.1 DHA PORTFOLIO MANAGEMENT SYSTEM

DITPR registration is required for SIS and CRN. For information on DoD IT portfolio management, please see DoDI 8115.01. Be sure that all information fields shared between

DITPR and eMASS are consistent.

3.2.2 EMASS

The PM/ISSM role is the first level of the PAC will register all Stand-alone Information

System (SIS) and Closed/Restricted Network (CRN) systems into eMASS NIPRNet and

SIPRNet instances. Annotate the system as SIS or CRN [Type I, II, III, or IV] in the system name and in the system description field of the eMASS record during system registration.

This must be accomplished by adding “CRN – T#” or “SIS– T#” in parenthesis after the system acronym and system name during registration where the “#” is replaced with the appropriate number for the CRN Type as described in Section 2.2. System categorization (C-I-A), control baselines, and control overlays are selected in the same manner as normal systems. The eMASS system roles must be assigned in accordance with Sections 3.3.3 & 3.3.4 of this Guide.

If a CRN also meets the definition for a different class of IS with a specific naming convention, then the system may forego using the CRN…