Mobile Access Capability Package 2.6.0 PDF
Document Details
Uploaded by jmclark59
null
2024
Tags
Summary
This document details the Mobile Access Capability Package 2.6.0, providing a detailed overview of commercial solutions for classified mobile access. It outlines various updated requirements and modifications, including changes to specific sections like Continuous Monitoring, Key Management, and Enterprise Gray networks. This package aims to enhance the security and functionality of mobile access solutions.
Full Transcript
COMMERCIAL SOLUTIONS for CLASSIFIED (CSfC) Mobile Access Capability Package 2.6.0 Version 2.6.0 13 May 2024 CHANGE HISTORY Title Version Date Change Summary Commercial Solutions for 2.6...
COMMERCIAL SOLUTIONS for CLASSIFIED (CSfC) Mobile Access Capability Package 2.6.0 Version 2.6.0 13 May 2024 CHANGE HISTORY Title Version Date Change Summary Commercial Solutions for 2.6.0 13 May 2024 Changed requirements MA-2F-1 through Classified (CSfC) Mobile MA-2F-12 from Objective to T=O. Access (MA) Capability Package (CP) Table 35 Modification. MA-RD-17 Modifications. MA-CR-10 Withdrawn. MA-CR-16 Updated to T=O. MA-RD-13 Alternative Additions. MA-RD-31 New Requirement. MA-RD-32 New Requirement. Table 17 Modifications to include SHA512. MA-PS-25 Modifications. Renamed section 8 from Continuous Monitoring to Supporting Documents. Added section 8.1 Continuous Monitoring overview. Added section 8.2 Key Management overview. Added section 8.3 Enterprise Gray overview. Minor administrative changes were made in formatting, punctuation and glossary. Wireless Dedicated Outer VPN added for Tactical use case. All references to Two-Factor Authentication changed to Multi-Factor. All 2F requirements renamed to MFA. i Title Version Date Change Summary Commercial Solutions for 2.5.1 18 September 2021 Format Change. Classified (CSfC) Mobile Access (MA) Capability Package (CP) Commercial Solutions for 2.5 4 August 2021 Added section on Enhanced Isolation. Classified (CSfC) Mobile Access (MA) Capability Added section on Software Virtualization. Package (CP) Added section on Enhanced Hardware Isolation Requirements for Retransmission Devices. Updated Wireless Dedicated Outer VPN to just Dedicated Outer VPN as wireless is now prohibited. Updated Two Factor Authentication Requirements. Minor administrative changes were made in formatting and punctuation. Continuous Monitoring requirements moved to CSfC Continuous Monitoring Annex. Added Appendix F: EUD Configuration Options. Explicitly added Government Private Wired Network. CSfC MA CP 2.1 26 June 2018 Relocated Key Management Requirements from the CP to a separate “Key Management Requirements Annex.” Updated requirements to use “must” instead of “shall.” Minor administrative changes were made in formatting. Defined role of Security Administrator. ii Title Version Date Change Summary CSfC MA CP 2.0 November 2017 Updated based on stakeholder feedback to MA CP v1.8. Mandated use of Retransmission Device for all black transports except government private wireless and government private cellular. Moved Retransmission Device within CSfC solution boundary. Added objective mandatory access control requirements for EUD policy enforcement. Clarified requirements for EUD connecting to infrastructure supporting multiple security levels. Updated Test Requirements in new MA CP Annex. CSfC MA CP release for Public 1.8 March 2016 Added support for Multiple Security Levels. Comment Removed Option to terminate Inner Tunnel in the Red Network. Updated Continuous Monitoring architecture and requirements. Added support for EUDs with Dedicated Outer VPN with wireless connectivity to Computing Device. Relocated Threat Section to associated Risk Assessment document. Updated Key Management sections IAW CNSS AM 02-15. Temporarily removed Test Section; updated Test Section will be introduced in MA CP v2.0. iii Title Version Date Change Summary CSfC MA CP 1.1 19 June 2015 Minor update incorporating customer feedback. Corrected language in requirement MA- CR-9 and made consistent with the MA CP Compliance Matrix. CSfC MA CP 1.0 2 April 2015 Removed "Non-MDF Validated" EUD type. Removed EUD design using two VPN Gateways. Removed option to use separate computing platform with VPN Client installed to provide Outer layer of encryption. Changed restrictions on control plane traffic. Added Tactical Solution Implementation Appendix Added requirements for End User Device. Added requirements for RD. Commercial Solutions for 0.8 3 November 2014 Initial release of CSfC MA guidance for Classified (CSfC) Mobile public comment. Access (MA) Capability Package (CP) release for Incorporates End User Device (EUD) Public Comment Solution Designs from VPN version 3.0 CP. Incorporates content from Mobile Security Guide version 2.3. iv Table of Contents Introduction.......................................................................................................................................... 1 Purpose and Use................................................................................................................................... 2 Legal Disclaimer.................................................................................................................................... 3 Description of the Mobile Access Solution........................................................................................... 3 Networks....................................................................................................................................... 5 4.1.1 Red Network......................................................................................................................... 5 4.1.2 Gray Network........................................................................................................................ 6 4.1.3 Black Network....................................................................................................................... 6 4.1.4 Data, Management, and Control Plane Traffic..................................................................... 9 High-Level Design........................................................................................................................ 10 4.2.1 End User Devices................................................................................................................. 10 4.2.2 Independent Site................................................................................................................. 13 4.2.3 Multiple Sites...................................................................................................................... 14 4.2.4 Multiple Security Levels...................................................................................................... 15 Rationale for Layered Encryption............................................................................................... 16 Authentication............................................................................................................................ 17 4.4.1 Traditional Authentication.................................................................................................. 17 4.4.2 Multi-Factor Authentication............................................................................................... 17 4.4.2.1 Physical EUD........................................................................................................................ 18 4.4.2.2 Inner Encryption Component.............................................................................................. 18 4.4.2.3 Virtual Desktop Infrastructure (VDI)................................................................................... 18 Other Protocols........................................................................................................................... 18 Availability................................................................................................................................... 19 Infrastructure Components................................................................................................................ 19 Outer Firewall............................................................................................................................. 19 Outer VPN Gateway.................................................................................................................... 20 Gray Firewall............................................................................................................................... 20 Inner Firewall.............................................................................................................................. 21 Gray Management Services........................................................................................................ 21 5.5.1 Gray Administration Workstation....................................................................................... 22 v 5.5.2 Gray Security Information and Event Management (SIEM)............................................... 22 5.5.3 Gray Authentication Server................................................................................................. 22 Inner Encryption Components.................................................................................................... 23 5.6.1 Inner VPN Gateway............................................................................................................. 23 5.6.2 Inner TLS-Protected Server................................................................................................. 24 5.6.3 Inner SRTP Endpoint........................................................................................................... 24 Red Management Services.......................................................................................................... 25 5.7.1 Red Administration Workstations....................................................................................... 25 5.7.2 Red Security Information and Event Management (SIEM)................................................. 26 Public Key Infrastructure Components....................................................................................... 26 End User Device Components............................................................................................................. 26 EUD.............................................................................................................................................. 26 6.1.1 TLS Client............................................................................................................................. 27 6.1.2 SRTP Client.......................................................................................................................... 27 Enhanced Isolation...................................................................................................................... 28 6.2.1 Software Virtualization....................................................................................................... 28 6.2.2 Enhanced Hardware Isolation Requirements for Retransmission Device.......................... 29 Outer VPN Component............................................................................................................... 29 6.3.1 Dedicated Outer VPN.......................................................................................................... 29 6.3.2 Outer VPN Client................................................................................................................. 30 Mobile Access Configuration and Management................................................................................. 30 Solution Infrastructure Component Provisioning....................................................................... 30 EUD Provisioning......................................................................................................................... 31 Administration of Mobile Access Components........................................................................... 31 EUDs for Different Classification Domains.................................................................................. 32 Supporting Documents....................................................................................................................... 33 Continuous Monitoring............................................................................................................... 33 Key Management........................................................................................................................ 33 Enterprise Gray........................................................................................................................... 34 Data At Rest................................................................................................................................ 34 Requirements Overview..................................................................................................................... 35 vi Capabilities.................................................................................................................................. 35 Threshold and Objective Requirements..................................................................................... 36 Requirements Designators.......................................................................................................... 36 Requirements for Selecting Components........................................................................................... 37 Configuration Requirements............................................................................................................... 41 Overall Solution Requirements................................................................................................... 41 All VPN Components Configuration Requirements.................................................................... 42 Inner and Outer VPN Component Configuration Requirements................................................ 44 Inner VPN Components Requirements....................................................................................... 45 Outer VPN Components Requirements...................................................................................... 46 Multiple Security Level Requirements........................................................................................ 47 TLS-Protected Server & SRTP Endpoint Requirements............................................................... 48 Retransmission Device Requirements........................................................................................ 49 Enhanced Hardware Isolation Requirements............................................................................. 51 Connectivity to Dedicated Outer VPN Requirements................................................................. 51 End User Device Requirements................................................................................................... 52 Enhanced Virtualization Requirements...................................................................................... 58 Port Filtering Solution Components Requirements.................................................................... 59 Configuration Change Detection Requirements......................................................................... 61 Device Management Requirements........................................................................................... 61 Continuous Monitoring Requirements....................................................................................... 63 Wireless Intrusion Detection System/Wireless Intrusion Prevention System (WIDS/WIPS) Requirements.......................................................................................................................................... 63 Auditing Requirements............................................................................................................... 63 Key Management Requirements................................................................................................ 63 Multi-Factor Authentication Requirements................................................................................ 64 Solution Operation, Maintenance, and Handling Requirements....................................................... 65 Use and Handling of Solutions Requirements............................................................................ 65 Incident Reporting Requirements............................................................................................... 67 Role-Based Personnel Requirements.................................................................................................. 69 Information to Support The AO.......................................................................................................... 71 vii Solution Testing.......................................................................................................................... 72 Risk Assessment.......................................................................................................................... 73 Registration of Solutions............................................................................................................. 73 Appendix A. Glossary of Terms................................................................................................................... 75 Appendix B. Acronyms................................................................................................................................ 79 Appendix C. References.............................................................................................................................. 82 Appendix D. End User Device Implementation Notes................................................................................ 86 Appendix E. Tactical Solution Implementations......................................................................................... 95 Appendix F. EUD Configurations Options................................................................................................... 98 Table of Figures Figure 1. Overview of Mobile Access Solution.............................................................................................. 4 Figure 2. Acceptable Black Transport Networks........................................................................................... 8 Figure 3. EUD Solution Designs................................................................................................................... 11 Figure 4. EUDs Connected to Independent Site.......................................................................................... 13 Figure 5. Multiple Mobile Access Solution Infrastructures Supporting EUDs............................................ 14 Figure 6. Mobile Access Solution Supporting Multiple Security Levels...................................................... 15 Figure 7. Overview of Gray Management Services..................................................................................... 22 Figure 8. Overview of Red Management Services...................................................................................... 25 Figure 9. Solution Continuous Monitoring Point........................................................................................ 33 Figure 10. VPN EUD with Inner VPN Client and Separate Outer VPN Gateway......................................... 86 Figure 11. VPN EUD with Inner and Outer VPN Clients in Separate Virtual Machines with Retransmission Device.......................................................................................................................................................... 87 Figure 12. VPN EUD with Inner and Outer VPN Clients in Separate Virtual Machines without Retransmission Device................................................................................................................................ 88 Figure 13. TLS EUD with Separate Outer VPN Gateway............................................................................. 89 Figure 14. TLS EUD with Integrated Outer VPN Client with Retransmission Device.................................. 90 Figure 15. TLS EUD with Integrated Outer VPN Client without Retransmission Device............................. 91 Figure 16. Retransmission Device Connectivity.......................................................................................... 92 Figure 17. Mobile Access Solution Infrastructure Supporting VPN and TLS EUDs..................................... 93 Figure 18. Virtualization High Level Architecture....................................................................................... 94 viii List of Tables Table 1. Overview of Mobile Access CP Terminology................................................................................... 4 Table 2. Acceptable Black Transport Networks............................................................................................ 7 Table 3. Capability Designators................................................................................................................... 35 Table 4. Requirement Digraphs.................................................................................................................. 36 Table 5. Product Selection Requirements................................................................................................... 37 Table 6. Overall Solution Requirements..................................................................................................... 41 Table 7. Approved Commercial Algorithms (IPsec) for up to Top Secret................................................... 42 Table 8. Approved Commercial Algorithms for TLS up to Top Secret........................................................ 43 Table 9. Approved Commercial Algorithms for Wireless Connectivity....................................................... 43 Table 10. Approved Commercial Algorithms for SRTP up to Top Secret.................................................... 44 Table 11. Inner and Outer VPN Component Configuration Requirements................................................ 44 Table 12. Inner VPN Components Requirements....................................................................................... 45 Table 13. Outer VPN Components Requirements...................................................................................... 46 Table 14. Multiple Security Level Requirements........................................................................................ 47 Table 15. TLS-Protected Server & SRTP Endpoint Requirements............................................................... 48 Table 16. Retransmission Device Requirements......................................................................................... 49 Table 17. Enhanced Hardware Isolation Requirements............................................................................. 51 Table 18. Connectivity to Dedicated Outer VPN Requirements................................................................. 52 Table 19. End User Device Requirements................................................................................................... 52 Table 20. Enhanced Virtualization Requirements....................................................................................... 58 Table 21. Port Filtering Solution Components Requirements.................................................................... 59 Table 22. Configuration Change Detection Requirements......................................................................... 61 Table 23. Device Management Requirements............................................................................................ 61 Table 24. Continuous Monitoring Requirements....................................................................................... 63 Table 25. WIDS/WIPS Requirements.......................................................................................................... 63 Table 26. Auditing Requirements............................................................................................................... 63 Table 27. Key Management Requirements................................................................................................. 63 Table 28. Multi-Factor Authentication Use Case Requirement.................................................................. 64 Table 29. Use and Handling of Solutions Requirements............................................................................. 65 Table 30. Incident Reporting Requirements............................................................................................... 68 ix Table 31. Role-Based Personnel Requirements.......................................................................................... 71 Table 32. Test Requirement........................................................................................................................ 73 Table 33. Tactical Implementation Overlay Requirements........................................................................ 96 Table 34. WPA3 Encryption and EAP-TLS (Approved Algorithms).............................................................. 97 Table 35. EUD Configuration Options Retransmission Device MA-RD....................................................... 98 Table 36. EUD Configuration Options Dedicated outer VPN...................................................................... 99 x INTRODUCTION The Commercial Solutions for Classified (CSfC) Program within the National Security Agency’s (NSA) Cybersecurity Directorate (CSD), publishes Capability Packages (CPs) to provide configurations that empower NSA customers to implement secure solutions using independent, layered Commercial Off- the-Shelf (COTS) products. The CPs are product-neutral and describe system-level solution frameworks documenting security and configuration requirements for customers and/or Integrators. The NSA delivers this CSfC Mobile Access (MA) CP to meet the demand for mobile data in transit solutions (including Voice and Video) using approved cryptographic algorithms and National Information Assurance Partnership (NIAP) evaluated components. These algorithms, known as the Commercial National Security Algorithm (CNSA) suite, are used to protect classified data using layers of COTS products. In MA CP Version 2.1 and future versions, the Key Management Requirements have been relocated from this CP to a separate CSfC Key Management Requirements Annex. MA CP Version 2.6.0 takes lessons learned from solution support, a testing environment, and a CSfC Initial Solution that implemented secure voice and data capabilities using the CNSA suite, modes of operation, standards, and protocols. While CSfC encourages industry innovation, trustworthiness of the components is paramount. Customers and their Integrators are advised that modifying a NIAP-validated component in a CSfC solution may invalidate its certification and require a revalidation process. To avoid delays, customers and integrators who feel it is necessary to modify a component should engage the component vendor and consult NIAP through their Assurance Continuity Process (https://www.niap- ccevs.org/Documents_and_Guidance/ccevs/scheme-pub-6.pdf) to determine whether such a modification will affect the component’s certification. In case of a modification to a component, NSA’s CSfC Program Management Office (PMO) requires a statement from NIAP that states the modification does not alter the certification, or the security of the component. Modifications that trigger the revalidation process include, but not limited to: configuring the component in a manner different from its NIAP-validated configuration, and modifying the Original Equipment Manufacturer’s code (to include digitally signing the code). Mobile communication systems (i.e., cellular, Wi-Fi, etc.) are inherently risky. The CSfC Mobile Access (MA) Capability Package (CP) Version 2.6.0 was developed and approved by the National Manager as a commercial strategy suitable for protecting classified information and National Security Systems (NSS), provided the customer’s implementation of the solution is configured, maintained, and monitored as required by the CP. The residual risks for this CP are documented in the MA CP Version 2.6.0 Risk Assessment. The National Manager is responsible for ensuring that the design documented in the CP is sufficiently robust to protect classified information and NSS. The Government Authorizing Official (AO) assumes the risk for implementing and deploying the solution in accordance with the requirements in the CP. The AO must consider the operational environment and provide appropriate usage guidance to End Users. End Users must understand the risks and adhere to handling requirements established by the AO for the fielded MA CP system. End Users must maintain positive physical control of the End User device. Further, End Users should consider their environment and ensure adequate physical standoff to 1 mitigate threats associated with physical proximity. (Recommend a standoff distance of at least 15 feet.) PURPOSE AND USE This CP provides high-level reference designs and corresponding configuration requirements that allow customers to select COTS products from the CSfC Components List, available on the CSfC web page (https://www.nsa.gov/resources/commercial-solutions-for-classified-program), for their MA solution and properly configure those products to achieve a level of assurance sufficient to protect classified data while in transit. As described in Section 10, customers must ensure that the components selected from the CSfC Components List provide the necessary functionality for the selected capabilities. To successfully implement a solution based on this CP, all Threshold (T) Requirements, or the corresponding Objective (O) Requirements applicable to the selected capabilities, must be implemented, as described in Sections 9 and 11. Customers who want to use this CP must register their solution with the NSA. Additional information about the CSfC process is available on the CSfC web page (https://www.nsa.gov/resources/commercial- solutions-for-classified-program). This CP will be reviewed twice a year to ensure that the defined capabilities and other instructions still provide the security services and robustness required. Solutions designed according to this CP must be registered with the NSA. Once registered, a signed Deputy National Manager (DNM) Approval Letter will be sent validating that the MA solution is registered as a CSfC solution validated to meet the requirements of the latest MA CP and is approved to protect classified information. Any solution designed according to this CP may be used for one year and must then be revalidated against the most recently published version of this CP. Top Secret Solutions will be considered on a case-by-case basis. Customers are encouraged to engage their Client Advocate or the CSfC PMO team early in the process to ensure the solutions are properly scoped, vetted, and that the customers have an understanding of risks and available mitigations. Please provide comments on usability, applicability, and/or shortcomings to your NSA Client Advocate and the MA CP Maintenance Team at [email protected]. MA CP solutions must also comply with the Committee on National Security Systems (CNSS) Policies and Instructions. Any conflicts identified between this CP and the CNSS or local policy should be provided to the MA CP Maintenance Team. For any additional information on Cross Domain Solutions (CDS) contact the National Cross Domain Strategy Management Office (NCDSMO) at [email protected] Customers and integrators must adhere to all applicable data transfer policies for their organization when designing and implementing these capabilities within their CSfC solution architecture. For example DoD customers must follow DoDI 8540.01 when deploying a CDS within a CSfC solution and if any discrepancies are found between the guidance in this document and DoDI 8540.01 report according to the instruction found in this section. 2 LEGAL DISCLAIMER This CP is provided “as is.” Any express or implied warranties, including but not limited to, the implied warranties of merchantability and fitness for a particular purpose are disclaimed. In no event must the United States Government be liable for any direct, indirect, incidental, special, exemplary or consequential damages (including, but not limited to, procurement of substitute goods or services, loss of use, data, or profits, or business interruption) however caused and on any theory of liability, whether in contract, strict liability, or tort (including negligence or otherwise) arising in any way out of the use of this CP, even if advised of the possibility of such damage. The user of this CP agrees to hold harmless and indemnify the United States Government, its agents and employees from every claim or liability (whether in tort or in contract), including attorney’s fees, court costs, and expenses, arising in direct consequence of Recipient’s use of the item, including, but not limited to, claims or liabilities made for injury to or death of personnel of User or third parties, damage to or destruction of property of User or third parties, and infringement or other violations of intellectual property or technical data rights. Nothing in this CP is intended to constitute an endorsement, explicit or implied, by the U.S. Government of any particular manufacturer’s product or service. DESCRIPTION OF THE MOBILE ACCESS SOLUTION This CP describes a general MA solution to protect classified information as it travels across either an untrusted network or a network consisting of multiple classification levels. The solution supports connecting end-user devices (EUDs) to a classified network via two layers of encryption terminated on the EUD provided that the EUD and the network operate at the same security level. The MA solution uses two nested, independent tunnels to protect the confidentiality and integrity of data (including voice and video) as it transits the untrusted network. The MA solution uses Internet Protocol Security (IPsec) as the Outer Tunnel and, depending on the solution design, IPsec or Transport Layer Security (TLS) as the Inner layer of protection. Throughout this CP, the term “Inner Encryption Component” is used to refer generically to the component (device or software application) that terminates the Inner layer of encryption. An Inner Encryption Component can be a virtual private network (VPN) Component or a TLS Component that is in the infrastructure or part of an EUD. The term “VPN Component” refers generically to both VPN Gateways and VPN Clients in situations where the differences between the two are unimportant. The term “TLS Component” is used to denote a component that implements TLS between the infrastructure (TLS-Protected Server or Secure Real-time Transport Protocol (SRTP) Endpoint) and EUDs (TLS Client or SRTP Client) in accordance with this CP (see Sections 5.6.2 and 5.6.3 respectively). There are two EUD solution designs: VPN EUD and TLS EUD. The term “EUD” is used to refer generically to both designs where the differences between them are unimportant. Finally, the term “Dedicated Outer VPN” is used to describe a dedicated piece of hardware that can be part of an EUD and terminates the Outer layer of IPsec encryption. 3 Table 1. Overview of Mobile Access CP Terminology Component VPN EUD TLS EUD Inner Encryption IPsec provided by VPN Client TLS or SRTP provided by TLS-Protected Component Server, SRTP Endpoint, TLS Client, OR SRTP Client Outer Encryption IPsec provided by Dedicated IPsec provided by Dedicated Outer VPN Component Outer VPN OR VPN Client OR VPN Client Figure 1. Overview of Mobile Access Solution As shown in Figure 1, before being sent across the untrusted network, classified data is encrypted twice: first by an Inner Encryption Component, and then by an Outer VPN Component. At the other end of the data flow, the received packet is correspondingly decrypted twice: first by an Outer VPN Component, and then by an Inner Encryption Component. All Encryption Components are within the CSfC Solution Boundary. The MA CP Version 2.0 and future versions, no longer allows the use of existing Classified Enterprise Network Encryption Components to provide the Inner layer of protection. MA solution components are managed using Red Management Services for Inner Encryption Components and Gray Management Services for Outer Encryption Components. The Gray Management Services include an administration workstation, a Gray firewall, a Security Information and Event Management (SIEM) Component, Intrusion Detection System (IDS)/Intrusion Prevention System (IPS) and any additional components located between the Outer VPN Gateway and Inner Encryption Components. Gray Management Services may also include a locally run Outer Certification Authority (CA), Certificate Revocation List (CRL), CRL Distribution Point (CDP), and/or authentication server. The Red Management Services include an administration workstation, an Inner Firewall, and other components within the Red Network. The Red Management Services may also manage a locally run Inner Tunnel CA and, optionally, a locally-run Outer Tunnel CA. In addition, the MA CP allows customers 4 to leverage an existing Enterprise Public Key Infrastructure (PKI) to issue certificates to Outer VPN Components and Inner Encryption Components. To use an existing Enterprise Root CA at least two separate subordinate CAs must be used: one to issue Certificates for Outer VPN Components and the other to issue certificates for Inner Encryption Components. The EUDs used within the MA CP are form-factor agnostic. They include smart phones, tablets, and laptops. An MA CP EUD can be composed of multiple physical devices (e.g., a Dedicated Outer VPN and a Computing Device) all collectively referred to as the EUD. Although the CP allows flexibility in the selection of the EUD, customers and Integrators must ensure that EUDs meet all applicable requirements for the planned solution design. Section 4.2.1 describes in detail the differences between the VPN EUD and TLS EUD solution design options. The MA CP instantiations are built using products from the CSfC Components List (see Section 10). Customers who are concerned that their desired products are not yet on the CSfC Components List are encouraged to contact the appropriate vendors and encourage them to sign a Memorandum of Agreement with NSA and commence evaluation against a NIAP approved Protection Profile using the CSfC mandated selections which will enable them to be listed on the CSfC Components List. NIAP Certification alone does not guarantee inclusion on the CSfC Components List. Products listed on the CSfC Components List are not guaranteed to be interoperable with all other products on the CSfC Components List. Customers and integrators should perform interoperability testing to ensure the components selected for their MA Solution are interoperable. If you need assistance obtaining vendor Point of Contact information, please email [email protected]. NETWORKS This CP uses the following terminology to describe the various networks that compose an MA solution and the types of traffic present on each: Red, Gray, and Black. The terms Red, Gray, and Black refer to the level of protection applied to the data as described below. 4.1.1 RED NETWORK Red data consists of unencrypted classified data and a Red Network contains only Red data. Red Networks are under the control of the solution owner or a trusted third party. The Red Network begins at the internal interface(s) of Inner Encryption Components located between the Gray Firewall and Inner Firewall. EUDs access the Red Network through the two layers of nested encryption described in this CP. For example, an Inner VPN Gateway located between the Gray Firewall and Inner Firewall terminates the Inner layer of IPsec encryption from a VPN EUD. Once a successful IPsec connection is established, the EUD is given access to classified services such as web, email, Virtual Desktop Infrastructure (VDI), voice, etc. In some instances, when the MA infrastructure is designed to support TLS EUDs, the TLS-Protected Server or SRTP Endpoint, which terminates the Inner layer of encryption, will implement a TLS-Protected Server that includes both Gray and Red Network interfaces located between the Gray Firewall and Inner Firewall. This TLS-Protected Server terminates the TLS connection from the EUD and acts as a proxy to Red Services located outside of the CSfC Solution Boundary. 5 If using user client certificate authentication for the services in your enterprise Red Network, then the Inner TLS-Protected Server acting as a TLS proxy option is NOT recommended. The Inner VPN Gateway option is best in this case. The Inner TLS-Protected Server acting as a TLS proxy option is viable if the services in your enterprise Red Network are using TLS Server Authentication only or are clear text. Please note that the TLS certificate on the TLS EUD that is used to connect to the Inner TLS-Protected Server is a non-person entity (NPE) certificate. Another use case for the Inner TLS-Protected Server option is replicated services on the gray/red boundary. In this case a user certificate is allowable, but a NPE certificate is still preferred. A similar situation exists for SRTP when using a Voice over Internet Protocol (VoIP) Gateway/Border Controller to terminate the SRTP traffic for an EUD and relaying the data to the Red Network. Since a VoIP Gateway/Border Controller, located between the Gray Firewall and the Inner Firewall, terminates the Inner layer of SRTP desktop phones in the Red Network are not included in the Solution Boundary. Red Networks may only communicate with an EUD through the MA solution if both operate at the same security level. 4.1.2 GRAY NETWORK Gray data is classified data that has been encrypted once. Gray Networks are composed of Gray data and Gray Management Services. Gray Networks are under the physical and logical control of the solution owner or a trusted third party. The Gray Network is physically treated as a classified network even though all classified data is singly encrypted. If a solution owner’s classification authority determines that data on a Gray Network is classified, perhaps by determining the Internet Protocol (IP) addresses are classified at some level, then the MA solution described in this CP cannot be implemented, as it is not designed to provide two layers of protection for any classified information on the Gray Network. Gray Network components consist of the Outer VPN Gateway, Gray Firewall, and Gray Management Services. All Gray Network components are physically protected at the same level as the Red Network components of the MA infrastructure. Gray Management Services are physically connected to the Gray Firewall and include, at a minimum, an administration workstation. The Gray Management Services also includes a SIEM unless the SIEM is implemented in the Red Network in conjunction with a CDS (refer to CSfC Continuous Monitoring Annex as referenced in Section 8.1). The MA CP requires the management of Gray Network components through the Gray administration workstation. As a result, neither Red nor Black Administration Workstations are permitted to manage the Outer VPN Gateway, Gray Firewall, or Gray Management Services. Additionally, the Gray administration workstation is prohibited from managing Inner Encryption Components. These Inner Encryption Components must be managed from a Red Administration workstation. 4.1.3 BLACK NETWORK Black data is classified data that has been encrypted twice. The network connecting the Outer VPN Components together is a Black Network. Black Networks are not necessarily, and often will not be under the control of the solution owner and may be operated by an untrusted third party. 6 The MA CP allows EUDs to operate over any Black Network when used in conjunction with a Government-owned Retransmission Device (RD) or a physically separate Dedicated Outer VPN to establish the Outer IPsec Tunnel. The government-owned RD is a category of devices that includes Wi-Fi hotspots and mobile routers. On the external side, the RD can be connected to any type of medium (e.g., cellular, Wi-Fi, SATCOM, Ethernet) to gain access to a Wide Area Network (WAN). On the internal side, the RD is connected to EUDs either through an Ethernet cable or Wi-Fi. When the RD is a Wi-Fi access point connected to the EUD (or multiple EUDs), the Wi-Fi network must implement Wi-Fi Protected Access II (WPA2) with Pre- Shared Key (PSK). The EUD must be configured to only permit connections to authorized RDs. RDs are only permitted to establish connectivity to the Black Network, and may not be placed between an Outer Encryption Component and Inner Encryption Component. The CP also allows connectivity without the use of an RD or Dedicated Outer VPN if any of the following transport networks are used: Government Private Cellular Networks or Government Private Wireless Networks or Government Private Wired Networks. Government Private Cellular Networks are defined as cellular base stations that are owned and operated exclusively by the U.S. Government (such as in tactical environments). Government Private Wireless Networks denote Wi-Fi connectivity by a Wireless Local Area Network (WLAN) accredited by an AO. These Wi-Fi networks must comply with applicable organization policies. Within the Department of Defense (DoD) the applicable policy is DoD Instruction (DoDI) 8420.01. At a minimum, these Wi-Fi networks must implement WPA2 with PSK; however, WPA2 with certificate-based authentication is preferred for all use cases. When Government Private Wireless Networks use certificate-based authentication, they cannot share the Outer Tunnel CA or Inner Tunnel CA certificate Management Services. WPA2 between the RD and EUD protects the Black Transport Network, but does not count as one of the layers of CSfC data-in-transit encryption. A Wireless Intrusion Detection System (WIDS) is required if a Government Private Wireless Networks is used within the solution. A Wireless Intrusion Prevention System (WIPS) should also be considered. For requirements and information on WIDS and WIPS see the CSfC Wireless Intrusion Detection System (WIDS)/Wireless Intrusion Prevention System (WIPS) Annex. Government Private Wired Networks are hardwired networks that are accredited by an AO. Table 2. Acceptable Black Transport Networks VPN EUD TLS EUD Any Black Transport Network Government RD OR Dedicated Government RD OR Outer VPN Dedicated Outer VPN Government Private Cellular No additional requirements No additional requirements or Government Private Wireless or Government Private Wired 7 Figure 2. Acceptable Black Transport Networks As shown in Figure 2, both EUD designs can connect to the MA solution over Government Private Cellular or Government Private Wireless Networks or Government Private Wired Networks without the need for a separate Dedicated Outer VPN or RD. When connecting over any other Black Transport Network, EUDs must use a Dedicated Outer VPN or a Government RD to connect to the MA solution. When an EUD includes a Dedicated Outer VPN, that VPN is used to establish the Outer layer of IPsec to the government infrastructure and is included within the CSfC Solution Boundary. The Dedicated Outer VPN must be connected to the computing platform using an Ethernet cable (see Sections 11.10 and 11.11). The computing platform then terminates the Inner layer of encryption. Although only required as described above, a Dedicated Outer VPN can be used to connect to any transport network for any of the EUD solution designs. Similarly, an EUD can use a Government RD to connect to any transport network. The Government RD is part of the CSfC Solution Boundary, and acts as an intermediary between the desired transport network and the EUD and is to be protected from unauthorized use and tampering. Similar to the Government RD, the Dedicated Outer VPN must be protected from unauthorized use and tampering. 8 4.1.4 DATA, MANAGEMENT, AND CONTROL PLANE TRAFFIC Data plane traffic is classified information, encrypted or not, that is being passed through the MA solution. The MA solution exists to encrypt and decrypt data plane traffic. All data plane traffic within the Black Network is encapsulated within an Outer layer of Encapsulating Security Payload (ESP) and either a second layer of ESP or a layer of TLS or SRTP. All data plane traffic within the Gray Network is encapsulated within ESP, TLS, or SRTP. Management plane traffic is used to configure and monitor solution components. It includes the communications between an Information System Security Officer (ISSO) and a component, as well as the logs and other status information forwarded from a solution component to a SIEM or similar repository. Management plane traffic on Red and Gray Networks must be encapsulated within the Secure Shell (SSH), ESP, or TLS protocol. Control plane traffic consists of standard protocols necessary for the network to function. Unlike data or management plane traffic, control plane traffic is typically not initiated directly on behalf of a user or an ISSO. Examples of control plane traffic include, but are not limited to, the following: Network address configuration (i.e., Dynamic Host Configuration Protocol (DHCP), Neighbor Discovery Protocol (NDP), etc.) Address resolution (i.e., Address Resolution Protocol (ARP), NDP, etc.) Name resolution (e.g., Domain Name System (DNS)) Time synchronization (i.e., Network Time Protocol (NTP), Precision Time Protocol (PTP), etc.) Route advertisement (i.e., Routing Information Protocol (RIP), Open Shortest Path First (OSPF), Intermediate System to Intermediate System (IS-IS), Border Gateway Protocol (BGP), etc.) Certificate status distribution (i.e., Online Certificate Status Protocol (OCSP), HTTP download of CRLs, etc.) The MA CP explicitly prohibits the use of most control plane traffic for EUDs that use a single Computing Device to provide both the Inner and Outer layers of encryption. The MA CP does not allow route advertisement or certificate status distribution to ingress/egress from the Black Transport Network for these EUDs. As a result, the implementing organization must implement procedures to handle a situation in which the certificate of an Outer VPN Gateway is revoked. EUDs are configured for all IP traffic to flow through the Outer IPsec VPN Client with the exception of control plane protocols necessary to establish the IPsec tunnel. The control plane necessary to establish the IPsec tunnel is limited to Internet Key Exchange (IKE), address configuration, time synchronization, and in some cases name resolution traffic. EUDs selected from the CSfC Components List use NIAP evaluated configurations to ensure that IP traffic flows through the Outer IPsec VPN Client. Upon establishing the Outer VPN tunnel, the CP does not impose detailed requirements restricting control plane traffic in the Gray and Red Networks. 9 Restrictions are also placed on control plane traffic for the Outer VPN Gateway. The Outer VPN Gateway is prohibited from implementing routing protocols on external and internal interfaces. The Outer VPN Gateway must rely on the Outer Firewall to implement any dynamic routing protocols. Except as otherwise specified in this CP, the use of specific control plane protocols is left to the solution owner to approve. The solution owner must disable or drop any unapproved control plane protocols. Data plane and management plane traffic are generally required to be separated from one another by using physical or cryptographic separation. Use of a Virtual Local Area Network (VLAN) alone is not sufficient to separate data plane and management plane traffic. As a result, a solution may, for example, have a Gray data network and a Gray Management network that are separate from one another, where the components on the Gray Management network are used to manage the components on the Gray data network. The Gray Management network is separated from the Gray data network via the Gray Firewall. The Gray Firewall uses an Access Control List (ACL) to ensure that only appropriate Gray Management Services (i.e., administration workstation, SIEM or Network Time Server) can communicate with the Outer VPN Gateway. The Gray Firewall is also responsible for ensuring that Gray Management Services are only capable of flowing in the appropriate direction. For example, SSH traffic is permitted to initiate from an administration workstation to the Outer VPN Gateway, but not from the Outer VPN Gateway to any Gray Management Services. Conversely, system log data is permitted from the Outer VPN Gateway to the Gray SIEM, but is not permitted from the Gray Management Services to the Outer VPN Gateway. Given that some control plane traffic is necessary for a network to function, there is no general requirement that control plane traffic be similarly separated, unless otherwise specified. HIGH-LEVEL DESIGN The MA solution is adaptable to support multiple capabilities, depending on the needs of the customer implementing the solution. The supported EUD capabilities are mutually exclusive; if a customer chooses to implement an EUD using two layers of IPsec, then the Inner TLS Client would not be included as part of that EUD implementation. Similarly, if a customer only needs a secure voice capability, then the Inner IPsec Component would not be included as part of that EUD implementation. Although the EUD solution designs are mutually exclusive, the infrastructure may be configured to support both EUD solution designs (see Appendix D). This enables implementation of both types of EUDs based on use cases and device features. Any implementation of the MA solution must satisfy all of the applicable requirements specified in this CP, as explained in Sections 10 and 11. 4.2.1 END USER DEVICES This CP uses the concept of an EUD, which is either a single Computing Device, such as a smart phone, laptop, or tablet, or the combination of the Computing Device and a Dedicated Outer VPN. The EUD provides two layers of protection for data in transit to tunnel through the Black Network and access classified data on the Red Network. In some instances, an EUD encompasses more than one piece of hardware (e.g., Computing Device and Dedicated Outer VPN) each of which perform a layer of encryption. Where more than one piece of hardware is used, each component is included as part of the EUD and are within the CSfC Solution Boundary. EUDs are dedicated to a single classification level and can only be used to access a Red Network of the same classification. There are two EUD designs which 10 can be implemented as part of an MA solution. Each of the EUD designs share many requirements in common, but also have unique requirements specific to that design: 1) IPsec-IPsec (VPN EUD): Uses two IPsec tunnels to connect to the Red Network. Such an EUD includes both an Inner VPN Client and Outer VPN Component to provide the two layers of IPsec. Throughout the document this EUD design is referred to as the “VPN EUD.” VPN EUDs can be implemented using combinations of IPsec VPN Clients and IPsec Gateways (see Appendix D). For example, a VPN EUD can be implemented on a Computing Device with two VPN Clients running on separate IP stacks. Similarly, the MA CP allows a VPN EUD to use a Dedicated Outer VPN to provide the Outer layer of IPsec encryption and a VPN Client installed on a Computing Device to provide the Inner layer of encryption. 2) IPsec-TLS (TLS EUD): Uses an Outer layer of IPsec encryption and an Inner layer of TLS encryption to access the Red Network. Throughout the document this EUD design is referred to as the “TLS EUD.” The Outer layer of encryption can be provided by either an IPsec VPN Client or a Dedicated Outer VPN. The Inner layer of encryption is then provided by a TLS Client. The EUD TLS Client includes a number of different options which can be selected, in accordance with the CP requirements, to meet the operational needs of the customer. The EUD TLS Clients include, but are not limited to, web browsers, email clients, and VoIP applications. Traffic between the TLS EUD Client and the TLS-Protected Server is encrypted with TLS or in some instances SRTP. Figure 3. EUD Solution Designs 11 Figure 3 shows the two EUD solution designs available as part of the MA CP. In each design the Outer VPN Component is used to establish an IPsec tunnel to the Outer VPN Gateway of the MA solution infrastructure. In either EUD design, this Outer VPN Component must be selected from the CSfC Components List and could be either a VPN Client or a Dedicated Outer VPN. If a Dedicated Outer VPN is used to provide the Outer IPsec tunnel, then the computing platform must be connected to the Dedicated Outer VPN using an Ethernet cable. The Inner layer of encryption for VPN EUDs is provided by a VPN Client. The Inner VPN Client must be selected from the CSfC Components List (see Section 10). If VPN Clients are used for both the Inner and Outer layers of encryption then they must use a different IP stack, and are generally implemented using virtualization. The Inner layer of encryption for TLS EUDs is provided by either TLS or SRTP. Every application that performs TLS or SRTP must be selected from the CSfC Components List. The MA CP allows three different deployment options pertaining to the use and handling of an EUD while powered off: 1. EUD with DAR: To implement Data-at-Rest (DAR) on an EUD, the DAR solution must be approved by NSA – either as compliant and registered with NSA’s DAR CP or approved as a tailored solution for the protection of information classified at the level of the Red Network connected to the EUD. Specification of such a DAR solution is outside the scope of this CP, but can be found in the DAR CP. Continuous physical control of the EUD must be maintained at all times. 2. Classified EUD: The EUD can only be used when applying physical security measures approved by the AO. EUDs are not subject to special physical handling restrictions beyond those applicable for classified devices as they can rely on the environment they are used within for physical protection. If this design option is selected, then the EUDs must be treated as classified devices at all times. The EUD in this case must enable the native platform DAR protection (e.g., encryption) in order to protect the private keys and other classified information stored on it from disclosure and increase the difficulty of tampering with the software and configuration. Continuous physical control of the EUD must be maintained at all times. 3. Thin EUD: The EUD can be designed to prevent any classified information from being saved to any persistent storage media on the EUD. Possible techniques for implementing this include, but are not limited to: using VDI configured not to allow data from the Enterprise/Red Network to be saved on the EUD, restricting the user to a non-persistent virtual machine on the EUD, and/or configuring the EUD’s operating system to prevent the user from saving data locally. Since the EUD does not provide secure local storage for classified data, its user is also prohibited by policy from saving classified data to it. The EUD in this case must enable the native platform DAR protection to protect the private keys stored on it from disclosure, and to increase the difficulty of tampering with the software and configuration. This option is not permitted if any of the private keys or certificates stored on the EUD are considered classified by the AO. Continuous physical control of the EUD must be maintained at all times. 12 While powered on, an EUD is classified at the same level of the connected Red Network, since classified data may be present in volatile memory and/or displayed on screen. To mitigate the risk of accidental disclosure of classified information to unauthorized personnel while the EUD is in use, the customer must define and implement an EUD user agreement that specifies the rules of use for the system. The customer must require that all users accept the user agreement and receive training on how to use and protect their EUD before being granted access. There is no limit to the number of EUDs that may be included in an MA solution. The intent of a continuous physical control requirement for the MA CP is to prevent potential attacks via brief, undetected physical access of an EUD by a nation state adversary. Since MA CP EUDs by their nature are mobile they are frequently transported and operated outside of physically protected government spaces. As a result, customers must maintain continuous physical control of the EUD at all times. 4.2.2 INDEPENDENT SITE Figure 4. EUDs Connected to Independent Site Figure 4 shows a single Red Network connected to EUDs that operate at the same security level through the MA solution. Here, the Red Network has at least two Encryption Components associated with it: one or more Inner Encryption Components connected to the Red Network, and an Outer VPN Gateway between the Inner Encryption Components and the Black Network. There are two layers of encryption between any EUD communicating with the Red Network: one IPsec tunnel between their Outer VPN Components, and a second IPsec, TLS or SRTP layer depending on the selected EUD design(s). For independent sites, administration is performed at that site for all components within the Solution Boundary, including the Outer VPN Gateway, Gray Management Services, Inner Encryption Components, Red Management Services, firewalls, and EUDs. Independent sites are not interconnected with other infrastructure sites through the MA solution; therefore, management, data plane, and control plane traffic between solution infrastructure sites are outside the scope of the MA CP. If two or more sites 13 must be interconnected, customers may also register the MA solution against the MSC CP or use an NSA-Certified encryptor. While Figure 4 shows only a single EUD, this solution does not limit the number of EUDs being implemented. 4.2.3 MULTIPLE SITES Figure 5. Multiple Mobile Access Solution Infrastructures Supporting EUDs Figure 5 shows two MA solution infrastructures that an EUD can connect to in order to access different Red Network services. Customers may want to implement multiple solution infrastructures to support Continuity of Operations or provide better performance based on geographic location of EUDs or Red services. The multiple solution infrastructures may be interconnected using an NSA-approved solution such as the MSC CP or an NSA-Certified encryptor; however, connectivity of Solution Infrastructure Components is outside the scope of the MA CP. While Figure 5 shows only two sites, this solution can scale to include numerous sites, with each additional site having the same design as those in Figure 5. 14 Figure 6. Mobile Access Solution Supporting Multiple Security Levels 4.2.4 MULTIPLE SECURITY LEVELS A single implementation of the MA solution may support multiple Red Networks of different security levels. The MA solution provides secure connectivity between EUDs and the Red Network of the same security level while preventing EUDs from accessing Red Networks of different security levels. This enables a customer to use the same physical infrastructure to carry traffic from multiple networks. EUDs operating as part of a Multiple Security Level solution are still dedicated to a single classification level. Although each Red Network will still require its own Inner Encryption Component(s), a site may use a single Outer VPN Gateway in the infrastructure to encrypt and transport traffic that has been encrypted by Inner Encryption Components of varying security levels. As shown in Figure 6, a SECRET Coalition EUD is only capable of communicating with and authenticating to the Inner Encryption Components for Network 3 – SECRET Coalition. This EUD does not have any connectivity to the Inner Encryption Components of Network 1 and Network 2. There is no limit to the number of different security levels that an MA solution may support. MA solutions supporting multiple security levels may include independently managed sites (see Section 4.2.2) or multiple sites (see Section 4.2.3). In all cases, separate CAs and management devices are needed to manage the Inner Encryption Components and Inner Firewall at each security level. For example, Figure 6 shows an independent site with multiple security levels. Network 1, Network 2, and Network 3 each have their own CA and management devices which prevent EUDs from being able to authenticate with the incorrect network. 15 In addition to separate Inner Encryption Components and CAs, an authentication server must be used to allow the use of a single Outer VPN Gateway for multiple security levels. The authentication server resides within the Gray Management network and validates that Outer Tunnel certificates are signed by the Outer Tunnel CA, are still within their validity period, and have not been revoked. The authentication server also parses the certificate for information assigned to a specific inner network (i.e., Organizational Unit (OU) field or policy Object Identifiers (OIDs)) to determine which inner network the EUD is authorized to connect. After successful authentication, the authentication server provides an accept message to the Outer VPN Gateway along with a Vendor-Specific Attribute (VSA). The Outer VPN Gateway uses the VSA to assign the proper network and firewall rules such that an EUD can only reach the appropriate Inner Encryption Components. RATIONALE FOR LAYERED ENCRYPTION A single layer of CNSA encryption, properly implemented, is sufficient to protect classified data in transit across an untrusted network. The MA solution uses two layers of CNSA encryption not because of a deficiency in the cryptographic algorithms themselves, but rather to mitigate the risk that a failure in one of the components, whether by accidental misconfiguration, operator error, or malicious exploitation of an implementation vulnerability, results in exposure of classified information. The use of multiple layers of protection reduces the likelihood of any one vulnerability being used to exploit the full solution. If an Outer VPN Component is compromised or fails in some way, the Inner Encryption Component can still provide sufficient encryption to prevent the immediate exposure of classified data to a Black Network. In addition, the Gray Firewall can indicate that a failure of the Outer VPN Gateway has occurred, since the filtering rules applied to its external network interface will drop and log the receipt of any packets not associated with an Inner Encryption Component. Such log messages indicate that the Outer VPN Gateway has been breached or misconfigured to permit prohibited traffic to pass through to the Inner encryption component. Conversely, if the Inner Encryption Component is compromised or fails in some way, the Outer VPN Gateway can likewise provide sufficient encryption to prevent the immediate exposure of classified data to a Black Network. As in the previous case, the Gray Firewall filtering rules applied to its internal network interfaces will drop and log the receipt of any packets not associated with an Inner Encryption Component. Such log messages indicate that the Inner Gateway has been breached or misconfigured to permit prohibited traffic to pass through to the Outer VPN Gateway. If both the Outer and Inner Gateways are compromised or fail simultaneously, then it may be possible for classified data from the Red Network to be sent to a Black Network without an adequate level of encryption. The security of the MA solution depends on preventing this failure mode by promptly remediating any compromises or failures in one Encryption Component before the other also fails or is compromised. Diversity of implementation is needed between the components in each layer of the solution in order to reduce the likelihood that both layers share a common vulnerability. The CSfC Program recognizes two ways to achieve this diversity. The first is to implement each layer using components produced by different manufacturers. The second is to use components from the same manufacturer, where the manufacturer has provided NSA with sufficient evidence that the implementations of the two 16 components are independent of one another. The CSfC web page (https://www.nsa.gov/resources/commercial-solutions-for-classified-program) contains details for how a manufacturer can submit this evidence to NSA and what documentation must be provided. Customers that wish to use products from the same manufacturer in both layers must contact their NSA Client Advocate to confirm that NSA has accepted the manufacturer’s claims before implementing their solution. AUTHENTICATION The MA solution provides mutual device authentication between Outer VPN components and between Inner Encryption components via public key certificates. This CP requires all authentication certificates issued to Outer VPN components and Inner Encryption components be Non-Person Entity (NPE) certificates, except in the case when TLS EUDs are implemented. In addition, NPE certificates issued to Outer VPN Gateways may need to assert the IP address of the Outer VPN Gateway in either the Common Name field of the certificate Distinguished Name, or in the Subject Alternative Name certificate extension. The EUD may be required to check the IP address asserted in the Outer VPN Gateway certificate and ensure it is the same IP address registered in the EUD. 4.4.1 TRADITIONAL AUTHENTICATION Following the two layers of device authentication, VPN EUDs require the user to authenticate to the network before gaining access to any classified data (e.g., username/password, user certificate). TLS EUDs may use a device certificate or a user certificate. When a device certificate is used, the user must also authenticate to the Red Network before gaining access to any classified data in the same manner as a VPN EUD (e.g., username/password, user certificate). When a user certificate is used, the user certificate authenticates the Inner layer of TLS encryption and authenticates the user for access to the requested classified data. In this latter case, it is recommended that additional access controls, such as Allowlist, be implemented in conjunction with the user certificate to control access to Red Network services. In addition to authentication for the Outer and Inner layer of encryption, the MA CP requires user-to- device authentication. This authentication occurs between the user and the Computing Device (which processes Red data) of an EUD. In some instances the Computing Device may be physically separate from the component of the EUD which provides the Outer layer of encryption (for example, a Dedicated Outer VPN Gateway provides the Outer layer of encryption). The MA CP requires EUD components use a minimum of a six-character, case-sensitive, alpha-numeric password to authenticate to the device. This password can be used both for decrypting the platform encryption as well as for unlocking the screen. EUD components, which are selected from the Mobile Platform section of the CSfC Components List, are able to use a relatively short authentication factor since they use a hardware based root encryption key which is evaluated during the NIAP certification. 4.4.2 MULTI-FACTOR AUTHENTICATION Within this CP a form of multi-factor authentication must be used for a user to access classified data. The current multi-factor authentication options are, ‘something you know’ and ‘something you have.’ There are two forms of multi-factor authentication one of which must be used within MA CP. The two forms are ‘User to EUD’, in which the user authenticates to the EUD using an additional factor, and ‘EUD to Infrastructure’, in which the user authenticates to the Inner Encryption Component user an additional 17 factor. The authentication token and the EUD must be stored in a physically separate and independently securable storage containers when both devices are securely stored. 4.4.2.1 PHYSICAL EUD This multi-factor use case could apply to either a VPN or TLS EUD. “Physical EUD” is defined as using a second factor of authentication for login to the device in a user's possession. This could be accomplished using a smart card with an identity PKI cert (something you have) and a passphrase (something you know). This could also be accomplished with a passphrase (something you know) and the second factor will be a “something-you-have” factor manifesting as a physically separate token external from the VPN EUD supplying a one-time password for the user to enter. As shown in Table 19, the passphrase in both cases must still meet the complexity and length requirement specified. 4.4.2.2 INNER ENCRYPTION COMPONENT This multi-factor use case applies to a VPN EUD or TLS EUD. “Inner Encryption Component” is defined as using a second factor of authentication to the Inner VPN tunnel or TLS Server. This could be accomplished using a smart card with the Inner EUD PKI cert (something you have) and a passphrase (something you know). This could alternatively be accomplished as shown in Table 19, the first factor will be the certificate that is on the device. The second factor will be a “something-you-have” factor manifesting as a physically separate token from the VPN EUD supplying a one-time password for the user to enter. Adding a second factor of authentication to the solution prevents continued access to a network if an EUD is compromised as a result of an attack. If a device has been compromised, it must be assumed that the certificates used to authenticate to the enterprise would be accessible to an adversary to be used on a legitimate device or they could be extracted and used on a different device masquerading as the user. If an adversary has managed to compromise the certificates on an EUD, adding a second authentication factor prevents persistent access to a network. 4.4.2.3 VIRTUAL DESKTOP INFRASTRUCTURE (VDI) This multi-factor use case applies to a Thin EUD and is defined as a second factor of authentication to log into a Virtual Desktop/Environment session to access Red data. This could be accomplished using a smart card with an identity PKI cert (something you have) and a passphrase (something you know). This could also be accomplished with a passphrase (something you know) and the second factor will be a “something-you-have” factor manifesting as a physically separate token external from the VPN EUD supplying a one-time password for the user to enter. As shown in Table 19, the passphrase in both cases must still meet the complexity and length requirement specified. OTHER PROTOCOLS Throughout this document, when IP traffic is discussed, it can refer to either IPv4 or IPv6 traffic, unless otherwise specified, as the MA solution is agnostic to most named data handling protocols. Public standards conformant Layer 2 control protocols are allowed as necessary to ensure the operational usability of the network. This CP is agnostic with respect to Layer 2; specifically, it does not require Ethernet. Public standards conformant Layer 3 control protocols may be allowed based on local AO policy, but the default configuration of this solution is for all Layer 3 control protocols to be disabled. 18 Red and Gray Network multicast messages and Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) may also be allowed depending on local AO policy. Multicast messages received on external interfaces of the Outer VPN component must be dropped. It is expected that the MA solution can be implemented in such a way as to take advantage of standards- based routing protocols that are already being used in the Black and/or Red Network. For example, networks that currently use Generic Routing Encapsulation (GRE) or Open Shortest Path First (OSPF) protocols can continue to use these in conjunction with the Outer Firewall and Inner Firewall solution to provide routing as long as the AO approves their use. AVAILABILITY The high-level designs described in Section 4.2 are not designed to automatically provide high availability. Supporting solution implementations for which high availability is important is not a goal of this version of the CP. However, this CP does not prohibit adding redundant components in parallel to allow for component failover or to increase the throughput of the MA solution, as long as each redundant component adheres to the requirements of this CP. The CP does not limit the number of Outer VPN Gateways or Inner Encryption components that can be implemented for high availability in a MA Solution. INFRASTRUCTURE COMPONENTS In the high-level designs discussed in the previous section, all communications flowing across a Black Network are protected by at least two layers of encryption, implemented using an Outer IPsec VPN tunnel and an Inner layer of IPsec, TLS, or SRTP encryption. Mandatory aspects of the solution infrastructure also include administration workstations, IDS/IPS, SIEM, firewalls, and CAs for key management using PKI. Each infrastructure component is described in more detail below. The descriptions include information about the security provided by the components as evidence for why they are deemed necessary for the solution. Components are selected from the CSfC Components List and configured per NIAP configuration guidance in accordance with the Product Selection requirements of this CP (see Section 10). This section also provides details on additional components that can be added to the solution to help reduce the overall risk. However, where indicated in the text, these are not considered mandatory components for the security of the solution; therefore, this CP does not place configuration requirements on those optional components. OUTER FIREWALL The Outer Firewall is located at the edge of the MA solution infrastructure and connected to the Black Transport Network. The external interface of the Outer Firewall only permits IPsec, IKE, and ESP traffic with a destination address of the Outer VPN Gateway. 19 The internal interface of the Outer Firewall only permits IPsec traffic with a source address of the Outer VPN Gateway and any necessary control plane traffic. The minimum requirements for port filtering on the Outer Firewall can be found in Section 11.13. As shown in Figure 4, The Outer Firewall, selected from the CSfC Components List, must be physically separate from the Outer VPN Gateway. OUTER VPN GATEWAY Authentication of peer VPN Components, cryptographic protection of data in transit, and configuration and enforcement of network packet handling rules are all aspects fundamental to the security provided by VPN Gateways. The external interface of the Outer VPN Gateway is connected to the internal interface of the Outer Firewall. The VPN Gateway establishes an IPsec tunnel with peer Outer VPN Components, which provides device authentication, confidentiality, and integrity of information traversing Black Networks. VPNs offer a decreased risk of exposure of information in transit since any information that traverses a Black Network is placed in a secure tunnel that provides an authenticated and encrypted path between the site and an EUD. The Outer VPN Gateway is implemented identically for all the high-level designs supporting a single security level. When supporting multiple security levels, the Outer VPN Gateway must use a gray authentication server. Similar to the Outer Firewall, the external interface of the Outer VPN Gateway only permits IPsec traffic. The internal interface of the Outer VPN Gateway is configured to only permit traffic with an IP address and port associated with Inner Encryption Components, Gray Management Services (e.g., SIEM and administration workstation), or control plane component (i.e., DNS and NTP Servers in the Gray). The Outer VPN Gateway is prohibited from implementing routing protocols on external and internal interfaces and must rely upon the Outer Firewall to provide any dynamic routing functionality. As shown in Figure 4, the Outer VPN Gateway, selected from the CSfC Components List, must be physically separate from the Outer Firewall and Gray Firewall. Described in Section 4.2.4, The Outer VPN Gateway is implemented in conjunction with a Gray authentication server when multiple security levels are implemented. The Outer VPN Gateway acts as an EAP pass-through for authentication between the EUD and the authentication server. Upon successful mutual authentication, the Outer VPN Gateway receives an accept message and VSA for that specific EUD. The Outer VPN Gateway uses the VSA to assign the correct IP address and ACL to ensure that the EUD is capable of reaching only the correct Inner Encryption Component. The Outer VPN Gateway cannot route packets between the Gray and Black Networks; any packets received on a Gray Network interface and transmitted to a Black Network interface must be transmitted within an IPsec VPN tunnel configured according to this CP. GRAY FIREWALL The Gray Firewall is located between the Outer VPN and Inner encryption components. In addition to filtering EUD traffic, the Gray Firewall also provides packet filtering for the Gray Management Services. 20 The external interface of the Gray Firewall should only accept packets with a source address of the Outer VPN Gateway’s IP pool assigned to EUDs. The internal interface of the Gray Firewall should only accept packets with a source address of the TLS-Protected server or the Inner VPN Gateway as part of an established communication session. When supporting multiple security levels the Gray Firewall must also ensure that only EUDs and Inner Encryption components of the same security level are able to communicate. In addition to EUD data traffic, the Gray Firewall adjudicates traffic related to both the management of the Gray boundary and EUD control plane traffic. As shown in Figure 4, the Gray Firewall, selected from the CSfC Components List, must be physically separate from the Outer VPN Gateway and Inner Encryption Components. INNER FIREWALL The Inner Firewall is located between the Inner encryption components and the Red Network. The external interface of the Inner Firewall should only accept inbound traffic with a source address of the TLS-Protected server or Inner VPN Component. The internal interface of the Inner Firewall should only allow outbound traffic from the Red enclave to the Inner VPN Component or the TLS-Protected server. The TLS-Protected servers include, but are not limited to: VoIP call managers, mobile device management (MDM) services, VDI, and web server content. The Inner Firewall, selected from the CSfC Components List, must be physically separate from the Inner Encryption Components. GRAY MANAGEMENT SERVICES Secure administration of components in the Gray Network and continuous monitoring of the Gray Network are essential roles provided by the Gray Management Services. The Gray Management Services are composed of multiple components that provide distinct security to the solution. The MA CP allows flexibility in the placement of some Gray Management Services. All components within the Gray Management Services are either directly or indirectly connected to the Gray Firewall (e.g., multiple Gray Management Services connected to a switch which is connected to the Gray Firewall). The Gray Management Services are physically protected as classified devices. 21 CSfC Solution Infrastructure Components End User Outer Outer VPN Gray Inner Device Firewall Gateway Firewall Firewall Red Black Network Network Gray Inner Encryption Management Component(s) Services Switch Red Management Services Authentication SIEM/ Server Log Collection Storing DNS Administration Workstation Gray Management Services CSfC Black/Gray Boundary Gray/Red Boundary Solution Boundary Figure 7. Overview of Gray Management Services Figure 7 shows the infrastructure components of the Gray Management Services in the MA Solution. Within the Gray Network, which is between the Outer VPN Gateway and Inner Encryption Components, has an Administration workstation, SIEM, Authentication Server, and DNS. Components within the Gray Network are further described below. 5.5.1 GRAY ADMINISTRATION WORKSTATION Gray administration workstations maintain, monitor, and control all security functions for the Out
