robsmit/testSet

1{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "0", "chunk": "UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY// REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT   1 \n National Security Agency  \nCybersecurity Directorate  \n \n 2 \n 3 \nCross Domain Solution (CDS) Design and 4 \nImplementation Requirements : 5 \n2023  Raise the Bar (RTB) Baseline Release   6 \nDRAFT Version 5.0 rev 85 7 \n11 May 2023 8 \nNCDSMO -R-00008-005_00  9 \n 10 \nX\n 11 \nJohn Jamka  12 \nChief, National Cross Domain Strategy & Management Office  13 \n 14 \n 15 \nPleas e send comments or questions to  ncdsmo@nsa.gov .  16 \n 17 \n 18 \n 19 \n 20 \nDISTRIBUTION STATEMENT C. Distribution authorized to United States Government agencies and their 21 \ncontractors and to the Government  agencies of ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, 22 \nSWE,  QAT, and NATO individual member nations  (Administrative Use) (11 May 2023). Other  requests for 23 \nthis document shall be referred to the National Security Agency\u2019s National Cross Domain Strategy and 24 \nManagement Office.  25UNCLASSIFIED//FOR OFFIC IAL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU,", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}2{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "1", "chunk": " SWE, QAT  \nPage 2 of 397 Disclaimer  26 \nReferences herein to a ny commercial products, process, or service by trade name, trademark, 27 \nmanufacturer, or otherwise, do not constitute an official endorsement, either expressed or implied, by the 28 \nNational Security Agency.  29 \nReferences herein to any commercial products, process , or service by trade name, trademark, 30 \nmanufacturer, or otherwise, do not constitute an official endorsement of this document, either expressed 31 \nor implied, by the trademark holder.  32 \nReferences to a product in this document do not imply endorsement by the National Security Agency of 33 \nthe use of that product in any specific operational environment or system, to include integration of the 34 \nproduct as a component of a software or hardware system.  35 \nReferences to attribution of specific cyber -attacks does not constitute endorsement or confirmation, either 36 \nexpressed or implied, by the National Security Agency or the United States Government.  37 \nThis document is not intended to endorse any vendor or product over another in any way.  Citations of 38 \nworks in this report do not imply endorsement by the National Security Agency of the content, accuracy, 39 \nor applicability of such works.  References to information technology standa", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}3{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "2", "chunk": "rds or guidelines do not 40 \nimply a claim that products are in conformance or nonconf ormance with such standard or guideline.  41 \nClassification markings used in the requirements sections are for example purposes only. This document 42 \nis UNCLASSIFIED //FOR OFFICIAL USE ONLY //REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, 43 \nNATO, NOR, SAU, SWE, and QAT . 44 \nAbout the NCDSMO  45 \nPursuant to the authority of Executive Order 12333 , National Security Directive 42, and National Security 46 \nMemorandum 8, the National Cross Domain Strategy & Managemen t Office (NCDSMO) is the focal 47 \npoint for U.S. Government cross domain capabilities and mission needs.  The NCDSMO develops cross 48 \ndomain s olution (CDS) technical standards, processes, and technologies and operates the U.S. 49 \nGovernment CDS testing program.  50 \n To learn more about the NCDSMO\u2019s mission and to find other NCDSMO documents, visit our Intelink 51 \nwebsites:  52 \n\u25aa https://intelshare.intelink.gov/sites/ncdsmo (NIPRNet)  53 \n\u25aa https://intelshare.intelink.sgov.gov/sites/ncdsmo (SIPRNet)  54 \n\u25aa https://intelshare.intelink.ic.gov/s ites/ncdsmo (JWICS)  55 \n Contact  the NCDSMO at:  56 \n\u25aa ncdsmo@nsa.gov (NIPRNet)  57 \n\u25aa ncdsmo@nsa.smil.mil (SIPRNet)  58 \n\u25aa ncdsmo@nsa.ic.gov (JWICS)  59 \n 60UNCLASSIFIED//FOR OFFICI A", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}4{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "3", "chunk": "L USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 3 of 397 Table of Contents  61 \nLIST OF FIGURES ................................ ................................ ................................ ................................ .....................  6 62 \nLIST OF TABLES  ................................ ................................ ................................ ................................ ......................  7 63 \nCHANGE HISTORY  ................................ ................................ ................................ ................................ ..................  8 64 \n1 DOCUMENT OVERVIEW  ................................ ................................ ................................ ..............................  19 65 \n1.1 RESTRICTIONS ON USE AND DOCUMENT VERSIONING ................................ ................................ ...............................  21 66 \n1.2 TAILORING OF REQUIREMENTS  ................................ ................................ ................................ ...........................  22 67 \n1.3 ORDER OF PRECEDENCE  ................................ .....", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}5{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "4", "chunk": "........................... ................................ ................................ .... 23 68 \n1.4 CLARIFICATION ON TERMINOLOGY USAGE  ................................ ................................ ................................ .............  23 69 \n1.5 REQUIREMENTS TERMINOLOGY  ................................ ................................ ................................ ..........................  23 70 \n1.6 DEVIATIONS FROM REQUIREMENTS IN THIS DOCUMENT  ................................ ................................ ............................  24 71 \n1.7 NOTICE OF FUTURE CHANGES  ................................ ................................ ................................ ............................  24 72 \n1.8 CDS  AND CRYPTOGRAPHIC  DEVICES  ................................ ................................ ................................ ....................  25 73 \n2 SHOULD WE BUILD A NEW CDS?  ................................ ................................ ................................ .................  25 74 \n2.1 BUY, BUY AND MODIFY , OR BUILD NEW? ................................ ................................ ................................ .............  26 75 \n2.2 CDS  TESTING (ALSO CALLED ASSESSMENT ) .........................", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}6{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "5", "chunk": "....... ................................ ................................ ............  27 76 \n2.3 CDS  OPERATIONS , MAINTENANCE , & LIFECYCLE  ................................ ................................ ................................ .... 28 77 \n3 CDS DEFINITIO NS ................................ ................................ ................................ ................................ ........  29 78 \n4 CDS CLASSES  ................................ ................................ ................................ ................................ ...............  35 79 \n4.1 DATACENTER -CLASS TRANSFER CDS  (DCCDS)  ................................ ................................ ................................ .......  37 80 \n4.2 TACTICAL -CLASS TRANSFER CDS  (TCDS)  ................................ ................................ ................................ ..............  38 81 \n5 CDS IMPLEMENTATION MODELS  ................................ ................................ ................................ ................  38 82 \n6 RISKS & THREATS  ................................ ................................ ................................ ................................ ........  40 83 \n6.1 THREAT AND WEAKNESS (T&W)  MAPPING  .....................", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}7{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "6", "chunk": "........... ................................ ................................ ...........  40 84 \n6.2 OPERATIONAL ENVIRONMENT RISK ASSUMPTIONS  ................................ ................................ ................................ .. 41 85 \n6.3 CYBER ENVIRONMENT RISK ASSUMPTIONS  ................................ ................................ ................................ ............  42 86 \n6.4 GENERAL THREATS  ................................ ................................ ................................ ................................ ..........  42 87 \n6.5 CONTENT AND PROTOCOL -BASED RISKS AND ATTACKS  ................................ ................................ .............................  44 88 \n7 FOUNDATIONAL CONCEPTS  ................................ ................................ ................................ ........................  51 89 \n7.1 SECURE BY DESIGN  ................................ ................................ ................................ ................................ ..........  51 90 \n7.2 PRINCIPLES OF LEAST PRIVILEGE , LEAST KNOWLEDGE , & LEAST FUNCTIONALITY  ................................ ..............................  52 91 \n7.3 REDUNDANT , ALWAYS INVOKED , INDEPENDENT IMPLEMENTATIONS , AND NON-BYPASSABLE", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}8{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "7", "chunk": " (RAIN)  EXPLAINED ....................  53 92 \n7.4 PLATFORM SECURITY  ................................ ................................ ................................ ................................ .......  56 93 \n7.5 FILTERING  ................................ ................................ ................................ ................................ .....................  59 94 \n8 CDS DESIGN PATTERNS: OVERVIEW AND REQUIREMENTS ................................ ................................ ..........  73 95 \n8.1 INTRODUCTION TO DESIGN PATTERN DRAWINGS  ................................ ................................ ................................ .... 73 96 \n8.2 UNACCEPTABLE DESIGN PATTERNS (UDP)  ................................ ................................ ................................ ............  74 97 \n8.3 ACCEPTABLE DESIG N PATTERNS (ADP)  ................................ ................................ ................................ ................  79 98 \n8.4 DESIGN PATTERNS AND REQUIREMENTS USING ONE-WAY TRANSFER MECHANISMS (OWTDP)  ................................ .......  103 99UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}9{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "8", "chunk": ", BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 4 of 397 9 GENERAL REQUIREMENTS  ................................ ................................ ................................ ........................  129 100 \n9.1 SAFETY REQUIREMENTS (SR) ................................ ................................ ................................ ...........................  130 101 \n9.2 TRAINING REQUIREMENTS (TR) ................................ ................................ ................................ ........................  130 102 \n9.3 CDS  THROUGHPUT REQUIREMENTS  ................................ ................................ ................................ ..................  131 103 \n9.4 CDS  LATENCY REQUIREMENTS  ................................ ................................ ................................ .........................  131 104 \n9.5 CDS  AVAILABILITY REQUIREMENTS  ................................ ................................ ................................ ....................  131 105 \n9.6 PREVENTATIVE MAINTENANCE REQUIREMENTS (PMR)  ................................ ................................ ..........................  131 106 \n9.7 NETWORK CABLING REQUIREMENTS (NCR)  ................................ .......................", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}10{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "9", "chunk": "......... ................................ ........  131 107 \n9.8 NETWORKING RELATED REQUIREMENTS (NRR)  ................................ ................................ ................................ .... 132 108 \n10 GENERAL SECURITY REQUIREMENTS  ................................ ................................ ................................ ........  136 109 \n10.1  SECURITY CERTIFICATION REQUIREMENTS (SCR)  ................................ ................................ ................................ . 136 110 \n10.2  GENERAL  ARCHITECTURE REQUIREMENTS (GAR)  ................................ ................................ ................................  137 111 \n10.3  COMMAND AND CONTROL (C2)  AND METADATA MESSAGING REQUIREMENTS (C2R)  ................................ .................  143 112 \n10.4  OPERATING SYSTEM SECURITY REQUIREMENTS (OSSR)  ................................ ................................ ........................  146 113 \n10.5  SYSTEM ADMINISTRATION SUBSYSTEM REQUIREMENTS (SASR)  ................................ ................................ .............  169 114 \n10.6 DEVELOPMENT PROCESSES & MECHANISMS REQUIREMENTS (DPMR)  ................................ ................................ .... 179 115 \n10.7  SYSTEM INSTALLATION AND HARD", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}11{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "10", "chunk": "WARE CONFIGURATION REQUIREMENTS (SIHCR)  ................................ ....................  188 116 \n10.8  PROCESS ISOLATION REQUIREMENTS (PIR)  ................................ ................................ ................................ ........  195 117 \n10.9  ROLE-BASED ACCESS CONTROL (RBAC)  REQUIREMENTS (RBACR)  ................................ ................................ .........  199 118 \n10.10  ENCRYPTION AND DIGITAL SIGNATURE REQUIREMENTS (EDSR) ................................ ................................ ............  206 119 \n10.11  SYSTEM INTEGRITY REQUIREMENTS (SIR)  ................................ ................................ ................................ ........  210 120 \n10.12  JOURNALING , AUDITING , AND LOGGING (JAL)  SUBSYSTEM (JALS)  REQUIREMENTS (JALSR)  ................................ .......  218 121 \n10.13  REMOTE MONITORING REQUIREMENTS (RMONR)  ................................ ................................ ...........................  229 122 \n10.14  REMOTE MANAGEMENT REQUIREMENTS (RMANR)  ................................ ................................ .........................  230 123 \n10.15  PROTOCOL ADAPTER REQUIREMENTS (PAR)  ................................ ................................ .......................", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}12{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "11", "chunk": "......... .... 234 124 \n10.16  DOMAIN ROUTE R REQUIREMENTS (DRR)  ................................ ................................ ................................ .......  235 125 \n10.17  FILTER REPORT VALIDATOR REQUIREMENTS (FRVR)  ................................ ................................ ..........................  236 126 \n10.18  JOB SCHEDULER REQUIREMENTS (JSR)  ................................ ................................ ................................ ...........  238 127 \n10.19  RESULTS PROCESSOR REQUIREMENTS (RPR) ................................ ................................ ................................ .... 239 128 \n10.20  TAMPER PROTECTION REQUIREMENTS (TPR)  ................................ ................................ ................................ ... 240 129 \n10.21  SUPPLY CHAIN REQUIREMENTS (SC) ................................ ................................ ................................ ..............  242 130 \n10.22  DEFENSIVE CYBERSPACE OPERATIONS (DCO)  OF CDS  REQUIREMENTS (DCOR)  ................................ .......................  244 131 \n11 DATAFLOW FILTERING REQUIREMENTS  ................................ ................................ ................................ .... 245 132 \n11.1  GENERAL DATAFLOW FILTERING ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}13{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "12", "chunk": "REQUIREMENTS (GDFR)  ................................ ................................ .....................  245 133 \n11.2  GENERAL XML  AND FIXED FORMAT PROCESSING REQUIREMENTS (GXFFPR)  ................................ ............................  258 134 \n11.3  MILITARY MESSAGING FIXED FORMAT DATA FILTERING AND PROTOCOL REQUIREMENTS (MMFFR)  ...............................  260 135 \n11.4  MODULAR PIPELINE COMPONENT REQUIREMENTS (MPCR)  ................................ ................................ ..................  262 136 \n11.5  CUSTOMER DEVELOPED MODULAR PIPELINE COMPONENTS REQUIREMENTS (CDMPCR)  ................................ .............  270 137 \n12 REQUIREMENTS FOR CDS VIRTUALIZATION (VIRT)  ................................ ................................ ...................  273 138 \n13 REQUIREMENTS FOR USE OF SEPARATION KERNELS (SK) ................................ ................................ ..........  279 139 \n14 REQUIREMENTS FOR MULTI -LEVEL SECURITY CDS (MLS)  ................................ ................................ ..........  280 140 \n15 TRANSFER CDS CLASS/CDS IMPLEMENTATION MODEL REQUIREMENTS  ................................ ..................  283 141 \n15.1  DCCDS -FF/TSB  ARCHITECTURE DESIGN PATTERN AND REQUIREMENTS (DCFFTSB) .......", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}14{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "13", "chunk": "......................... ..................  283 142UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 5 of 397 15.2  DCCDS -FF/CCOTS  ARCHITECTURE DESIGN PATTERN AND REQU IREMENTS (DCFFCOTS)  ................................ ...........  284 143 \n15.3  DCCDS -CD/TSB  ARCHITECTURE DESIGN PATTERN AND REQUIREMENTS (DCCDTSB)  ................................ ................  290 144 \n15.4  THA  ARCHITECTURE DESIGN PATTERNS AND REQUIREMENTS (THA)  ................................ ................................ .......  290 145 \n15.5  THA  AND HB REQUIREMENTS (HWR)  ................................ ................................ ................................ .............  290 146 \n15.6  CONNECTIONS BETWEEN UNCLASSIFIED /HIGH THREAT NETWORK AND CLASSIFIED NETWORKS REQUIREMENTS (CUCR)  ...... 290 147 \n16 TESTING REQUIREMENTS (DTR)  ................................ ................................ ................................ ................  291 148 \n16.1  VENDOR TESTING REQUIREMENTS (VTR)  ................................ ................................ ................................ ..........  291", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}15{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "14", "chunk": " 149 \n16.2  LAB-BASED SECURITY ASSESSMENT (LBSA)  REQUIREMENTS (LBSAR)  ................................ ................................ ..... 292 150 \n16.3  SITE-BASED SECURITY ASSESSMENT (SBSA)  REQUIREMENTS (SBSAR)  ................................ ................................ .... 293 151 \n17 MULTI -LEVEL DATABASE REQUIREMENTS (MLDBR)  ................................ ................................ ..................  294 152 \n18 MULTI -LEVEL SWITCH AND NIC REQUIREMENTS (MLSWNR)  ................................ ................................ ..... 299 153 \n19 CDS MANAGEMENT SYSTEM REQUIREMENTS (CMSR)  ................................ ................................ ..............  301 154 \n20 ACCESS CDS SPECIFIC REQUIREMENTS (ACDSR)  ................................ ................................ ........................  305 155 \n21 RELIABLE HUMAN REVIEW REQUIREMENTS (RHRR)  ................................ ................................ .................  307 156 \n22 FILTER SIDECAR REQUIREMENTS (FSR) ................................ ................................ ................................ ...... 311 157 \n23 DISTRIBUTED FILTERING SYSTEM REQUIREMENTS (DFSR)  ................................ ................................ ........  319 158 \n24 CDS DEC", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}16{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "15", "chunk": "OMMISSIONING AND REUSE REQUIREMENTS (CDRR)  ................................ ................................ . 327 159 \n25 HARDWARE -BASED CDS AND HARDWARE -BASED COMPONENTS REQUIREMENTS (HWCR)  .....................  327 160 \n25.1  HARDW ARE-BASED CDS/C OMPONENTS GENERAL HARDWARE REQUIREMENTS (HWC -GHR)  ................................ .......  328 161 \n25.2  HARDWARE -BASED CDS/C OMPONENTS NON-TACTICAL REQUIREMENT S (HWC -NTR)  ................................ ................  331 162 \n25.3  HARDWARE -BASED CDS/C OMPONENTS TACTICAL REQUIREMENTS (HWC -TR) ................................ ..........................  333 163 \n26 GOVERNMENT DOCUMENTS  ................................ ................................ ................................ ....................  338 164 \n27 NON -GOVERNMENT PUBLICATIONS  ................................ ................................ ................................ .........  341 165 \n28 TRADEMARKS  ................................ ................................ ................................ ................................ ...........  342 166 \n29 APPENDIX A \u2013 ABBREVIATIONS AND ACRONYMS  ................................ ................................ .....................  344 167 \n30 APPENDIX B \u2013 ENCRYPTION & DIGITAL SIGNATURE", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}17{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "16", "chunk": " STANDARDS ................................ ..............................  352 168 \n31 APPENDIX C \u2013 RTB REQUIREMENTS MAPPING FOR ACCESS CDS  ................................ ...............................  355 169 \n32 APPENDIX D \u2013 RTB REQUIREMENTS MAPPING FOR HCFD, PFD, AND HARDWARE CDS  .............................  356 170 \n33 APPENDIX E \u2013 CDS AUDIT EVENTS  ................................ ................................ ................................ .............  357 171 \n34 APPENDIX F \u2013 RTB SPECIFIC THREATS  ................................ ................................ ................................ .......  357 172 \n APPENDIX G \u2013 RTB SPECIFIC WEAKNESSES  ................................ ................................ ................................  363 173 \n35 363 174 \n36 APPENDIX H \u2013 EXAMPLE BOOT SEQUENCES FOR TACTICAL CDS WITH FPGAS  ................................ ...........  370 175 \nAPPENDIX I \u2013 ALIGNMENT OF RTB REQUIREMENTS TO NIST CONTROLS  ................................ ............................  371 176 \n 177UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 6 of 397 List ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}18{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "17", "chunk": "of Figures  178 \nFIGURE 1 \u2013 PITCHER /DIODE/CATCHER (PDC)  ARCHITECTURE  ................................ ................................ ..............................  34 179 \nFIGURE 2 \u2013 UDP -1: THE SINGLE PROCESS GUARD  ................................ ................................ ................................ ............  75 180 \nFIGURE 3 \u2013 UDP -2: THE NEARLY SINGLE PROCESS GUARD  ................................ ................................ ................................ . 75 181 \nFIGURE 4 \u2013 UDP -3: THE \u201cSTAR\u201d GUARD  ................................ ................................ ................................ .......................  76 182 \nFIGURE 5 \u2013 UDP -4 CASCADING OF CDS................................ ................................ ................................ .........................  77 183 \nFIGURE 6 \u2013 UDP -5 CHAINING OF CDS................................ ................................ ................................ ...........................  78 184 \nFIGURE 7 \u2013 UDP -6 SWITCH OR SERVER CONNECTING DIODES  ................................ ................................ ..............................  79 185 \nFIGURE 8 \u2013 RECOMMEND DATA PATTERN /DATA TYPE MAPPING  ................................ ................................ .........", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}19{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "18", "chunk": ".................  80 186 \nFIGURE 9 \u2013 ADP -1 THE \u201cDOUBLE STAR\u201d GUARD  ................................ ................................ ................................ .............  80 187 \nFIGURE 10 \u2013 ADP -2: MULTIPLE DOMAIN LINEAR ASSURED PIPELINE  ................................ ................................ ....................  82 188 \nFIGURE 11 \u2013 ADP -3A: RECURSIVE DECOMPOSITION PIPELINE  ................................ ................................ .............................  84 189 \nFIGURE 12 \u2013 ADP -3B MULTI-DOMAIN RECURSIVE DECOMPOSITION PIPELINE ................................ ................................ .........  84 190 \nFIGURE 13 \u2013 ADP -4: REDUNDANT RECURSIVE DECOMPOSITION PIPELINE  ................................ ................................ ..............  86 191 \nFIGURE 14 \u2013 ADP -5: ALTERNATIVE RECURSIVE DECOMPOSITION PIPELINE  ................................ ................................ .............  87 192 \nFIGURE 15 \u2013 ADP -6: LINEAR ASSURED PIPELINE WITH COMPARATORS  ................................ ................................ ..................  88 193 \nFIGURE 16 \u2013 ADP -7: VIRTUAL MACHINE BASED ACCESS CDS ................................ ................................ .............................  90 194 \nFIGURE 17 \u2013 ADP -", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}20{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "19", "chunk": "8: REMOTE VDI  ACCESS CDS ................................ ................................ ................................ .............  92 195 \nFIGURE 18 \u2013 ADP -9: TACTICAL ACCESS CDS  WITH EMBEDDED TRANSFER CDS ................................ ................................ .......  93 196 \nFIGURE 19 \u2013 ADP -10: TWO DOMAIN TACTICAL CDS  USING CPU S AND FPGA S ................................ ................................ ..... 96 197 \nFIGURE 20 \u2013 ADP -11: TWO DOMAIN TACTICAL CDS  USING FPGA S (NO CPU S) ................................ ................................ .... 98 198 \nFIGURE 21 \u2013 ADP -12: TWO DOMAIN TACTICAL CDS  USING ONLY NVFPGA S ................................ ................................ ........  99 199 \nFIGURE 22 \u2013 ADP -13: TWO DOMAIN TACTICAL CDS  FOR LOW SWAP  ................................ ................................ ...............  100 200 \nFIGURE 23 - ADP -14 EXAMPLE OF HCFD  USED IN ENTERPRISE ENVIRONMENTS  ................................ ................................ .... 101 201 \nFIGURE 24 \u2013 OWT -18 UNACCEPTABLE DESIGN PATTERN #1 ................................ ................................ ............................  109 202 \nFIGURE 25 \u2013 OWT -18 UNACCEPTABLE DESIGN PATTERN #2 ................................ ...........", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}21{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "20", "chunk": "..................... ............................  109 203 \nFIGURE 26 \u2013 OWTDP -1: TRADITIONAL DIODE PATTERN ................................ ................................ ................................ .. 112 204 \nFIGURE 27 \u2013 OWTDP -2: TRADITIONAL DIODE PATTERN FOR BIDIRECTIONAL DATA FLOWS  ................................ ......................  113 205 \nFIGURE 28 \u2013 OWTDP -3: DIODE SANDWICH PATTERN  ................................ ................................ ................................ .... 114 206 \nFIGURE 29 \u2013 OWTDP -4A: MULTI-DOMAIN CDS  W/ HIGH THREAT CONNECTIONS PATTERN (BI-DIRECTIONAL ) ...........................  116 207 \nFIGURE 30 \u2013 OWTDP -4B: MULTI-DOMAIN CDS  W/ HIGH THREAT CONNECTIONS PATTERN (UNI-DIRECTIONAL ) .........................  117 208 \nFIGURE 31 \u2013 OWTDP -4C: DUAL MULTI-DOMAIN CDS  W/ HIGH THREAT CONNECTIONS PATTERN (BI-DIR) \u2013 OPTION 1 ................  118 209 \nFIGURE 32 \u2013 OWTDP -4C: DUAL MULTI-DOMAIN CDS  W/HIGH THREAT CONNECTIONS PATTERN (BI-DIR) \u2013 OPTION 2 ................  119 210 \nFIGURE 33 \u2013 OWTDP -4C: DUAL MULTI-DOMAIN CDS  + COMMERCIAL FILTERING APPLIANCE W /HIGH THREAT CONNECTIONS PATTERN 211 \n(BI-DIR) \u2013 OPTION 3 ................................ ................................ ................................ .....................", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}22{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "21", "chunk": "........... ...... 120 212 \nFIGURE 34 \u2013 OWTDP -4C: MULTI-DOMAIN CDS  + CDS  INTEGRATED WITH DIODE W /HIGH THREAT CONNECTIONS PATTERN (BI-DIR) \u2013 213 \nOPTION 4 ................................ ................................ ................................ ................................ ....................  121 214 \nFIGURE 35 \u2013 OWTDP -5 ARCHITECTURE  ................................ ................................ ................................ ......................  123 215 \nFIGURE 36 \u2013 OWTDP -6: ONE WAY TRANSFER WITH H/W  FILTERING  ................................ ................................ ................  124 216 \nFIGURE 37 \u2013 OWTDP -7A: BI-DIRECTIONAL TRANSFER WITH H/W  FILTERING ................................ ................................ .......  125 217 \nFIGURE 38 \u2013 OWTDP -7B BI-DIRECTIONAL WITH AN HCFD  & MULTI-DOMAIN CDS................................ ..............................  125 218 \nFIGURE 39 \u2013 OWTDP -8 PCIE CARD BASED PITCHERS AND CATCHERS ................................ ................................ .................  126 219 \nFIGURE 40 \u2013 EXAMPLE JOURNALING , AUDIT, AND LOGGING SUBSYSTEM ARCHITECTURE  ................................ ..........................  221 220 \nFIGURE 41 \u2013 DCCDS -FF/TSB  MULTIPLE DOMAIN ASSURED PIPELINE DESIGN", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}23{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "22", "chunk": " PATTERN  ................................ ..........................  284 221 \nFIGURE 42 \u2013 COMPOSED COTS  UNIDIRECTION AL CDS  DESIGN PATTERN  ................................ ................................ .............  285 222 \nFIGURE 43 \u2013 COMPOSED COTS  BI-DIRECTIONAL CDS  DESIGN PATTERN  ................................ ................................ ..............  285 223UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 7 of 397 FIGURE 44 \u2013 FSR-ADP -1 A SINGLE ISOLATED FILTER SIDECAR ENVIRONMENT  ................................ ................................ ...... 316 224 \nFIGURE 45 \u2013 FSR-ADP -2 MULTIPLE ISOLATED FILTER SIDECAR ENVIRONMENTS  ................................ ................................ .... 317 225 \nFIGURE 46 \u2013 FSP-UDP -1 SINGLE SIDECAR CONTROLLER ON THE CDS ................................ ................................ .................  317 226 \nFIGURE 47 \u2013 FSP-UDP -2 SINGLE PROCESS PER DOMAIN & COMBINED SIDECAR CONTROLLER PER DOMAIN  ................................  318 227 \nFIGURE 48 \u2013 FSP-UDP -3 - SINGLE PROCESS PER DOMAIN COMMUNICATING WITH SIDECAR CONTROLLERS  ..", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}24{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "23", "chunk": ".............................. . 318 228 \nFIGURE 49 \u2013 DFSR -ADP -1 SINGLE PHYSICALLY ISOLATED DFS  ENVIRONMENT  ................................ ................................ ...... 321 229 \nFIGURE 50 \u2013 DFSR -ADP -3 PER DOMAIN DFS  ENVIRONMENT  ................................ ................................ ..........................  322 230 \nFIGURE 51 \u2013 USE OF PITCHER /DIODE/CATCHER TO ISOLATE A DFS  FROM AN HTN  ................................ ................................ . 322 231 \nList of Tables  232 \nTABLE 1 \u2013 RTB  REQUIREMENTS BASELINE RELEASE TIMELINE  ................................ ................................ ..............................  21 233 \nTABLE 2 \u2013 CLASS OF ATTACK TO TECHNOLOGY MITIGATION MAPPING  ................................ ................................ ...................  58 234 \nTABLE 3 \u2013 TACTICAL CDS  WITH FPGA  ADP  COMPARISON ................................ ................................ ................................  100 235 \nTABLE 4 - APPROVED ALGORITHMS FOR IPSEC  ................................ ................................ ................................ ..............  352 236 \nTABLE 5 - APPROVED ALGORI THMS FOR TLS ................................ ................................ ................................", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}25{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "24", "chunk": " ..................  352 237 \nTABLE 6 - APPROVED ALGORITHMS FOR SRTP  ................................ ................................ ................................ ...............  353 238 \nTABLE 7 - APPROVED ALGORITHMS FOR DATA-AT-REST ................................ ................................ ................................ ... 353 239 \nTABLE 8 - APPROVED ALGORITHMS FOR SSH/SFTP/SCP  ................................ ................................ ................................ . 353 240 \n 241 \n  242UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 8 of 397 Change History  243 \nDate  Version  Description  \n21DEC2018  1.0 Official Release  \n4JAN2019  1.1 Released \u2013 Changelog detail s removed for brevity in V3.0  \n14MAR 2019  1.2 Released \u2013 Changelog detail s removed for brevity in V3.0. See version \nv2.1 and below for detailed changes.  \n1JAN2020  2.0 Released \u2013 Changelog detail s removed for brevity in V3.0. See version \nv2.1 and below for detailed changes.  \n7APR2020  2.1 Released \u2013 Changelog detail s removed for brevity in V3.0. See version \nv2.1 and below for detailed changes.  \n22DEC 2020", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}26{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "25", "chunk": "  3.0 Released \u2013 Changelog details removed for brevity in V 4.0. See version \nv3.0 and below for detailed changes.  \n18DEC2021  4.0 Released \u2013 Changelog details removed for brevity in V 5.0. See version \nv4.0 and below for detailed changes.  \n11JUL2022  4.1 Released \u2013 Changelog details removed for brevity in V 5.0. See version \nv4.1 and below for detailed changes.  \n1DEC 2022   5.0 rev 1-36 Added EDSR -15 \nAdded GAR -5.4.1 -5.4.6 \nAdded MPCR -38, MPCR -39 \nAdded CD MPCR Section  \nAdded OSSR -20.4 \nExpanded  the PFD explanation in Sec 0 \nAdded GDFR -17-.1 \nUpdated GDFR -27 to clarify o/s length cannot exceed o/s limit  \nAdded clarification to GDFR -11 \nReplace \u201cstage\u201d with \u201cpro cess\u201d in GDFR -13 \nGDFR -46 and -46.1 deleted and content merged with GDFR -31 \nGDFR -35.2 \u201cis not\u201d replaced with \u201cshall not be\u201d  \nGDFR -36 \u201cshould\u201d changed to \u201cshall\u201d  \nGDFR -37 \u201ca dataflow configuration\u201d changed to \u201cdata configurations\u201d  \nAdded GDFR -38.5 \nUpdated EDSR -12 switch to split keys  \nAdded SASR -4.4UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 9 of 397 Rewrote SIR -1.4 to fix the original intent of the requirement  \nUpd", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}27{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "26", "chunk": "ated SIR -14 to include logging  \nAdded SIR -16 to detect process death  \nAdded clarification to send of OWTDP -2 about Impl B and Impl C \nbeing physically separate servers  \nAdded JALSR -42 \nAdded SASR -16 and 16.1  \nUpdated Clarification for RMANR -10   \nAdded CMSR -11 \nAdded POLF to JALSR -1 \nFixed minor typo in SIR -15.2 \nAdded \u201ctransition to maintenance mode\u201c to JALSR -2.3 \nUpdated GDFR -25 to handle encr ypted data  \nAdded \u201ctruncated\u201c to JALSR -31 \nFixed internal order dependency issue with JALSR -13 \nAdded \u201c syntactically and semantically\u201d to JALSR -32 \nJALSR -12 merged with JALSR -9.1. Minor updates to JALSR -9.1 \nRemoved 2nd sentence from JALSR -2.4 and added Clarification about \nSASR -7.8 \nAdded T&W to JALSR  \nUpdated T&W for OSSR -30, RBACR -9, C2R -6 \nUpdated T&W for GAR -2.0, GAR -5.5, C2R -2, C2R -3, OSSR -10.2, \nOSSR -10.3.1, OSSR -12, OSSR -19, OSSR -20.1, OSSR -26, OSSR -32, \nOSSR -32.3.1, O SSR-32.3.2, OSSR -32.5.1, OSSR -32.6, OSSR -37, \nOSSR -39, OSSR -40.1, SASR -1, SASR -7.2.1, DPMR -7, DPMR -12, \nDPMR -12.1, DPMR -12.7a  \nAdded MPC to JALSR -2.3, 2.4, 2.5  \nAdded MPCR -40, 41, 41.1, 4 2 \nUpdated the definition of \u201cIndependent Implementations\u201d in the \nsection on RAIN to state the independent implementation SHALL be \nby different developers.  \nUpdated GAR -1.", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}28{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "27", "chunk": "1 to clarify independent.  \nOWT -17 now a SHALL  \nAdded FSR and DFSR sections  \nUpdated to required NIST -800 Rev 5 and related updated to CNSS -\n1253 and CDS Overlay  \nAdded RHRR -4 requirements to support overriding filteringUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 10 of 397 Deprecated ADP -1 \nAdded PAR -11 \nRewrote much of section 2 to improve clarity  \nChanged NRR -7 to remove restriction on MLS and transfer CDS. It \napplies to all CCDS  \nUpdated NRR -7.2 to clarify that separate physical interfaces should be \nused for management and monitoring functions  \nAdded rational to NRR -8 \nAdded DPMR -21 and -22 \n8.4.10 OWTDP -8 2.b \u2013 clarified soft core usage  \nAdded hardware content filtering device (HCFD) to OWT intro section  \nAdded OWT -25 through OWT -30 \nChanged OWTDP -7 to OWTDP -7a and added OWTDP -7b with \nHCFD support  \nAdded OSSR -27.2.1 \u2013 27.18  \nAdded \u201cfile transfer\u201d IPC to OSSR -27 \nDeprecated use of POSIX Semaphores  \nUpdated OSSR -27 Clarification  \nUpdated OSSR -27.2 word to improve clarity  \nAdde d Clarification to OSSR -27.2 \nImproved wording for FSR and DFSR sections  \nAdded to HTN DF", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}29{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "28", "chunk": "S drawing  \nAdded ACDSR -8 \nAdded OWT -31 \nAdded Clarification to MPCR -4 \nChanged DRR -8 from \u201cthe DR\u201d to \u201ca DR\u201d  \nAdded OSSR -27.2.1   \nRewrote part of MPCR -4 requirements to impro ve clarity and \nexpanded the clarification  \nMPCR -7 make interface/protocols both plural  \nAdded clarification to MPCR -10 \nAdded clarification to MPCR -7.2 \nRewrote MPCR -8 clarify which OCI specifications  \nMPCR -10 changed to shall  \nAdded Rationale to MPCR -10UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 11 of 397 Added Clarification to MPCR -11 and added \u201cexternally (to the CDS) \u201d \nto the requirement  \nAdded clarification to MPCR -14 \nAdded rationale to MPCR -25.2, MPCR -30, MPCR -31 \nReworded MPCR -37 to remove CDS developer testing  \nAdded clarification to CDMPCR -3 \nImproved wo rding for CDMPCR -6 \nAdded clarification to MLSWNR -10 \nAdded ACDSR -8.1-8.7 \nUpdated ACDSR -1 to require multi -factor authentication in alignment \nwith NSM -8 \nAdded ACDSR -9 \nAdded OWT -2.2 \u2013 2.4 to resolve ambiguities in the implementation of \nthe rule of three requirement.  \nUpdated MLSWNR -2 for RFC 3376/IGMPv3, RFC 3810/MLDv2  \nUpdated ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}30{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "29", "chunk": "MLSWNR -2.1 add IGMP and MLD  \nAdded rationale to MPCR -32 \nMPCR -6 Changed \u2018within a system \u2019 to \u2018within a specific CDS \u2019 \nAdded T&W for MPCR, PAR, and DRR  \nAdded Clarification to DPMR -12.15  \nMPCR -28 changed to should  \nAdded rational to OSSR -27.1 \nAdded Section 8.3.4 on hardware content filtering devices (HCFD)  \nExpanded clarification of PIR -1 \nExpanded discussion in section 1.2  \nAdded OWT -12.5 \nAdded clarification to TR -6 \nReworded TR -6.1 & 6.2 to improve clarity  \nReworded PMR -1 improve clarity  \nReworded NRR -8, moved example to clarification and the original \nclarification to NRR -8.1 \nReworded GAR -2 to improve clarity  \nChanged GAR -3 ingesting -> ingests  \nRewrote into to FRVR section  \nGAR -3.2 requirement  and rationale reworded to improved clarityUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 12 of 397 GAR -4, 5.1, 5.3, 5.4, 5.5, 6, 7, 7.2, 9.2 minor wording changes to \nimprove clarity  \nGAR -5.3 expanded clarification  \nAdded GAR -5.5.1  \nupdated clarification to PIR -7.1 \nupdated OSSR -27.9 \nAdded a Server -variant example at  end of section 8.3.2.1  ADP -7: \nVirtual Machine Based ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}31{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "30", "chunk": "Access CDS  \nAdded VIRT -8.3 \nHWR has largely been written to address changes for HCFDs, the new \ntactical CDS patterns from RTB 4.1, and the changes required for the \nCDS Anti -tamper requirements.  It is stron gly recommend ed that entire \nsection be reviewed carefully.  \nAdded HWR -16, -17, and -18 \nHWR -5.1 deleted. Replaced by HWR -18 \nHWR -5 updated to allow SystemVerilog  \nHWR -6 removed encryption comment  \nAdded HWR -6.1 and 6.2  \nImproved clarification for HWR -8 \nMinor rewording to HWR -11 to improve clarity  \nHWR -11.1 deleted.  \nSplit HWR -14 into 14.1 to improve testability of the \nrequirements  \nAdded HWR -17.1 to clarify security relevant \nnormalization/denormalization functions.  \nUpdated HWR -1, 8, 8.1, 9, 11, 11.3, 15, 15.1  \nAdded HWR -6.1, 12.1  \n5DEC2022  5.0  rev37  Added ADP -3b figure and renamed original ADP -3 to ADP -3a. \nAdd language to ADP -3 discuss use of a 2nd FRV in ADP -3b.  \nUpdate d multi -domain language in ADP -4 and ADP -5. \nExpanded intro to FRVR to cover multi -domain versions of AFP -3 & \nADP -5 \nAdded FRVR -12 and RPR -12 \nUpdated FRVR -9 and added Clarification to FRVR -9.1 \n9DEC2022  5.0 rev38  Added GAR -10 through GAR -10.6.1 related to handling of license \nkeysUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, J", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}32{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "31", "chunk": "PN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 13 of 397 12DEC2022  5.0 rev39   \n24DEC2022  5.0 rev40 -42 Added GCHQ CDS papers to references  \nAdded SIR -17, 17.1, 17.2  \n28DEC2022  5.0 rev43  Added SIR-11.5 \nMoved GAR -5.3.1 to SIR -11.6 \nUpdated SIR -11, 11.3., 11.4 to improve clarity  \nUpdated OSSR -4, 4.6, 4.7 to move supplemental  sentences into the \nClarification.  \n31DEC2022  5.0 rev44  Added rationale to EDSR -1.1 \nOSSR -8.5 added \u201cto CALD\u201d  \nAdded clarification to OSSR -35.2 \nAdded GDFR -49 \nChanged EDSR -9 to SHALL  \nChange  SIR-9 to SHOULD  \n1JAN2023  5.0 rev45  Added clarification to MPCR -5, -6 and expanded -7 \nMPCR -25.1 deleted  \nMPCR -20 \u201cpolicies\u201d -> \u201cconstructs\u201d  \nAdded language about documenting role actions in JALSR -39 \nAdded 140 -3 to EDSR -5 and EDSR -5.1 \nUpdated section 1.7 about FIPS 140 -2 \n5JAN2023  5.0 rev46  Minor wording tweaks to OWT -25, OWT -26 \nAdded \u201cin a n HCFD\u201d to OWT -29 \nSCR -2.2 \u2013 moved 2nd sentence to Clarification and added back in the \nlast se ntence from SCR -2.4 in RTB 3 to the clarification for SCR -2.2 \nAdded \u201cor teams\u201d to GAR -1.1 \n7JAN2023  5.0 rev47  Added deviation language  to 1.6  \n \n10JAN2023  5.0 rev48 -49 Tweaked wording", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}33{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "32", "chunk": " of sections 6.4 headers to phrase as threats  \nSplit OWT -28 and added OWT -28.1 \nUpdated Figure 22/HCFD to reflect DCO OOB connection for the \nHCFD  \nAdded HWR -19/20 for  sending logs from a HCFDUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 14 of 397 Changed all references to back channel and backchannel to back -\nchannel  \nAdded footnote to OSSR -36 \nAdded OSSR -27.19  \nAdded  SIHCR -20/20.1  \nAdded clarification  to OWT -12.5 \nAdded ACDSR -10 and 10.1  \nSection  15.2 CCOTS has been deprecated for USG use. See new \nintroduction to section on where it can be used.  \nSplit CDMPCR -14 and added CDMPCR -14.1 \nSplit DFSR -26 list into DFSR -26.1 \u2013 26.7 \nRemoved references to U/HTN since it was causing confusion.  \nRewrote OWT -25 to improve clarity and added a Clarification  and \ntweaked Rationale  \nAdded NRR -11 \n11JAN2023  V5.0 rev 50  Added SIR -3 \nAdded Section 24  CDS Decommissioning and Reuse Requirements \n(CDRR)  \nAdded additional sub -bullet s under 7.3 RAIN/Independent \nImplementa tions/ Different developers  \n13JAN2023  V5.0 rev 51  Added OWT -31.1 \nUpdates to Section 1.7  \nAdded section to 8.4 ab", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}34{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "33", "chunk": "out deprecating low side filtering in PDC in \nfuture release.  \nAdded Clarification  to GAR -1.1 \n16JAN2023  V5.0 rev 52  Added Clarification to OWT -12.3 \nAdded Clarification NRR -8.1 \nMinor wording tweaks to GAR -1.1 \nGAR -7.2 reword to improve clarity  \nAdded Clarification to GAR -9.2 \nUpdated section 9 intro on class/model and sub -requirements  \nAdded phase out of CMSR -3.1 PXE Boot to Section 1.7  \nSplit DFSR -20 and added DFSR -20.1 \nDFSR -25 is now a SHOULD and fixed DFSR -25.3 number to be 25.1  \n17JAN2023  V5.0 rev 53  Added EDSR -16, 16.1, and 17 to support disabling and enabling fullUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 15 of 397 disk encryption to support incident response/insider threat activities.  \nAdded RBACR -3.1.14 , 3.1.13 , 3.2.8 , 7.17 \nMajor rewrite of DPMR -4 to improve clarity of requirement, \nclarification, and  rationale. Added support for python and similar \ninterpreted languages that can be compiled into executable form.  \nUpdated DPMR -7 to add Protocol Adapters and added support for \npython and similar interpreted languages that can be compiled into \nexecutable fo rm.", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}35{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "34", "chunk": " Update rationale.  \nDPMR -8 2nd sentence moved to Clarification  \nEDSR -1 2nd sentence moved to Clarification and fixed wording issue.  \nMultiple updates to EDSR -15 and its sub -requirements and \nclarifications to improve clarity  \nAdded T&W to FRVR section  \nUpdate d Figure 35 \u2013 OWTDP -5 Architecture  to show DCO OOB \nconnection s \n25JAN2023  V5.0 rev 54  Added CMSR -4.3.1  \nAdded GDFR -38.6 and rewrote 38.5  \nMoved 2nd sentence  in TR -6.2 to TR -6.2.1  \n30JAN2023  V5.0 rev 55/56  Changed CDRMPCR -10 & 11so either can be done  \nDeleted TPR -7 and moved to SC -13 and expanded to cover Enterprise \nenvironments  \nDeleted TPR -6 and moved to SC -12 and reworded  \nUpdated GAR -5.5 to cover device insertions , removals , changes  \nRewrote SIR -14 to cover just unauthorized  processes  \n31JAN2023  V5.0 rev57  Update SIR -1.4 clarificatio n \nAdded phase out of SIHCR -3.3 PXE Boot part to Section 1.7  \nAdded SIHCR -3.3.4 and 3.3.5  \nAdded T&W to RPR  \n2FEB2023  V5.0 rev58  Added RBACR -7.18 \nAdded Clarification to PAR -11 \nAdded comment to OSSR -25.1 \nAdded FSR -2.1 \nAdded Clarification  to GAR -5.4.4  \nReworded GAR -5.5 to improve intent  \nGFDR -17.1 Moved 2nd sentences  to Clarification and addedUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, N", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}36{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "35", "chunk": "OR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 16 of 397 clarification about send original failed fail to DCO OOB  \nMoved 2nd sentence in GDFR -27 to GDFR -27.1 \nRemove clarification from HWR -10.1 and moved to Section 1.7  \n8FEB2023  V5.0 rev59  Added clarification to MPCR -2.2 \n9FEB2023  V5.0 rev60  Moved MPCR -41 to JALSR -43 \nMoved MPCR -41.1 to MPCR -41 \nAdded OSSR -27.15.1  \nUpdated MLS -7 \n13FEB2023  V5.0 rev61/62  Added SIHCR -21 \nUpdated introduction to 8.3.3.2  \nAdded clarification to MPCR -20 and MPCR -21 \nAdded clarification VTR -2 \nAdded OSSR -43 and OSSR -44 \nAdded clarification to SASR -7 about CMS.  \n14FEB2023  V5.0 rev63  Added intro to OSSR section to handle software components in \nhardware -based CDS  \nUpdated section 9 intro about applicably of software requirements to \nhardware -based CDS that include software components.  \nAdded clarification to DPMR -10 \nRemove \u201ctemperature\u201d fr om TPR -13.3 \n18FEB2023  V5.0 rev64  Minor updates to OWT -13 and OWT -14 to improve clarity  \nImproved wording of PFD section of Section 8.4 to clarify what must \nbe filtered in the PFD hardware  \nUpdated OWT -20 to allow SystemVerilog  \nImproved intent and clarity of OWT -22.1  \nAdded JALSR -44 ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}37{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "36", "chunk": "\n21FEB2023  V5.0 rev65  Added Clarification to NRR -7 \nAdded \u201cPFD\u201d to OWT -29 \nAdded \u201cper destination\u201d to OWR -31 \n28FEB2023  V5.0 rev 66 -69 Added TPR-13.7 \nAdded  TPR-13.8 \n29FEB2023  V5.0 rev 70  Major updates to CMSR to handle both CMS servers and CMSUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 17 of 397 applications.  Added CMSR -12 thru 23 and CMSR -1.1 & 1.2  \n21MAR2023  V5.0 rev 71 -74 Updated OWTDP -4C Option 1 drawing  \nTHA and HWR sections deleted and replaced by new HWCR  \nAdded \u201caudit data\u201d and \u2018Log data\u201d to definitions list  \nRemoved examples from MLS -5 requirement  statement.  \nSubstantially increase the background information for JALSR section \nintroduction  \n5APR 2023  V5.0 rev 75 -76 Added OSSR -45 \nAdded clarification to RBACR -11 \n8APR2023  V5.0 rev 77  MPCR -33 changed to SHALL  \nMPCR -33.1 split into .1 - .3 \nAdded OWTDP -1/OWTDP -2 phase out timeline in Section 1.7  \nChanged OWTDP -1 Variant 1  to be preferred version for L2H  \nUpdated OWTDP -1 Variant 1 & 2 about normalization  and \ndenormalization functions  \n12APR2023  V5.0 rev 78  Updated SFPGA -8 and WNVFPGA -5 to clarify they", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}38{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "37", "chunk": " apply to clock \nand voltage glitches  \nSFPGA -6, SFPGA -2 Deleted.  \nWNVFPGA -4 Deleted.  \nUpdated ADPs 10 -13 to remove support for the management CPU  \n27APR2023  V5.0 rev79  MLS -3 visit subject/object issue.  \nUpdated MLSWNR -5 and MLDBR -5.1 to support the new S OSA v2 \nstandard for Layer 2 labeling of packets.  \nAdded OSSR -4.9 \nAdded explanation to 8.3.3.1  about rationale for removing support for \nFPGAs with embedded CPU and caveat for RTB 4.1  \nAdded HWC -TR-9 \n30APR2023  V5.0 rev80  Added T&W to MLS  \nSFPGA -10 changed to should  \nAdded RMANR -11 \nCDMPCR -5.1 removed  \n1MAY2023  V5.0 rev8 1 Removed text in () for Dataflow ID from RHRR -3.6.2  \nFixed RHRR -6 reference in RHRR -3.7.1UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 18 of 397 Updated clarification for RHRR -3.4.6  \n7MAY2023  V5.0 rev82  Remove d FSR-17 & 17.1  and reordered FSR  \nExpanded intro the FSR section  \n9MAY2024  V5.0 rev83/84  Rewrote OWT -17 and added OWT -17.2/17.3  \n11MAY2024  V5.0 rev85  EDSR -1.1 now a SHALL  \nDCOR -6.1, EDSR -7.1, RHRR -3.6.2 , GDFR -44 converted from \nSHA2 -256 to SHA -384 \nUpdated EDSR -1 Clarificatio", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}39{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "38", "chunk": "n for CNSA v2.0 support  \nCMSR -0.0.1 changed to SHALL \nAdded Appendix I \u2013 Alignment of RTB requirements to NIST \nControls  \n 244 \n1  245 \n1.1  246 \n1.2  247 \n1.2.1  248 \n1.2.2    249 \n1  250 \n  251UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 19 of 397 1 Document Overview  252 \nThis document  establishes architecture  and implementation requirements for the development of 253 \ncross domain solutions (CDS). The fundamental premise behind this document is that 254 \nimplementing security controls is not sufficient  to make a CDS  safe to operate  or to perform its 255 \ncore function adequately.  While the primary objective of the Raise the Bar ( RTB ) Strategy  is to 256 \nensure the United States Government (USG) has secure  and resili ent CDS, its secondary 257 \nobjective is to enable the development of CDS that can be quickly  and securely enhanced with 258 \nnew capabilities  and features . 259 \nThis do cument defines the architecture  and implementation requirements for the National 260 \nSecurity Agency (NSA) /U.S. Cyber Co mmand (CYBERCOM) RTB  Strategy. The RTB Strategy 261 \nwas approved by the Departme", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}40{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "39", "chunk": "nt of Defense ( DoD ) Information Security Risk Management 262 \nCommittee (ISRMC) in December 2017 . In the DoD  Chief Information Officer (CIO) 263 \nmemorandum  \u201cImplementing Cross Domain Bug Bounty Remediation \u201d dated 5 April 2018  all 264 \nCDS used by the DoD  shall be compliant  with RTB by FY2020.  Under NSD -42 and NSM -8, all 265 \nCDS developed for use to protect USG National Secu rity Information (NSI) and National 266 \nSecurity Systems (NSS) are required to implement the requirem ents described in this 267 \ndocument1.  268 \nThis document also applies to all CDS designed to support  Foreign Military Sales (FMS) . CDS 269 \nused in FMS are intended to pro tect the exchange of information between classified or sensitive 270 \nU.S. sensors and weapon systems, which have been developed for the USG  but sold to a Foreign 271 \nPartner  and used in a Foreign Partner\u2019s other classified or unclassified networks.  272 \nCompliance with  this requirements document is required for CDS to be listed on the NCDSMO  273 \nUSG and FMS CDS Baseline Lists.  274 \nThis document assumes the reader has read the NCDSMO documents2: 275 \n\u2022 CDS 101: An Introduction to  Cross Domain Solution s (NCDSMO Doc  ID: NCDSMO -G- 276 \n00032 -001_00 ) describes  concep ts and terms that will be used in this docum", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}41{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "40", "chunk": "ent  without 277 \nfurther explanation . 278 \n\u2022 Security Assessment of Cross Domain Solutions (CDS): Process and Requirements  279 \n(NCDSMO Doc  ID: NCDSMO -R-0000 3-004_00) describes key concepts and 280 \nterminology related to the assessment ( e.g., security testing) of CDS . 281 \n\u2022 Cyber One-Way Taps Technical Requirements  (NCDSMO Doc ID: NCDSMO -R-00016 - 282 \n001_ 01) describes the requirements for the design, implementation, and testing 283 \n \n1 This includes CDS operating between any USG, Bi -lateral, and Coalition classified networks (e.g., S//REL A to \nS//REL B).  \n2 To obtain a copy of any of the documents, email ncdsmo @nsa.gov  (NIPRNet), ncdsmo @nsa.smil.mil  (SIPRNet), \nor ncdsmo @nsa.ic.gov  (JWICS) or at the NCDSMO\u2019 s Intelink -U site: https://intelshare.intelink.gov/sites/ncdsmoUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 20 of 397 requirements of one -way taps and diodes . 284 \n\u2022 Versioning and Patching Requirements for Cross Domain Solutions (CDS)  (NCDSMO 285 \nDoc ID: NCDSMO -R-00002 -003_00) provides the requirements for ver sioning of CDS, 286 \nhow CDS patching will be implemented, a", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}42{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "41", "chunk": "nd general guidance on the scope of testing 287 \nrequired for different changes to a CDS . 288 \n\u2022 Cross Domain Solution (CDS)  Development and Testing Environment  Security 289 \nRequirements (NCDSMO Doc ID: NCDSMO -R-00011 -001_ 01) describe s the security 290 \nrequirements  for CDS development and testing environment s to protect against adversary 291 \ntheft of CDS technology (e.g., software, hardware designs, documentation) and 292 \nmanipulation and implantation of CDS software and hardware . 293 \nIt is strongly recommend ed that the reader also  read the following documents:  294 \n\u2022 Guidance for Enabling Rapid Application Deploy ment with Cross Domain Solution 295 \n(NCDSMO Doc  ID: NCDSMO -G-00027 -001_ 02) provides best practices guidance 296 \nintegrating  custom er applications with CDS . 297 \n\u2022 Primer for Cyber Incident Response of Cross Domain Solutions (CDS) , (NCDSMO Doc  298 \nID: NCDSMO -G-00049 -001_00 ) describes overview of what to do and not do when 299 \nperforming  incident response activities involving a CDS . 300 \n\u2022 Frequently Asked Questions about the Release and Export of Cross Domain Solutions  301 \n(NCDSMO Doc  ID: NCDSMO -G-00028 -001_01 ) provides guidance and rules on how 302 \nCDS used to protect USG NSS are releas ed and exported to foreign Government s. ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}43{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "42", "chunk": "303 \n\u2022 Using Linux Secure Computing (SECCOMP) Mode in Cross Domain Solutions  304 \n(NCDSMO Doc ID: NCDSMO -G-00050 -001_ 01) 305 \n\u2022 Manage and Secure Processes on Linux -based Cross Domain Solutions Using 20ystem  306 \n(NCDSMO Doc ID: NCDSMO -G-00051 -001_00 ) 307 \n\u2022 Using Linux Namespaces and Control Groups (CGROUP) to Secure Cross Domain 308 \nSolution Processes  (NCDSMO Doc ID: NCDSMO -G-00052 -001_00 ) 309 \n\u2022 Using Linux Containers with Cross Domain Solutions  (NCDSMO -G-00053 -001_00 ) 310 \n\u2022 Analysis of Linux Interprocess Communication (IPC) Mechanisms for use in Cross 311 \nDomain Solutions  (NCDSMO Doc ID: NCDSMO -G-00054 -001_00)  312 \n\u2022 Using Linux Capabilities  in Cross Domain Solutions  (NCD SMO Doc ID: NCDSMO -G- 313 \n00055 -001_00 ) 314 \n\u2022 Requirements for the Cross Domain Transfer of Software  (NCDSMO -R-00014 -001_0 2) 315 \n\u2022 CDS  Anti-Tamper and TEMPEST Implementation Requirements  (NCDSMO Doc ID:   316 \nNCDSMO -R-00018 -001_00 ). This document is classified at the Secret level and is 317 \navailable by request from the NCDSMO and is need -to-know only . 318 \n\u2022 Required Audit Events for Cross Domain Solutions  (NCDSMO Doc ID:  NCDSMO -R- 319 \n00019 -001_00)  320 \n\u2022 Managing the Cross Domain Solution Baseline and Sunset Lists  (NCDSMO Doc ID:  321 \nNCDSMO -R-00017 -0", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}44{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "43", "chunk": "01_00 ) 322 \nImplementing RTB requirements substantially reduces  the risk  of an unsu ccessful L ab-Based 323UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 21 of 397 Security Assessment  (LBSA)  of th e CDS and the additional costs to remediat e the testing 324 \nfindings afterwards.  325 \nFor the purposes of this document, the term s developer  or vendor  apply  to the following: (1)  a 326 \nUSG organization that is developing a CDS internally (using government  personnel), (2) a 327 \ncontractor contracted by the USG to develop a CDS, or (3) a commercial entity that is 328 \ndeveloping a CDS using internal funding . 329 \n1.1 Restrictions on Use  and Document Versio ning  330 \nThis requirement s document is applicable for  CDS  entering the LBSA process  using a three year 331 \nsliding window starting the year after the release of a \u201c Cross Domain Solution (CDS) Design and 332 \nImplementation Requirements: Raise the Bar (RTB) Baseline Rel ease\u201d.  * 333 \nFor this edition of the Cross Domain Solution (CDS) Design and Implementation Requirement s 334 \ndocument, a  new CDS, or modification s to an existing CDS, ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}45{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "44", "chunk": "that is accepted into the  LBSA  335 \nprocess prior to 1 January 2028, shall comply with the requirements contained within this  336 \nversion or a newer version of this  document. A new CDS, or modifications to  an existing CDS, 337 \naccepted into LBSA after  1 January 2028 shall comply with an approved version of this 338 \ndocument  at that time.  For example, a  CDS entering LBSA in 2028 would be allowed to use the 339 \n2024, 2025, 2026, 2027, and, if available, the 2028 version of this document. But it would no t be 340 \nable to use the 2021 or 2023 version s. It is recommended that the latest released version of this 341 \ndocument  be used.  An example of the RTB baseline applicability timeline is shown in the table 342 \nbelow . A CDS may enter a Delta LBSA or a Regression LBSA under the same version of RTB 343 \nfor which it was tested if the \u201cDev & Test\u201d window (i.e., green block in Table 1) is still in effect. 344 \nModular Pipeline Components (MPC) can be tes ted for a version of a CDS in its \u201cDev & Test \u201d 345 \nand \u201cDeployment \u201d timelines.   346 \nIf the CDS is in the valid Dev & Test or Deployment time window  for the version of RTB under 347 \nwhich it was tested : 348 \n1) Any Modular Pipeline Component Testing (MPCT) testing or any hundredths -level  (in 349 \nthe version o", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}46{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "45", "chunk": "f CDS product ) chang es will be assessed using the version of RTB used to 350 \ntest the Major/Tenths version of the CDS.  This applies only the RTB v5.0 and higher . 351 \n2) The NCDMSO may, at its sole discretion but in consultation with the developer and lab, 352 \nallow CDS with tenths -level changes to be assessed using the version of RTB used to test 353 \nthe Major version of the CDS. This applies only the RTB v5.0 and higher.  354 \n 355 \nTable 1 \u2013 RTB Requirements Baseline Release Timeline  356 \nRTB \nRequirements \nBaseline \nRelease Year   Development, Testing, Deployment, and Sunset Timeline  \nCY24  CY25  CY26  CY27  CY28  CY29  CY30  CY31  CY32+UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 22 of 397 2023  Dev & Test  Deployment  Retiring & Sunset Process  \n 357 \nThis document will be reassessed annually  (this is called a yearly release)  and modified as 358 \nnecessary to address new threats , new CDS functionality, and incorporate new knowledge  (e.g., 359 \ntechnologies, polic ies, procedures,  and directives) .  During the year, incremental updates to this 360 \ndocument may occur to address critica", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}47{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "46", "chunk": "l new threats, resolve ambiguities, resolve issues found 361 \nduring LBSA  that could impact multiple CDS , and provide securit y requirements for new 362 \ncapabilities that cannot wait until a new yearly release of the document3.  The latest version of a 363 \nyearly release is considered the valid and active version  for that year . Earlier versions  of a yearly 364 \nrelease  are immediately deprec ated on the release of a new version  for that year . CDS currently 365 \nscheduled for a LBSA by the NCDSMO (with a specific start date and assigned lab) or currently 366 \nin LBSA will use the active version at the time they committed to a LBSA start date.  367 \nAt the end of the Deployment period  the CDS will be assigned retiring  status , unless there  are 368 \nspecific issue s like end -of-life (EOL) or end -of-support (EOS) operating system, components,  or 369 \nhardware  which automatically sunset  the CDS. The r etiring (also called sunsetting ) process is 370 \ndescribed in Managing the Cross Domain Solution Baseline and Sunset Lists . 371 \nIf a new version of this document is not released for a specific year, then the last released version 372 \nshall remain in effect until a new version of this document is released.  The RTB Requirements 373 \nBaseline Release Timeline will aut", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}48{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "47", "chunk": "omatically adjust by shifting the Dev & Test and Deployment 374 \ntimelines to the right each year until a new document is released.  375 \n1.2 Tailoring of Requirements  376 \nThe NCDSMO  recognizes that not all RTB requirements apply to a specific CDS and even to all 377 \nclasses of CDS  and that all RTB requirements cannot be implemented during a single update to a 378 \nCDS . CDS Developers4 are encourage d to engage with the NCDSMO throughout  the d esign 379 \nprocess of their CDS so that the requirements can be review ed and tailored for the unique 380 \ncharacteristics of the CDS.  381 \nThere are multiple ways to solve many of the security requirements and concerns in RTB. RTB 382 \nintentionally tries to implement redundant mechanisms,  when possible,  to reduce the risk of a 383 \nsingle mechanism failing due to a configuration mistake or software defect. If a vendor has 384 \nanother mechanism to solve a specific requirement  other than the mechanism prescribed in RTB , 385 \n \n3 If a multiple CDS are entering or projected to enter LBSA during the lifespan of this document and there is not \nsufficient security guidance on a particular capability and that without the g uidance it could lead to unsafe \nimplementations, then this document would be updated to address the issue.  \n4 ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}49{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "48", "chunk": "The terms CDS Developer and CDS Vendor are interchangeable in this document. If a CDS is developed by a \nGovernment PMO, then the PMO would be consi dered part of the CDS development team.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 23 of 397 then that should be discussed with the NCDSMO to determine sufficiency and conformance with 386 \nthe intent of the requirement(s).  However, any a lternative  mechanism must address the core 387 \nsecurity design principles discussion in Section 7 (e.g.,  RAIN, POLK, POLF, POLP).  388 \n1.3 Order of Precedence  389 \nUnless otherwise stated herein or in the Federal Acquisition Regulation (FAR) or the Defense 390 \nFederal Acquisition Regulation Supplement (DFARS) contract language, this requirements 391 \ndocument takes precedence over requirements defined in previous USG Directive s or 392 \nInstructions for the design, development, testing , assessment , and fielding of a CDS .  393 \nNothing  in this document  overrides  applicable U.S. law or regulation unless  a specific exemption 394 \nhas been obtained.  395 \n1.4 Clarification on Terminology Usage  396 \nThis document ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}50{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "49", "chunk": "occasionally uses the term s Low and High to refer to security domains. In most 397 \nrequirements or examples, i t does not discuss domain s beyond Low and High. However, u nless 398 \notherwise stated or implied ( e.g., in the diode section), the requirements in  this document apply 399 \nto CDS that support  multiple (2 or more ) security domains.  400 \nIn some cases, CDS are connected to domains that have no dominance relationship ( e.g., S//REL 401 \nUSA, FRA and S//REL USA, GBR are equivalent and neither dominates the other). In those 402 \ncases , there is no Low or High security domain. As a rule , the network of higher threat  should be 403 \ntreated  as the Low domain. Also, because the re is no dominance between the domains there is no 404 \nformal system high domain  so the remote management, remote monitoring, and Defensive 405 \nCyberspace Operations (DCO) of CDS activities must be conducted on  network s that dominate  406 \n(e.g., a Secret No Foreign netwo rk dominates all S//REL networks)  the other security domains 407 \nconnected to the CDS.  408 \n1.5 Requirements Terminology  409 \nThis requirements document uses key words from  Request for Comments ( RFC ) 21195 to 410 \nindicate requirement levels. The definitions are modified slightly  from RFC 2119 to improve 411 \ncla", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}51{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "50", "chunk": "rity.  412 \nMay   413 \nThe word may, or the adjective optional , mean s that the requirement is truly optional. 414 \nSystems  are permitted to implement  but are not required to  implement . 415 \nShould   416 \n \n5 RFC 2119 \u2013 \"Key words for use in RFCs to Indicate Requirement Levels \u201d, https://www.ietf.org/rfc/rfc2119.txtUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 24 of 397 The word should , or the adjective recommended , mean s that there may exist valid reasons 417 \nfor a particular implementation to deviate  from this requirement , but that such deviation 418 \ncould impact security, interoperability, and functionality.  419 \nMust   420 \nThe word must , or the term s required  or shall , mean s that the behavior described i s an 421 \nabsolute requirement of this document  and must be part of any implementation.  422 \n1.6 Deviations from Requirements in this Document  423 \nThis document and its supporting documents are intended to be a comprehe nsive set of CDS 424 \ndesign and implementation security requirements.  Deviations from this document must be 425 \ndiscussed with the NCDSMO prior to starting dev", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}52{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "51", "chunk": "elopment.  426 \nThe NCDSMO understands that some deviations in the design and requirements may be 427 \nnecessary f or different mission applications, operational or unique threat environments, and 428 \ntechnology choices. The NCDSMO also understands that security technology continually 429 \nevolves.  If a developer or researcher develops a new design, a better set of requirement s, new 430 \nrequirements, or a clearer way to phrase a requirement, the NCDSMO is willing to listen, learn, 431 \nand adjust. If authorized by the developer/researcher, the NCDSMO may incorporate those ideas 432 \ninto future versions of this document. The CDS community ca n only improve and evolve 433 \nrequirements through technical exchange and collaboration and therefore encourages open 434 \ndialogue throughout the CDS community.  435 \nAt its discretion, NCDSMO may consider justifiable reasons to provide a deviation  to a 436 \nrequirement.  437 \n1.7 Notice of Future Changes  438 \nThis section provides  early notification  to developers of requirements that are known to be 439 \nchanging (may/should to shall or  deprecated) or will be added in a future RTB release (year 440 \nstated).  441 \n1. Remo val of support for traditional diodes that lack any hardware -based  filtering 442 \nconnected to high threat n", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}53{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "52", "chunk": "etworks. Start migration to hardware -based  filtering for high 443 \nthreat network connections  to Classified NSS . Expected in 2025 release.  444 \n2. Support for cryptographic modules certified against FIPS 140 -2 will be removed in a 445 \nfuture revision.  Expected in 202 6 release.  See https://csrc.nist.gov/projects/fips -140-3- 446 \ntransition -effort  447 \n3. Removal of support  traditional Pitcher/Diode/Catcher solutions  (e.g., OWT DP-1, 448 \nOWTDP -2, that are designed and tested to be a CDS , that perform filtering on the low 449 \nside of the diode (if connected to an HTN). Future systems will be  required to move all 450 \nsecurity relevant filt ering to the high side of the diode if connected to the HTN. 451 \nNormalization of data  can remain on low  however any denormalization that is security 452UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 25 of 397 relevant (e.g., video recompression) must be on high.  Expected in 2024 release.  New 453 \nsystems being developed are strongly urged move filtering to high side component.  454 \n4. SIHCR -3.3 (PXE Boot Portion) and CMSR -3.1 (PXE Boot) will be r", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}54{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "53", "chunk": "emoved in favor of 455 \nthe more secure HTTP Boot in 202 4. 456 \n5. Use of Virtual TPMs for VM s will be required in the next release (VIRT -28). 457 \n1.8 CDS and Cryptographic Devices  458 \n(U//FOUO)  The requirements in th is document apply to all cryptographic dev ices that embed 459 \nCDS functionality. Some NSA Certified Cryptographic Devices may have \u201cby-pass\u201d channels 460 \nused solely for controlling the encryption device. \u201cBy-pass\u201d channels are not intended for 461 \ntransferring mission data. If a USG mission system or a Crypt ographic Device developer intend s 462 \nto use the \u201cby-pass\u201d channel mechanism to pass mission data,  then that device must meet the 463 \nCDS requirements in this document. Any use of a Cryptographic Device as a CDS must be 464 \ncoordinated with the NCDSMO and NSA Encryption Products and Solutions Group  prior  to 465 \ndevelopment. The NCDSMO, at its discretion , may allow  the Encryption Products and Solutions 466 \nGroup  to evaluate the CDS functionality o r the NCDSMO may elect to test the CDS 467 \nfunctionality at an NCDSMO  certified testing lab.  468 \n2 Should We Build a  New CDS?  469 \nThe short answer to the question \u201cShould we build a new CDS ?\u201d is no . Department of Defense 470 \nInstruction ( DoD I) 8540.01  states  that the  \u201cDoD  will emp", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}55{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "54", "chunk": "loy existing Enterprise Cross Domain 471 \nService Provider\u2019s ( ECDSP ) enterprise CD service or enterprise -hosted CDS when their use 472 \nsatisfies the CD mission requirements of DoD  Components.  Leveraging another operational 473 \nCDS, deployment of  a CDS from the NCDSMO USG CDS Baseline List,  or development of a 474 \nnew CD technology will be considered as alternative solutions only when an enterprise solution 475 \ncannot meet the CD capability requirements\u201d . An Intelligence Community (IC) Chief 476 \nInformation O fficer (CIO) CDS memorandum (ODNI Cross Domain Support Element (CDSE)  477 \nmemo signed 11/3/2011) states that organizations must use an Enterprise Cross Domain Service 478 \nfirst if it meets  their requirements.  For the  Department of Defense  (DoD ) and IC , the primary  479 \ngeneral purpose  ECDSP s are:  480 \n\u2022 Defense Information Systems Agency ( DISA ) for Non-Secure Internet Protocol (IP) 481 \nRouter Network ( NIPRNet ) and Secure IP Router Network ( SIPRNet ) connections  482 \n\u2022 Defense Intelligence Agency ( DIA) for NIPRNet , SIPRNet , and  Joint Worldwide 483 \nIntelligence Communications System ( JWICS ) connections  484 \n\u2022 United States Air Force ( USAF ) Secretary of the Air Force ( SAF)/Concepts 485 \nDevelopment and Management ( CDM ) United States ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}56{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "55", "chunk": "( US) Battlefield Information 486 \nCollection and Exploitation System  (BICES ) Program Office  for coalition and bi -lateral 487 \nnetworks  including Combined Enterprise Regional Information Exchange System 488 \n(CENTRIXS ) 489UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 26 of 397 \u2022 Intelink -U and Intelink -S 490 \n\u2022 DoD and IC -authorized Commercial Cloud Enterprise Cross Domain Service Providers6 491 \nThere are other  mission specific  ECDSP s for weather, Signals Intelligence ( SIGINT ), biometrics,  492 \nand Geospatial Intelligence  (GEOINT )7.  493 \nBefore doing anything contact your Service/Agency Cross Domain Support Element 494 \n(CDSE) or the NSA /NCDSMO  for advice . Do not start design or procurement of a CDS 495 \nwithout talking to yo ur CDSE or the NSA/NCDSMO first . 496 \nThe list of CDSEs can be found at:  497 \nhttps://intelshare.intelink.gov/sites/ncdsmo  498 \nWhen  contact ing your CDSE, you should complete the NCDS MO \u201cCDS Support Questionnaire\u201d 499 \n(NCD SMO Doc ID : NCDSMO -F-00001 -005_02). It will help you articulate  your requirements 500 \nin a way that your CDSE and/or the NCDSMO ca", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}57{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "56", "chunk": "n understand efficiently . The questionnaire  can 501 \nbe obtained by email ing ncdsmo @nsa.gov  or by contacting your CDSE.  502 \n2.1 Buy, Buy and Modify, or Build  New? 503 \nIf use of an ECDSP  will not support your validated mission requirements , then there are  three 504 \noptions  (provided here in order of preference) : 505 \nOption 1.  Buy 506 \no There are many  Government -Off-The-Shelf ( GOTS ) and Commercial -Off-The- 507 \nShelf ( COTS ) options for CDS technology  on the NCDSMO CDS Baseline .  508 \no Most likely, one already exists that can be used out -of-the-box or with new 509 \nrulesets or schemas  510 \no This approach is usually the lowest technical and approval risk, most cost 511 \neffective, and fastest solution to get deployed . 512 \nOption 2.  Buy an d Modify  513 \no CDS are modified to support unique mission specific protocols, data formats, or 514 \nSpace, Weight, Power, and Cooling (S waP-C) requirements . 515 \no Generally, it is much cheaper and faster and with lower schedule, technical, and 516 \nsecurity risks to fund modifi cations to an existing CDS than to start from scratch . 517 \no Modifications to the CDS will requir e testing  in an NCDSMO  certified lab  518 \ntypically in a Delta Lab -Based Security Assessment (DLBSA) . 519 \n \n6 For example, the Join", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}58{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "57", "chunk": "t Warfighting Cloud Capability (JWCC) , https://community.hacc.mil/s/jwcc  \n7 For more information on the criteria for ECDSP and which ECDSPs exist contact the NCDSMO at \nncdsmo@nsa.gov  (NIPRNet), ncdsmo@nsa.smil.mil  (SIPRNet), or ncdsmo @nsa.ic.gov  (JWICS).UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 27 of 397 o CDS that leverage Modular Pipeline Components (See Sections 11.4 and 11.5) 520 \nare designed to be able to add  new capabilities  with a shorter , less expensive 521 \nassessment activity ( i.e., Modular Pipeline Component Testing (MPCT)).  522 \no This approach is more expensive than buy and less expensive than build  new. It 523 \nhas lower technical, authorization, and deployment timeline risk than build  new. 524 \nOption 3.  Build New  525 \no Used only when an existing CDS cannot be used or modified to meet mission 526 \nrequirements . 527 \no It has high technical, security, p rogrammatic, and schedule risks . 528 \no A development program can expect building a new CDS to take at least 2 -5 years 529 \nand cost in the millions of dollars . 530 \no An NCDSMO  Full Lab -Based Security Assessment (F", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}59{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "58", "chunk": "LBSA)  is required for new  531 \nCDS . 532 \no This approach is the most expensive, has the highest technical and authorization 533 \nrisk, and has the longest timeline to deployment . 534 \no If this is the option that must be selected, consider leveraging a proven CDS 535 \ndeveloper.  536 \n\u25aa The divisions of most companies that build weapon systems/sens ors do 537 \nnot have extensive experience on how to build a CDS, but other divisions 538 \nof the company might. NCDSMO has seen this all too often when a 539 \ncompany does not reach out internally or externally to CDS experts and 540 \nthe results are rarely good.  541 \n 542 \nIf buying, modifying , or building a CDS, then the CDS must be compliant with the requirements 543 \nin this document or have approved deviations. This document will help an organization 544 \nunderstand if the CDS being purchased is likely to achieve security authorization and, thus, be 545 \ndeployable. The remainder of this document is directly relevant to cases where a CDS is going to 546 \nbe modified or built (Options 2 and 3).  547 \nIf an organization  decide s to Buy and Modify or Build a New CDS, engaging with the 548 \nNCDSMO during the system de sign period, b efore development starts, and throughout the 549 \ndevelopment lifecycle  will reduce technical, ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}60{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "59", "chunk": "cost, and schedule risks.  550 \n2.2 CDS Testing (also called Assessment)  551 \nBeyond the normal internal functional and security testing performed by the developer , there are 552 \ntypically  three types of CDS testing  activities conduct ed by external entities : security, integration 553 \nand interoperability , and flight/vehicle safety  testing.  Of the three types of CDS testing, only the 554UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 28 of 397 security assessment of the CDS is performed by the NCDSMO. The three types of CDS testing 555 \nare described below:  556 \n\u2022 Security Assessment:  Testing  of a new CDS and c hanges to a n existing CDS  in 557 \naccordance with the  NCDSM O Lab-Based Security Assessment (LBSA) Process .  The 558 \ntesting is performed in an NCDSMO  certified lab. The LBSA process and requirements 559 \nare described in the NCDSMO document Security Assessment of Cross Domain Solutions 560 \n(CDS): Process and Requirements . For a new CDS, the LBSA process typically costs 561 \nbetween  $1-1.5 million and takes 6-9 months.  562 \n\u2022 Integration and  Interoperability Testing:  Testing t", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}61{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "60", "chunk": "o confirm the interoperability 563 \nbetween the CDS and the system(s) with which it is being integrated . For CDS integrated 564 \nwith weapon or C4ISR systems this is usually performed by the Joint Inter operability 565 \nTest Command (JITC).8 566 \n\u2022 Flight/Vehicle Safety Testing:  Testing of the CDS system to confirm it meets safety 567 \nrequirements may be required . This testing is perfo rmed by the weapon or C4ISR 568 \nsystem\u2019s developer or by some entity designated  by the Program Management Office 569 \n(PMO) for the overarching system.  570 \n2.3 CDS Operations,  Maintenance, & Lifecycle  571 \nRegardless of the decision to buy, buy and modify, or build a CDS,  there are long term costs that 572 \nmust be factored into any decision. These include:  573 \n\u2022 CDS are not a black box . 574 \n\u2022  Agencies cannot  install it and forget about it . 575 \n\u2022 CDS must be patched regularly for the lifetime of the weapon system, sensor, 576 \nplatform, or IT system in which it has been integrated . 577 \n\u2022 All CDS software  and firmware  updates and patches are provided by the CDS 578 \nvendor . 579 \n\u2022 For many weapon systems, implementing a CDS in hardware (e.g., Field 580 \nProgrammable Gate Arrays (FPGA)) can substantially reduce long term lifecyc le 581 \ncosts . 582 \n\u2022 CDS must be actively main", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}62{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "61", "chunk": "tained and enhanced to address new cyber threats , 583 \ncomponent obsolescence , and RTB compliance  until the CDS or the system it is 584 \nembedded in is decommissioned . 585 \n\u2022 Operating systems and CDS components will eventually reach end of life and  586 \n \n8 https://jitc.fhu.disa.milUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 29 of 397 must  be periodically upgraded or replaced to ensure the CDS is supportable . 587 \n\u2022 A CDS must be monitored and defended with an active Defensive Cyberspace 588 \nOperations capability . 589 \n3 CDS Defin itions  590 \nArtifact  \u2013 This is content that has been extracted from other content being filtered. For example, 591 \na JPEG image in a Microsoft Word\u00ae  document would be an artifact once it has been extracted 592 \nby the Microsoft Word\u00ae  filter for additional filtering by t he CDS\u2019s JPEG filter.  593 \nAssured  Pipeline ( AP) \u2013 This is a set of filter processes that are arranged in a linear order using 594 \none-way inter -process communications to transfer  data between process es. The linear flow is 595 \nenforced with mandatory and discretionary access control mechan", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}63{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "62", "chunk": "isms.  596 \nAudit  Data \u2013 Specific enumerated structured events from the operating system kernel, operating 597 \nsystem application, or CDS processes.   598 \nCentral Audit and Loggin g Daemon (CALD)  \u2013 The p rocess responsible for receiving CDS 599 \naudit and log events from CDS components, syntactically and semantically filtering the audit/log 600 \nevents, and dispatching events to the appropriate processes for storage, remote transfer, 601 \nperformance analysis, and system  monitoring and remediation.  602 \nCentral Journal  Daemon (C JD) \u2013 The p rocess responsible for receiving and securely wrapping 603 \nthe content filtered (i.e., journaled data) by the CDS and dispatching it for storage and remote 604 \ntransfer.  This daemon is used to send q uarantined data ( e.g., data that failed filtering) to an 605 \nexternal system for analysis.  606 \nCommunications Interface (CI)  \u2013 This is a physical hardware -based communications device 607 \nattached to the CDS used to support data communication. Typically, C is are Ethern et interfaces, 608 \nOne-Way Transfer interfaces (via Fiber Optic interfaces on Peripheral Component Interconnect 609 \n(PCI) boards), Universal Serial Bus (USB) interfaces, or traditional serial interfaces ( e.g., RS- 610 \n232). For the purposes of this document the ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}64{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "63", "chunk": "followi ng devices are not considered a CI: 611 \nkeyboards, mice, and video cards (for the purposes of display).  612 \nComplex Document Data  \u2013 This is a type of data that cannot  be precisely defined and validated 613 \nvia a ruleset or schema and can contain  one or more embed ded data types . Examples include  614 \nMicrosoft Office\u00ae  (all versions), Portable Document Format (PDF), most images formats ( e.g., 615 \nJPEG, JPEG 2000, NITF), Email, Hypertext Markup Language (HTML), and Container Formats 616 \n(e.g., ZIP, TAR, RAR). Complex Document Data is primarily used for human -to-human or 617 \nmachine -to-human (usually images or PDF)  cross domain transfers . Audio and Video Fil es 618 \nwould be categorized as Complex Document Data.  619 \nCDS Process  \u2013 A software program written or integrated by the CDS developer to perform a 620 \nspecific set of functions for the CDS. Examples include  protocol adapters ( e.g., Secure File 621 \nTransfer Protocol daemon  (SFTPd), Hypertext Transfer Protocol daemon (HTTPd)), filters, a 622 \nFilter Orchestration Engine (FOE), the CALD/CJD, and system or CDS administrative interfaces 623UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, AR", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}65{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "64", "chunk": "E, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 30 of 397 built specifically for the CDS.  CDS processes can be multithreaded. CDS processes do not 624 \ninclude  software programs that are provided by the operating system developer and are required 625 \nfor the operating s ystem to function ( e.g., cron , operating system  kernel, syslogd , systemd ). 626 \nCDS processes do not have to be developed by the CDS developer but they ar e integrated by the 627 \nCDS developer into the CDS ( e.g., an Antivirus  Engine).  628 \nDataflow  \u2013 A dataflow is the combination of a transport protocol, data format(s), direction(s) of 629 \nthe data transfer, source and destination(s) security domains, endpoints providing /receiving the 630 \ndata, and the dataflow filtering policy for a specific CDS customer ( e.g., human user of the CDS, 631 \nmachine -to-machine connections).  632 \nDataflow  Filtering Policy  (aka Filter Policy)  \u2013 A dataflow filtering policy describes the 633 \ntransport protocol, allowed content types, and the content filtering actions required to address the 634 \ndata attack, data hiding and data disclosure9 risks of the content being transferred. It may also 635 \ninclude other restrictions such as file size or allowed security m arkings and rules on how to 636 \ndeterm", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}66{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "65", "chunk": "ine the route (within the CDS) the data must take to reach  the appropriate destination 637 \nsecurity domain(s) based on the filtering rules applied. The dataflow filtering policy also 638 \nimplements the CDS portion of foreign partn er information exchange agreements when a transfer 639 \nCDS is used to transfer data to a foreign partner.  Dataflow Filtering  Policy contains the 640 \nnecessary information to configure the filters for the specific data flow and would include items 641 \nlike:  Extensible  Markup Language ( XML ) schemas, Data Format Description Language  642 \n(DFDL) files, rules for proprietary ruleset languages, dirty and clean words, and filter  specific  643 \nsettings (e.g. , enabling a removal of tracked changes, setting how many level s of embedding i s 644 \nallowed in a document, etc.).  645 \nDataflow  Identifier ( Dataflow  ID) \u2013 A dataflow ID is unique alphanumeric sequence (usually a 646 \nUUID10) that indicates a specific dataflow.  A user (human or machine) of the CDS will be 647 \nassigned one or more  dataflow s using dataflow ID s. 648 \nDiscretionary Access Control (DAC)11 \u2013 An access enforcement mechanism is common on 649 \nmost operating systems. DAC is implemented in the operating system kernel but  use of DAC is 650 \ncontrolled by the user. DAC typic", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}67{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "66", "chunk": "ally includes controlling the read, write, delete, and execute 651 \naccess to files, directories, networking ports, Inter -Process Communications (IPC) mechanisms, 652 \n \n9 Data Hiding and Data Disclosure are sometimes lumped together and called Data Loss Prevention (DLP).  \n10 Universally Unique Identifier (UUID) - https://en.wikipedia.org/wiki/Universally_unique_identifier  \n11 CNSSI 4009 definition:  An access control policy that is enforced over all subjects and objects in an information \nsystem where the policy specifies that a subject that has been granted access to information can do one or more of \nthe following: (i) pass the information to other subjects or objects; (ii) grant its privileges to other subjects; (iii) \nchange security attributes on subjects, objects, information systems, or system components; (iv) choose the security \nattributes to be associated with newly -created  or revised objects; or (v) change the rules governing access control. \nMandatory access controls restrict this capability.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 31 of 397 shared memory, processes and in some cases", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}68{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "67", "chunk": "  devices based on owner, group, and others12. DAC 653 \ncan be used to implement limited  process isolation and flow control.  File system Access Control 654 \nLists (ACL) are  considered part of the operation system  DAC  implementation . 655 \nDomain Router (DR)  \u2013 The CDS filter process responsible for the transfer of data between 656 \nassured pipelines/ FOEs  operating a t different security levels within the CDS. It is sometimes 657 \nreferred to as the Trusted Executive/Subject or Regrader.  The DR takes filtered data from the 658 \noutbound pipeline and sends it to the inbound pipeline.  659 \nEvent Manager & Policy Enforcer (EM/PE)  \u2013 This set of daemons processes Audit/Log and 660 \nother system data sources and enforces system security and management policy. The EM/PE  661 \nenforce least privilege by moving system security enforcement actions from Protocol Adapter 662 \n(PA), FOE, and Filter process es to a subsystem that does not process external data.  663 \nFilter  \u2013 This is a process  or a set of processes , that applies a filter policy to content. Filters 664 \nnormally implement the concept of least privilege and generally only work on a specific data 665 \ntype13 (e.g., a Microsoft Office\u00ae  filter would process Microsoft Office\u00ae  files but not images or 666 \nPortable Docum", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}69{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "68", "chunk": "ent Format (PDFs ) files). Filters can operate on a Pass/Fail model or Pass with 667 \nChange model. The Pass with Change model is the preferred model for imp lementing filters. 668 \nFilters may generate digitally signed filter reports in some CDS implementation models. Some 669 \nfilters consist of a filter controller that spawns individual filters to process the content.  670 \nFilter Orchestration Engine (FOE)  \u2013 This is a set of processes that are used to coordinate the 671 \nfiltering of the content being transferred through the CDS. The FOE processes determine which 672 \ndataflow  filtering policy will be used, sends the content to the filter(s) to be processe d, notifies  673 \nthe filter(s) which dataflow filtering policy to use,  retrieves the conte nt and artifacts from the 674 \nfilters, determines if additional filtering is required and validates that the filtering performed is 675 \nwhat was required and that it passed. Failed content i s either deleted immediately or quarantined 676 \nvia the CJD. The Job Scheduler and Result Processor processes are part of the FOE.  677 \nFilter Policy  \u2013 See Dataflow Filtering Policy.  678 \nFilter Policy ID  \u2013 A filter policy ID is unique alphanumeric sequence (usually a U UID)  that 679 \nidentifies a specific  filter policy on the CDS  (o", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}70{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "69", "chunk": "r grouping of CDS) .  Filter policy IDs are 680 \nassigned by the CDS when the filter policy is created , are unique , and are never reused in order 681 \nto maintain integrity of the audit record .  682 \nFilter Report Validator (FRV)  \u2013 This process independently validates filter reports from the 683 \nfilters and Results Processor and verifies the dataflow content was filtered according to the 684 \ndataflow filtering policy, that the content passed (or passed with change), verifies the integrity of 685 \nthe reports and the filter(s) and Results Processor signatures, and that the Secure Hash Algorithm 686 \n(SHA) hash of the content matches that in the report. The FRV is usually the last process in the 687 \n \n12 https://www.linux.com/learn/understanding -linux -file-permissions  \n13 There are some filters like Anti -Virus that work on multiple data types.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 32 of 397 filter pipeline before the Domain Router.  In some CDS design patterns , there is also a FRV  after 688 \nthe Domain Router.  689 \nFixed Format Data  \u2013 This is a type of data that can be precisely defined", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}71{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "70", "chunk": " and validated via a 690 \nruleset or schema . Examples include:  XML, JavaScript  Object Notation  (JSON) , Key-Length - 691 \nValue (KLV), United States Message Text Format (USMTF ), Tactical Digital Information Link  692 \n(TADIL ) J, and Variable Message Format (VMF). Fixed format data can be textual or binary.  693 \nFixed format data is primar ily used for machine -to-machine messaging and is generally designed 694 \nto be efficiently processed by software.  Fixed format data does not contain embedded data types.  695 \nAll fields must be fully inspectable  and constrainable via a ruleset or schema.  In some cases, data 696 \ntypes might be considered fixed f ormat in some use cases and not  in others ( e.g., XML as a 697 \nrepresentation of VMF would be fixed format but XML -based Microsoft Office\u00ae  files would 698 \nnot). 699 \nHardware Content Filtering Deice (HCFD)  \u2013 An HCFD is a hardware -based devic e that 700 \nimplements hardware -based separation, unidirectional flow enforcement, protocol 701 \nreconstruction, and the protocol filtering of a Protocol Filtering Diode while also syntactically 702 \nand semantically filtering the content being transferred.  703 \nHigh Threat N etwork (HTN)  \u2013 A HTN  is defined as a network in which a known or suspected 704 \nhighly skilled ( e.g., ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}72{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "71", "chunk": "nation -state or transnational organized crime level) cyber actor is operating. 705 \nThe cyber actor may be operating on the network without the knowledge of the pri mary user of 706 \nthe network. HTNs are also networks for which the cyber hygiene is known to be insufficient, 707 \nthe entities on the network are known not to have robust and effective Defensive Cyber space  708 \nOperations capabilities, and the lack of ownership of the network or ability to influence the 709 \nsecurity posture of it. An organization\u2019s Authorizing Official in consultation with  710 \nUSCYBERCOM and  the USG Intelligence Community will determine if a network is to be 711 \nconsidered high threat. Unclassified networks connect ed to the Internet are considered high 712 \nthreat . If a CDS is connecting to a foreign partner\u2019s secret network and it is known that the 713 \nforeign partner\u2019s  network is connected to the Internet with just firewalls (i.e., thus a direct 714 \nconnection), then that foreign partner\u2019s secret network is an HTN.   715 \nInbound Pipeline  \u2013 This is the secon d half of an assured pipeline and is located between the 716 \nDomain Router and the  destination  domain\u2019s  PA. Its purpose is detecting failures in the 717 \noutbound pipeline  and Domain Router  by filtering the content with red", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}73{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "72", "chunk": "undant and independent 718 \nfilters . It is the last check in verifying that the destination  domain  is only receiving  content and 719 \nmetadata that are appropriate for that  domain.  The term \u201cinbound\u201d is relative to the domain n ot 720 \nthe CDS , so the inbound pipeline is sending data to the destination domain.  721 \nInter -Process Communications  (IPC)14 \u2013 This is an operating system mechanism that allows 722 \nprocesses to communicate. Mechanisms include (but are not limited to): Transmission Control 723 \nProtocol (TCP) sockets, User Datagram Protocol (UDP) sockets, UNIX\u00ae  Domain Sockets, 724 \n \n14 http://man7.org/conf/lca2013/IPC_Overview -LCA -2013 -printable.pdfUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 33 of 397 System V/Portable Operating  System Interface for UNIX\u00ae  (POSIX\u00ae ) message queues, named 725 \npipes (also called a UNIX\u00ae  FIFO), System V/ POSIX\u00ae  shared memory, signals, System 726 \nV/POSIX\u00ae  semaphores, and pipes . On Linux \u00ae, the use of POSIX\u00ae  IPC is generally 727 \nrecommended over System V IPC15. A file system can implement IPC -like functionality if 728 \nsufficient MAC and DAC p", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}74{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "73", "chunk": "ermissions are used. The use of one -way IPCs is preferred to limit 729 \nthe ability of an adversary to exfiltrate filter software and configuration off the CDS if a process 730 \n(e.g., filter) is compromised.  731 \nJob Schedule r/Results Processor  \u2013 Two processes used in combination to implement the core 732 \nof a Recursive Decomposition Engine -based FOE (See Section 6.5: Design Patterns).  733 \n\u2022 The Job Scheduler  (JS) sends dataflow content and supporting metada ta (e.g., which 734 \ndataflow filtering policy to use) to filters for processing. Job Schedulers usually provide a 735 \nmechanism to map from a dataflow ID (from the PA) to the applicable dataflow filtering 736 \npolicy.   737 \n\u2022 The Results Process or (RP)  receives filtered cont ent, filtered artifacts, unfiltered 738 \nartifacts, and filter reports from filters; combines individual filter reports for a given 739 \ntransaction into a single report and digitally signs it, and validates filter reports for 740 \ncorrectness. The RP then sends the unfi ltered and filtered artifacts to the job scheduler for 741 \nprocessing, sends the successfully completed  filtered content to the next stage in the filter 742 \npipeline (usually the Filter Report Validator) and either drops failed/errored content or 743 \nsends it to the C J", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}75{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "74", "chunk": "D. 744 \nJournaled  Data  \u2013 This is data that has been sent to the CDS. Journaled data includes data that 745 \nhas not yet been filtered  (e.g., queued waiting for filtering) , data that has successfully completed 746 \nfiltering,  data that is in the filtering pipeline and thus still being filtered, or  data that failed in 747 \nfiltering  (i.e., quarantined data) . Only data that has successfully completed filtering should be 748 \ntreated as safe, all other d ata should always be considered malicious.  749 \nLog Data  \u2013 Unstructured or loosely structured data (e.g., syslog  messages) from operating 750 \nsystem or CDS processes.  751 \nMandatory Access Control (MAC)16 \u2013 An access enforcement mechanism found on \u201ctrusted 752 \noperating systems\u201d. Common implementations include Security -Enhanced Linux (SELinux) or 753 \n \n15 POSIX\u00ae is newer, simpler, faster, and generally easier to use. They are also thread safe and support use of sele ct() \nand poll().  \n16 CNSSI 4009 definition:  An access control policy that is uniformly enforced across all subjects and objects within \nthe boundary of an information system. A subject that has been granted access to information is constrained from \ndoing any  of the following: (i) passing the information to unauthorized subjects or objects; (ii) granti", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}76{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "75", "chunk": "ng its privileges \nto other subjects; (iii) changing one or more security attributes on subjects, objects, the information system, or \nsystem components; (iv) choo sing the security attributes to be associated with newly created or modified objects; or \n(v) changing the rules governing access control. Organization -defined subjects may explicitly be granted \norganization -defined privileges (i.e., they are trusted subjec ts) such that they are not limited by some or all of the \nabove constraints .UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 34 of 397 PitBull\u00ae in Linux\u00ae and Trusted Extensions in Solaris\u00ae .  MAC is implemented in and enforced 754 \nby the operating system kernel and is not changeable by the user. MAC can be used to 755 \nimplement robust process isolation and flow control . 756 \nOne-Way Transfer (OWT)  \u2013 A mechanism, (e.g., optical diode, Field Programmable Gate Array 757 \n(FPGA) based diode, electro -optical tap) , which enforces a unidirectional data flow with varying 758 \ndegrees of assurance, typically referred to as a \u201cdiode\u201d however not exclusively implemented as 759 \nsuch.  A common ex", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}77{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "76", "chunk": "ample is a fiber  optic isolator.  A diode is NOT a CDS  itself,  but it is a 760 \ncomponent of a CDS . 761 \nOutbound  Pipeline  \u2013 This is the first  half of an assured pipeline and is located between the 762 \noriginating domain\u2019s PA and the Domain Router . It is the primary filtering pipeline and is 763 \nresponsible for addressing via filtering the data hiding, data at tack, and data disclosure problems 764 \nwith the content.  The term \u201coutbound\u201d is rel ative to the domain not the CDS so the outbound 765 \npipeline is receiving data from the  source  domain.  766 \nPitcher /Diode /Catcher  (PDC)  \u2013 A design pattern  concept  that utilizes a OWT  mechanism  to 767 \nprovide guaranteed domain separation and a protocol break in combination with pitcher and catcher 768 \ndevices that provide the content filtering functionality to address data -based threats (e.g., delivery of 769 \nmalware, exfiltrat ion of data and malware command and control (C2) ). The pitcher  device receives 770 \ndata from the origin domain, filters it, and sends it over the OWT to the catcher  device which 771 \nreceives the data, filters it and sends it to the destination domain.  This concept  is the basis for the 772 \none-way transfer CDS design patterns in Section 0. In the Simple Diode Solution (SDS) variant of", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}78{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "77", "chunk": " a 773 \nPDC the content is not filtered.  774 \n 775 \nFigur e 1 \u2013 Pitcher/Diode/Catcher  (PDC)  Architecture  776 \nProtocol Adapter (PA)  \u2013 These CDS  process es communicate with entities external to the CDS. 777 \nProtocol Adapters are the only CDS processes that are part of the dataflow that can interact with 778 \nthe Communication Interfaces.  Protocol Adapters typically implement Open Systems 779 \nInterconnection  (OSI)  model17 layers 5 -7. 780 \nProtocol Filter ing Diode (PFD)  \u2013 This is OWT device that implements a protocol break and 781 \nreconstruction for  OSI Layers 1 -4 (e.g., Ethernet to UDP).  782 \nSecurity Domain  \u2013   A network operating at a unique combination of Classification, 783 \nReleasabilities, and Dissemination Controls (including Special Compartmented Information 784 \n(SCI), Alternative Compensatory Control Measures (ACCM ), and Special Access Program 785 \n \n17 https://en.wikipedia.org/wiki/OSI_modelUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 35 of 397 (SAP)). Networks with  different releasabilities ( e.g., Trigraphs, Tetragraphs, SCI compartments) 786 \nare considered different secur", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}79{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "78", "chunk": "ity domains.  Security Domain examples include Joint Worldwide 787 \nIntelligence Communication System ( JWICS ), Non-Secure Internet Protocol Router Network 788 \n(NIPRNet ), Secure Internet Protocol Router Network ( SIPRNet ), Combined Enterprise Regional 789 \nInformation Exchange System  (CENTRIXS ) \u2013 International Security Assistance Force  (ISAF ), 790 \nand CENTRIXS -Japan.  In the CDS community, a security domain is sometimes ca lled a \u201cdata 791 \ndomain\u201d or \u201cuser domain\u201d.  792 \nSimple Diode Solution (SDS)  \u2013 An implementation of the PDC design pattern except that the 793 \npitcher and catcher are not filtering data and do not meet the RTB security requirements. An 794 \nSDS is not a CDS  but is part of a CDS  architecture . The pitcher terminates the inbound protocols 795 \n(e.g., https, sftp, etc.) , extracts the payload data, packetiz es it, and then sends the  packetized  data 796 \nover the diode . The catcher then receives the data from the diode and d elivers it to the destination 797 \n\u2013 usually either a software CDS (for low -to-high) or the destination system (for high-to-low). 798 \nStreaming Data  \u2013 This is a type of data that can be precisely defined and validated via a ruleset 799 \nor schema but is delivered to the  CDS as a stream of messages ( e.g., packets) usually ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}80{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "79", "chunk": "as part of a 800 \npersistent session without a pre-defined end. The messages may have IDs but do not have file 801 \nnames. Examples of streaming data including Full Motion Video  (FMV) , Voice -over-IP (VOIP) , 802 \nVideo Tele-Conference  (VTC) , XML  or JSON Web Services, and Modeling and Simulation 803 \nData ( e.g., DIS, HLA, TENA) . 804 \nSubsystem  \u2013A subsystem is a grouping of components that are installed together, depend on 805 \neach other to operate, and perform a specific function.  A subsystem can consist of multiple 806 \nprocesses. Examples of subsystems include:  a PA, a filter, the central  audit and  logging daemon, 807 \nand the event manager/policy enforcer.  808 \nQuarantine d Data  \u2013 This is data that has failed content filtering. It should always  be considered 809 \nmalicious.   810 \n4 CDS Classes  811 \nCDS are comprised of hardware and software components that work together t o meet a specific 812 \nmission\u2019s operational and security needs. CDS  are either acquired through commercial markets  813 \n(also known as COTS  products ) or developed by the USG (also known as GOTS products). This 814 \ndocument applies to both COTS and GOTS CDS used by the USG to protect NSS.  There are two 815 \nfunctional classes  of CDS:  816 \n\u2022 Transfer CDS18 are used to move data betwee", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}81{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "80", "chunk": "n two or more security domains (usually  817 \nnetworks) operating at different security levels  and/or releasability and handling caveats.  818 \nTransfer CDS do not give users access into a different security domain; they simply 819 \n \n18 CNSSI 4009 definition:  A type of CDS  that facilitates the movement of data between information systems \noperating in different security domains .UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 36 of 397 enable the movement  of data between domains. There is a special case of a Transfer CDS 820 \ncalled a Multi -Level Security (MLS) CDS19.  821 \no An MLS CDS can store data at multiple security levels; however, when it 822 \nregrades20 or allows a user a t one level to query and retrieve data at a nother level  823 \nthen it becomes a transfer CDS.  It is extremely rare for an MLS CDS to onl y 824 \nallow a user to query and retrieve data at a single level  \u2013 they usually allow query 825 \ndown which is a transfer function.  An example of an MLS CDS that support s 826 \nquerying  and the ability to regrade/relabel, read -up, read -down, write -up, or write - 827 \ndown  is an MLS ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}82{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "81", "chunk": "Database (see Section 17). 828 \no If an MLS CDS does not allow regrading/relabelin g, read -up, read -down, write - 829 \nup, or write -down then it is a called a Multi -Level File Repository .  A Multi -Level  830 \nSwitch (see Section 18) functions similar to a ML  File Repository except  that it 831 \nmarshals access to different systems operating at differe nt levels while a ML File 832 \nRepository marshals access to different file system s/directories at different levels.  833 \n\u2022 Access CDS21 (ACDS)  are used to provide access  from  one (typically higher) security 834 \ndomain to one or more (typically lower) security domains . User data is never transferred 835 \nin its native format between domains using an Ac cess CDS \u2013 only a visual representation 836 \nis transferred  and usually as images or video . There are two variants of Access CDS:  837 \no Desktop  (DACDS)  838 \n\u25aa In the desktop variant, the user can access data in multiple domains from a 839 \nsingle desktop environment .  There are two widely used approaches for a 840 \nDesktop Access CDS: Virtual Machine (VM) based and Remote Virtual 841 \nDesktop Infrastructure  (VDI) . Both types o f Desktop Access CDS are a 842 \ntransfer  CDS  as data  (usually keyboard, mouse, and video) is moved 843 \nbetween domains. However, the ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}83{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "82", "chunk": "core purpose of the device is to provide 844 \naccess to information in another domain  not to transfer data . The typical 845 \ndata being transf erred is restricted to keyboard, mouse, video, audio,  and 846 \nsmartcard redirection.  Remote VDI Access CDS are generally used in 847 \nEnterprise environments.  VM Access CDS are generally used in Tactical 848 \n \n19 CNSSI 4009 definition:  A type of CDS  that uses trusted labeling to store data at different classifications and \nallows users to access the data ba sed upon their security domain and credentials.  The recategorization of MLS CDS \nunder transfer CDS is intentional. Historically MLS CDS has been considered a separate class of CDS. \nUnfortunately, this had led to insecure and unsafe design and implementatio n practices because the transfer CDS \nfunction of filtering of data during a regrade was not implemented. Because all known MLS CDS support data \nregrading, this document re -categorizes MLS CDS a subtype of transfer CDS. There are very few MLS CDS in \nactual use. \n20 Regrading is the process of changing the security label for content (e.g., files, database records). Examples include \ndowngrading a file from SECRET to UNCLASSIFIED or upgrading a file from SECRET to TOP SECRET (so for \nexample it would be available to a TS ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}84{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "83", "chunk": "user so that TS data could be added to the document).  \n21 The CNSSI 4009 definition  for Access CDS is :  A type of CDS  that provides access to a computing platform, \napplication, or data residing on different security domains from a single device.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 37 of 397 environments.  849 \no Server  (SACDS)  850 \n\u25aa In the server variant, groups of  VMs for each security domain are 851 \noperating on the Access CDS.  Each group of VMs is called a tenant.  852 \nAccess to a tenant\u2019s VM s must only be  from clients operating in the same 853 \nsecurity domain as the tenant . While this is similar in concept to an MLS 854 \nCDS, the Access CDS Server variant has no explicit knowledge of 855 \nsecurity levels. It essentially implements a multi -tenant architecture in 856 \nsuch a way that the data and VMs associated with a specific tenant are 857 \nonly accessible by clients  in the same security domain as the tenant . 858 \nClients can only interact with a single tenant. There is no data transfer 859 \nbetween tenants except via  a separate  approved Transfer CDS.  860 \nThis document a", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}85{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "84", "chunk": "pplies to all classes  and all variant s of CDS .  In addition, it applies to both 861 \nData center  and Tactical environment implementations, as described in the following sections . 862 \nBoth  Datacenter -class and Tactical -class CDS are used in point -to-point installations . 863 \n4.1 Datacenter -class  Transfer CDS  (DCCDS ) 864 \nDatacenter -class  Transfer CDS are generally implemented  in a fixed facility , without substantial 865 \nconstraints regarding SwaPC.  Commercial cloud service providers would be using datacenter - 866 \nclass CDS.  These CDS can support varied missions for multiple organizations  and frequently 867 \noperate  in facilities acting as an information or decision hub for C4ISR  operations.  Datac enter - 868 \nclass Transfer CDS typically operate on industry standard servers that are installed  in industry 869 \nstandard racks ( e.g., 19\u201d wide). These servers usually contain large numbers (12-64) of CPU  870 \ncores  (e.g., AMD\u00ae  Epyc \u00ae/Intel Xeon \u00ae), 1-4 CPU sockets , hundreds of  gigabytes of RAM, and 871 \nterabytes of local storage.  Datacenter -class Transfer CDS generally are  designed to meet 872 \noperational  requirements for  high availability  and fault tolerance , load balancing, high traffic 873 \nload, and support for large numbers of concurrent", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}86{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "85", "chunk": " users  (e.g., dataflows) . 874 \nThe DCCDS  category suppor ts three  broad types of transfer CDS : 875 \n\u2022 Fixed Format Dataf lows  (DCCDS -FF): CDS that typically  support dataflow s required 876 \nfor the secure, safe, and proper operation of sensors and weapon systems (e.g., processing 877 \na radar track and launc hing a missile to intercept it) or other systems requiring the cross 878 \ndomain transfer of fixed format and highly structured data ( e.g., logistics systems, 879 \nequipment maintenance support systems) . Typically , these flows use small, fixed  format 880 \nmessages , have low tolerance for latency (e.g., 100ms or less) and low -to-moderate 881 \nthroughput (e.g., 100s of VMF or TADIL -J messages/second) requirements. These 882 \ndataflows are typically considered mission critical systems.  883 \n\u2022 Streaming  Dataflows ( DCCDS -SD): CDS that  typically  support dataflows necessary for 884 \nC4ISR operations but are not directly related in the actual engagement with a target or 885 \ncontro lling a sensor or weapon system , these flows include streaming data types like 886 \nXML/JSON Web Services ( e.g., SOAP or REST), streaming Unmanned Aerial Vehicle 887UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIF", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}87{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "86", "chunk": "IED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 38 of 397 (UAV)  video, satellite/UAV ima ges, Video Teleconference (VTC) , and Voice Over 888 \nInternet Protocol (VOIP) .  These dataflows have low tolerance for latency (e.g., 100ms or 889 \nless) and moderate -to-high throughput (e.g., 1000s of XML messages/second, 6 mb/s 890 \nvideo streams)  requirements . These dataflows are typically considered mission critical 891 \nsystems . 892 \n\u2022 Complex Dataflow s (DCCDS -CD): CDS that support dataflow s necessary  for C4ISR 893 \noperations but are not directly related in the actual engagement with a target ( e.g., 894 \ndeveloping a  target list, drafting an air tasking order)  or controlling a sensor or weapon 895 \nsystem . Typically , these flows include data types like Microsoft Office\u00ae  files, PDF  files, 896 \nimages , email , and may include some  fixed format data flows . These dataflows have 897 \nmoderate -to-high tolerance for latency  (e.g., > 100ms)  and moderate throughput (e.g., 898 \n1000s of files per hour) requirements . These data flows are typically considered mission 899 \nessential.  Software transfer is a type of Complex Dataflow . 900 \n4.2 Tactical -class  Transfer CDS  (TCDS)  901 \nTactical -class Transfer  CDS are ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}88{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "87", "chunk": "designed for use in environmentally constrained  condition s (e.g., 902 \nsand, heat, humidity, shock , and vib ration ) and in most cases are used  mainly  for fixed format 903 \ndata flows or streaming video/images ( e.g., from an unmanned aerial vehicle (UAV) ). These 904 \nCDS typically have a low tolerance for latency and may have to operate in disconnected 905 \ncommunications environments.  906 \nTactical -class  Transfer  CDS generally operate in highly SwaPC-constrained environments and  907 \nare typically attached to or reside within  a weapon system ( e.g., aircraft, tank, plane, or missile 908 \nbattery) or sensor ( e.g., a data processing shelter in the back of a vehicle attached to radar  or 909 \nmobile/deployable command and c ontrol (C2) node ). Tactical -class Transfer CDS typically 910 \noperate on customized  motherboards within ruggedized  cases that meet military specifications.  911 \nThese servers usually contain 2-8 CPU cores (e.g., ARM \u00ae), 1-2 CPU socket s, 2-32GB of RAM , 912 \nand little storage ( e.g., a few GB of memory that is frequently batter y backed) . They a re 913 \nfrequently paired with FPGAs to perform specialized filtering and enforce unidirectional data 914 \nflow. 915 \n5 CDS Implementation Models  916 \nThere are four basic models  for implementing  ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}89{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "88", "chunk": "a CDS:  917 \n1) Traditional Software Based (TSB)  \u2013 CDS implemented in s oftware , operating on 918 \ntrusted operating system (OS) (e.g., Solaris\u00ae  11 with Trusted Extensions , Red Hat\u00ae  919 \nEnterprise Linux\u00ae  with SELinux enabled , General Dynamics PitBull\u00ae Trusted 920 \nOperating Sy stem, BAE  Systems  STO P\u2122 Operating System ). These types of CDS could 921 \nbe GOTS or COTS.  922 \n2) Hardware Based (HB)  \u2013 CDS implemented entirely in hardware  are usually  923UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 39 of 397 implemented in  a FPGA22. These types of CDS could be GOTS or COTS.  Hardware 924 \nmechanism may include anti -tamper protections.  925 \n3) Traditional Software Based with Hardware Assist  (THA)  \u2013 CDS that are primarily 926 \nimplemented in software but leverage  hardware for certain filtering, domain separation, 927 \nand/or device protection23 functions.  These types of CDS could be GOTS or COTS.  928 \n4) Composed COTS CDS  (CCOTS ) \u2013 CDS that are i mplemented using  entirely  929 \ncommercially available components  that are exportable worldwide  in accordance with 930 \nDoD  Supply Chain Risk ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}90{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "89", "chunk": "Manag ement (SCRM) directives . Compos ed COTS CDS use 931 \none or more one-way control mechanisms enforced by hardware  (e.g., an optical diode)  932 \nto provide the domain separation  and software (along with supporting hardware) to 933 \nimplement filters . A Composed COTS CDS is not typically  implemented using a 934 \ntraditional trusted OS.  Use of this model is no longer acceptable for USG CDS.  935 \nIt is important to consider these implementation models when implementing requirements.  As 936 \nsuch, they are applied to the requirements defined in Section s 9 and 10 accordingly.   937 \n  938 \n \n22 The complete design and programming requirements for the Field Programmable Gate Array (FPGA) components \nof hardware based or traditional CDS with hardware assist are out -of-scope for this version of the document.  \n23 Hardware based device protection can incl ude anti -tamper mechanisms, diodes for domain separation, and \ntechnologies like Trusted Platform Module (TPM) based Trusted Boot.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 40 of 397 6 Risk s & Threat s 939 \nThis section introduces the ongoing a", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}91{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "90", "chunk": "ctivities focused on aligning RTB with known threats and 940 \nweaknesses found in publicly available knowledge bases. It also defines the risk assumptions and 941 \nthreats that are, in part, the basis for the requirements described in this document. The 942 \nassumptions, as defined below, either reduce or increase the risk based on the operational 943 \nenvironment and cyber environment. An overview of content a nd protocol -based risks is also 944 \nprovided, along with examples of content/protocol -based attacks, which are essential to 945 \nunderstanding the requirements defined in RTB.  946 \n6.1 Threat and Weakness (T&W) Mapping  947 \nThis edition of the RTB requirements has started the pr ocess of formally mapping RTB 948 \nrequirements against the MITRE ATT&CK\u00ae24, MITRE Common Weakness Enumeration \u2122 949 \n(CWE)25, MITRE C ommon Attack Pattern Enumeration and Classification \u2122 (CAPEC)26 950 \nadversary tactics and techniques, software and hardware weaknesses, and known attack patterns 951 \nto assist developers and assessors in conceptually  understanding what threats the requirements 952 \naddress.   953 \nMITRE ATT&CK, CWE and CAPEC (AC&C) come from tactics, t echniques, and procedures 954 \n(TTP) that have been seen \u201cin the wild \u201d and focus on general software and hardware security ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}92{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "91", "chunk": "955 \nuse-cases . RTB, on the other hand, is targeted to the specific problem domain of CDS and is not 956 \nlimited to what has been seen in the wild.  Since it applies to a more constrained problem domain, 957 \nRTB can be more specific or strict than AC&C. For instance, the OSSR -4.5 requirement fits very 958 \nwell with the ideas in \u201cCWE -284: Improper Access Control \u201d but is able to be more specific than 959 \nthe CWE by  stating the types of access that should be restricted in the CDS problem domain. In 960 \nother instances, RTB specifies domain -specific threats and weaknesses that may not make sense 961 \nto capture in AC&C because they are so specific to CDS.  962 \nThere are some other categories of requirements that do not map well to CWE and CAPEC:  963 \n\u2022 Requirements that are  not mapped because they have been deemed mandatory guidance, 964 \nbest practice, or allowances.  965 \n\u2022 Parent requirements that are best understood not by being mapped but by looki ng at the 966 \nAC&C of their child requirements.  967 \n\u2022 Requirements that step outside the scope of CWE and CAPEC. For instance, the Security 968 \nDevelopment Lifecycle (SDL)  mentioned in DPMR -3 places organizational requirements 969 \non developers. CWE and CAPEC do not discuss  how developer organizations are 970 \n \n2", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}93{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "92", "chunk": "4 https://attack.mitre.org  \n25 https://cwe.mitre.org  \n26 https://capec.mitre.orgUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 41 of 397 structured and run. ATT&CK \u2019s mitigations come close by mentioning developer training 971 \nbut some of this is out of scope even for ATT&CK.  972 \nAlternative implementations of RTB requirements may be permitted if they address the iss ues 973 \ndiscussed in the ATT&CK, CWE and CAPEC mappings. CDS Developers that want to use an 974 \nalternative approach to address a requirement must contact the NCDSMO prior to development 975 \nto ensure that the implementation addresses the threats and meets the require ments.  976 \nThese mappings are evolving and future versions of RTB will have additional mappings. 977 \nSubmission of mapping suggestions and corrections to the NCDSMO is encouraged . 978 \nSections Appendix F \u2013 RTB Specific Threats  (TRTB) and Appendix G \u2013 RTB Specific 979 \nWeakness es (WRTB) were developed to describe threats and weaknesses which do not map to 980 \nan existing CWE  or CAPEC entries. They will be submitted for inclusion into those repositories 981 \nin the ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}94{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "93", "chunk": "future.  982 \n6.2 Operational Environment  Risk Assumptions  983 \nThis section provides some o f the operational environment risk assumption s for DCCDS and 984 \nTCDS  classes of CDS.  The assumptions in this section either reduce or increase the risk to the 985 \nCDS based on the operational environment.  986 \n6.2.1  DCCDS  987 \n\u2022 This class of CDS operates in  environments where temperature, vibration s, shock, 988 \nhumidity,  and air quality can be controlled . 989 \n\u2022 This class of CDS operates in environments where the temporary or permanent loss of 990 \npositive control of the CDS is unlikely.  991 \n\u2022 This class of CDS is installed in industry standard 19 -inch racks with  high quality  reliable  992 \n(often redundant)  power.  993 \n\u2022 This class of CDS has stable access to the networks on which the CDS will be 994 \ntransferring data .  995 \n6.2.2  TCDS  996 \n\u2022 This class of CDS operates in environments27 where temperature, humidi ty, air quality , 997 \nshock,  and vibrations are either minimally controlled or uncontrolled.  998 \n\u2022 This class of CDS operates in a variety of environments where controlling physical 999 \naccess to the system cannot be guaranteed.  1000  \n\u2022 This class of CDS operates in environments  where the possibility of temporary or 1001  \npermanent loss of p", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}95{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "94", "chunk": "ositive control of the CDS is substantial.  1002  \n \n27 Examples include tanks or similar land vehicles , unmanned vehicles (air, water, land), river boats or similar small \nwatercraft, planes, man -portable, and forward operating bases/locations.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 42 of 397 \u2022 This class of CDS  is installed in a variety of system enclosures from standard 19 -inch 1003  \nracks to custom configuration s inside of a weapon system or mobile/transportable C2 1004  \nnode, with potentially unreliable power sources.  1005  \n\u2022 This class of CDS may have unstable network access or no network access at all to 1006  \nsystems outside of the weapon system or sensor.  1007  \n6.3 Cyber Environment Risk Assumptions  1008  \n(U//FOUO)  This document takes a somewhat different approach than previous attempts to 1009  \ndevelop security requirements for CDS \u2013 it assumes an extremely hostile cyber environment. 1010  \nSpecifically, this document assumes the foll owing risks: 1011  \n\u2022 (U//FOUO)  All CDS, at some point in their lifecycle and various deployments, will be 1012  \nconnected to high threat (e", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}96{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "95", "chunk": "ssentially unbounded threats) networks like the Internet (if not 1013  \ndirectly then cascaded from another interconnected system  like NIP Rnet ). 1014  \n\u2022 (U//FOUO)  The developers of the CDS are not always privy to the true operational 1015  \nenvironment(s) in which the CDS will operate.  1016  \n\u2022 (U//FOUO)  One or more of the networks to which the CDS will be connected will , at 1017  \nsome point, have nation -state level actor(s) with advanced Computer Network Attack 1018  \n(CNA) and Computer Network Exploitation (CNE) capabilities  operating . 1019  \n\u2022 (U//FOUO)  The CNA/CNE capabilities of adversaries are growing at an increasingly 1020  \nrapid rate year after year and the cost of entry is lower each  year.  1021  \n\u2022 (U//FOUO)  All networks have complex insider threats.  1022  \n6.4 General Threats  1023  \nThis section identifies some of the general threats  to the CDS, including those from the 1024  \nenvironment where the CDS is deployed, malicious insiders, and connected networks.  1025  \n6.4.1  Unautho rized Facility Access  1026  \n\u2022 Unauthorized personnel with unconstrained physical access to the CDS allows execution 1027  \nof physical attacks against the CDS to exfiltrate software/data , implant the system with a 1028  \nmalicious software or hardware components, cause ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}97{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "96", "chunk": "system degradation , or cause a  denial 1029  \nof service (DoS).  1030  \n6.4.2  Malicious Insider (User)  1031  \n\u2022 (High -side user) Attempts to exfiltrate classified or sensitive data to the Low-side by 1032  \nmanipulati ng data sent to the CDS.  1033  \n\u2022 (Low -side user) Attempts to cause a DoS or undermine the integrity or availability of the 1034  \ndata on the High-side by manipulating data sent through the CDS.  1035  \n\u2022 For Access CDS, compromise of and privilege escalation withi n a VM could le ad to 1036  \ncompromise of the Hypervisor.  1037UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 43 of 397 6.4.3  Malicious Insider (Admin)  1038  \n\u2022 Unauthorized reconfiguration of the CDS dataflow policy to allow unapproved access to 1039  \nthe CDS; allow unapproved data types through the CDS; or alter the dataflow policy to 1040  \nallow data attack, data  exfiltration, and malware C2 through the CDS.  1041  \n\u2022 Addition of other network devices to provide alternative flows ( e.g., email, complex 1042  \ndocument file transfer, web browsing) that bypass the CDS.  1043  \n6.4.4  Non-Malicious Insider ( Users & Adm", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}98{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "97", "chunk": "in)  1044  \n\u2022 Admins can uni ntentionally misconfigure a CDS.  1045  \n\u2022 Users can unintentionally misuse a CDS . 1046  \n6.4.5  Attacks from Low-side Network(s)  1047  \n\u2022 Use of the Low-side network to attack the CDS and supporting systems to disrupt the 1048  \noperations of the CDS.  1049  \n\u2022 Use of the Low-side network to send malicious content to the CDS to disrupt the 1050  \noperations of the CDS or other connected networks.  1051  \n6.4.6  Attacks from Compromised High -side Network  1052  \n\u2022 Failure to patch the High-side systems leaving them susceptible to known vulnerabilities.  1053  \n\u2022 Use of removable media to transfer data between Low and High system which could 1054  \nintroduce malicious content to the High-side system that could pose a threat to the CDS.  1055  \n6.4.7  Supply Chain Com promise   1056  \nThis risk is inclusive of CDS  and systems on the High -Side and  Low-side networks . 1057  \n\u2022 Introduction of counterfeit/modified hardware/software/firmware that can be used to 1058  \ncause DoS , data corruption /misinformation, or  data exfiltration.  1059  \n\u2022 Loss of data about th e systems (architecture, build, documentation , etc. ) which provide s 1060  \ninformation necessary to cause disruption, DoS, or data exfiltration.  1061  \n\u2022 (U//FOUO)  Adversaries will su", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}99{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "98", "chunk": "ccessfully attack and manipulate the CDS component 1062  \nsupply chain.  1063  \n6.4.8  Insufficient  Human Review  1064  \n\u2022 Insufficiently or incorrectly marked content  could result in the  accidental release of 1065  \nsensitive information.  1066  \n\u2022 Insufficiently trained RHR Reviewer does not know how to inspect document s for data 1067  \nhiding and data disclosure problems (see Sections 6.5.2  and 6.5.3 ). 1068  \n\u2022 RHR Review ers lack sufficient knowledge of the subject matter for the content  they are 1069  \nreviewing to determine if it is correctly labeled  and thus releasable . 1070UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 44 of 397 \u2022 Insufficient or poorly configured RHR filters that do not correctly identify potential data 1071  \nhiding and data disclosure issues with the content.  1072  \n6.5 Content  and Protocol -Based Risks  and Attacks  1073  \nThis section  discusses the risks to a CDS or a security domain by  content (e.g., data, files , 1074  \nmessage s) and protocols.  This starts with a discussion of what constitutes a data transfer risk. 1075  \nWhile  there are  an indefinite number ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}100{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "99", "chunk": "of mechanisms within  content  or a protocol that may pose  a 1076  \ndata transfer risk, those mechanisms can be grouped into three broad categories: data attack risks, 1077  \ndata hiding risks, and data disclosure risks.  1078  \nThe NSA publishes a series of documents called Inspection and Sanitization Guidance (ISG) 1079  \nDocuments which provide a detailed discussion of the data hiding and data disclosure risks of  1080  \ncommonly used data types and protocols. ISGs  is also general discussion of some potential data 1081  \nattack risks.  1082  \n6.5.1  Data Attack Risks  1083  \nThe data attack  risk of a file type or protocol is the likelihood that vulnerabilities associated with 1084  \nthe content can be  used to exploit a system based on processing (i.e., parsing) that content. 1085  \nMalicious activities associated with data attack risks generally conform to the following three 1086  \nphases of a data attack:  1087  \n1. Delivery and implantation of the malware (includes executio n of the actual exploit) . 1088  \n2. Establishment and maintenance of communications with the malware\u2019s C2 servers28. 1089  \n3. Activation of the malware\u2019s malicious activities, including data exfiltration, DoS, or 1090  \ndestruction of system assets (e.g., system components or system data)29. 1091  ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}101{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "100", "chunk": "\nProtocol and Data attacks can usually be executed based on three broad categories of 1092  \ndata/protocol vulnerabilities : 1093  \n1. Syntactic \u2013 The attacker sends data to the target system that is not compliant with the file 1094  \nformat  or protoco l\u2019s structure or syntax to execute an exploit . 1095  \n2. Semantic \u2013 The attacker sends data to the target system that is syntactically correct,  but 1096  \nthe values (or sometimes type) of the data fields are not compliant with the specification 1097  \n(e.g., negative  integer ins tead of a positive integer  for a length , a string instead of a float  1098  \nfor a latitude , \u201cyes\u201d instead of \u201ctrue\u201d for a Boolean ). 1099  \n \n28 In some cases, the C2 capabilities of the malware are contained within the malware\u2019s initial delivery mechanism;  \nin other cases, C2 capabilities are separate from the malware\u2019s initial delivery mechanism.  \n29 The data exfiltration activities associated with data attack risks can also utilize techniques that are associated with \ndata hiding risks.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 45 of 397 3. Logical \u2013 The attacker sen", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}102{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "101", "chunk": "ds structurally and semantically correct data but logically 1100  \nincorrect data to the system to cause the dev ice to operate outside of its design parameters 1101  \nor intended operation (e.g.,  If a protocol for setting the RPM of a device allows a range 1102  \nof 0 to 30K RPM but a specific device can only operate to a maximum of 5K RPM then 1103  \nif an attacker sends command to th e device to run  30K RPM it could destroy the 1104  \ndevice. ).30 The key for logical data attacks is that the data is valid for the specification but 1105  \njust not for the specific system.  1106  \nWithin syntactic and semantic based attacks there are two main variants:  1107  \n1. Non-compliance with Specification \u2013 In this attack, the data does not comply with the file 1108  \nformat/protocol specification and the software processing that data does not properly 1109  \nhandle it leading to a program crash and possible exploit ation . 1110  \n2. Compliance with Specif ication \u2013 In this attack, the data complies with the specification, 1111  \nbut an incorrect assumption or decision by the developer on how to implement the 1112  \nspecification leads to potential program crash and exploit ation . For example, suppose a 1113  \nprogram processes a  length delimited file and the specification says that ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}103{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "102", "chunk": "a data field is 1114  \n128 characters, but developers knew that by convention ( e.g., common use) that only 16 1115  \ncharacters were used so they hardcoded an array to be 16 characters long.  If an attacker 1116  \nsent a s pecification compliant data field with 128 characters of data instead of 16 1117  \ncharacters , it could lead to a buffer overflow and possible exploit.  While content filtering 1118  \ncannot address the core buffer issue without prior knowledge of the 16 -character limit (in 1119  \nthis case), the content filtering would likely remove the implant. In effect the buffer 1120  \nexploit might work but when the shellcode tries to execute or install the larger implant 1121  \npayload, it would be missing or corrupted.  1122  \n6.5.2  Data Hiding Risks  1123  \nData hiding ri sks refer to the likelihood  that information can be conceal ed within a file or a 1124  \nprotocol\u2019s structure  or features. Generally, data hiding risks are more prevalent in file types than 1125  \nin protocols due to the increased complexity of file types and the difficulty in reliably parsing 1126  \nthem (e.g., inability to precisely decode all the structures in the file). Mo st non -trivial file types 1127  \nhave a potential data hiding risk due to the structure of the data type. As the comple", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}104{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "103", "chunk": "xity of 1128  \nmodern file types increases, so does the data hiding risk.  1129  \nThe increased data hiding risk inherent in modern file types is due in large  part to the increasing 1130  \nnumber of locations to hide data within  those file types. As an example, consider the following 1131  \npartial list of commonly exploited data hiding locations:  1132  \n \n30 Examples: https://en .wikipedia.org/wiki/Aurora_Generator_Test  and \nhttps://www2.cs.arizona.edu/~collberg/Teaching/466 -566/2012/Resources/presentations/topic9 -final/report.pdfUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 46 of 397 \u2022 Email messages may contain unofficial headers.  1133  \n\u2022 Documents may contain hidden te xt in headers and footers, hidden properties, tracked 1134  \nchanges, comments, and internally saved versions.  1135  \n\u2022 Document text may contain embedded hyperlinks or be the same color as the background 1136  \n(e.g., white text on a white background).  1137  \n\u2022 Document text can contain  encoded or obfuscated information.  1138  \n\u2022 Spreadsheets may contain hidden rows, hidden columns, or hidden sheets.  1139  \n\u2022 Spreadsheet fo", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}105{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "104", "chunk": "rmulas may contain hidden text or field codes.  1140  \n\u2022 Presentations may contain hidden slides, overlapping (e.g., obscured) objects, or 1141  \nimproperly cropped images.  1142  \n\u2022 Images may be brightened, contrast -adjusted, or contain steganography (hidden 1143  \nmessages).  1144  \n\u2022 Steganographic31 algorithms and techniques can be used to hide arbitrary data within 1145  \nvirtually any file type (e.g., storing encode textual d ata inside images , video, or audio ). 1146  \n\u2022 A file path to an external resource  can expose  potentially sensitive data including  1147  \nusernames , operating system, dates when the file was create d/modified,  who a document 1148  \nis for, and the organizational structure  of the a uthor \u2019s organization.  1149  \nData hiding can be either intentional or unintentional. Intentional data hiding can occur during 1150  \ndata exfiltration attempts or during the communication of malware C232 data that utilizes a given 1151  \nfile or protocol as a covert channel. U nintentional data hiding can occur during a classified 1152  \ninformation spill, especially when personnel are unaware of hidden classified information within 1153  \nthe structure of a file that was thought to contain only unclassified information.  1154  \nTraditionally, mitiga tion of the da", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}106{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "105", "chunk": "ta hiding risk focused on preventing human -initiated data 1155  \nspillage. Due to the increased sophistication of malware, however, the emphasis is shifting to 1156  \nmitigating techniques like steganography that support automated data exfiltration and mal ware 1157  \nC2 communications.  1158  \n6.5.3  Data Disclosure Risks  1159  \nData disclosure  risks  refer to the likelihood that  sensitive, perhaps classified, information can 1160  \nremain undetected within the content of a file or protocol not due to hiding data within the 1161  \nstructure of the file. Data disclosure issues are usually accidental. Data disclosure problems are 1162  \nrare in protocols.  1163  \n \n31 https://en.wikipedia.org/wiki/Steganography  \n32 Command and Control. It is very common for malware to connect back to external servers to receive command \nand control information. In some cases, malware authors embedded malware C2 data in other data formats like \nimages if they do not have a direct network connection to the malware. This allows the malware C 2 data to \u201cair gap\u201d \njump to other networks.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QA", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}107{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "106", "chunk": "T  \nPage 47 of 397 Example s of data disclosures risks are:  1164  \n\u2022 Inability for software to accurately find security markings because the file format does 1165  \nnot officially support security markings (e.g., Microsoft Word has no support for security 1166  \nmarkings);  1167  \n\u2022 Inability to accurately extract text from a file to perform a \u201cdirty word/phrase\u201d analys is 1168  \non the file\u2019s contents (e.g., failure to extract text from a PDF file that uses a multi -column 1169  \ntext layout, which is a typical layout for newspapers and journal articles); and  1170  \n\u2022 Inability to find security markings embedded within the viewable part of an i mage.  1171  \nAlthough data disclosure risks and data hiding risks are closely related, data disclosures can 1172  \nhappen when no data hiding has taken place.  1173  \n6.5.4  Examples of Content -Based Attacks  1174  \nThis section is intended to  provide  real world context to the data attack and  data hiding issues 1175  \ndiscussed above. While these attacks are generally targeting a user\u2019s endpoint (e.g., Microsoft 1176  \nWindows\u00ae with Microsoft Office\u00ae) , if the CDS does not sufficiently filter  the content then  1177  \nthese content -based attacks would be successfully  transferred  through a CDS. Several 1178  \ncountries33, includi", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}108{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "107", "chunk": "ng Russia  and China, and organized crime have been known, via public 1179  \nsources34, to exploit email attachments or HTTP  delivered content . These content -based attacks 1180  \ntypically use image s, Rich Text Form at (RTF)  emails , HTML emails, PDF files, and Microsoft 1181  \nOffice\u00ae files as the delivery mechanism for malware, malware command and control, and 1182  \nmalware augmentation. They are also known to use the same data formats as a mechanism to 1183  \nexfiltrate data from compr omised systems.   1184  \n Here are several notable examples, according to publicly available reporting:  1185  \n\u2022 The 2016 attacks against the Democratic National Committee and related organizations35, 1186  \nleveraged PNG images to conceal the attacks\u2019 backdoor and emails with ma licious 1187  \nattachments (e.g., RTF files and PDF) to deliver the initial attack.  1188  \n\u2022 The Russian attributed HAMMERTOSS36 attacks used imagery downloaded via HTTPS 1189  \nto perform command and control (C2) of the malware and to exfiltrate data from 1190  \ncompromised organizations.  1191  \n \n33 References to attribution of specific cyber -attacks does not constitute endorsement or confirmation, either \nexpressed or implied, by the National Security Agency or the United States Government.  \n34 https://att", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}109{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "108", "chunk": "ac k.mitre.org  \n35 https://us -cert.cisa.gov/sites/default/files/publications/JAR_16 -20296A_GRIZZLY%20STEPPE -2016 -1229.pdf  \nand https://arstechnica.com/information -technology/2016/11/russian -hackers -throw -trump -victory -party -with-new-\nspear -phishing -campaign  \n36 https://www.fireeye.com/blog/threat -research/2015/07/hammertoss_stealthy.htmlUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 48 of 397 \u2022 The Russian attributed Duqu37 2.0 attacks used imagery to mask malware C2 and 1192  \nMicrosoft  Word \u00ae files to del iver the initial attack.  1193  \n\u2022 The Russian attributed BlackEnergy38 attacks against Ukrainian power industry leveraged 1194  \nmalicious Microsoft Word\u00ae and Microsoft Excel\u00ae with embedded macros.  1195  \n\u2022 The Russian attributed Sandworm39 attack used malicious  Microsoft  PowerPoi nt\u00ae slides.  1196  \n\u2022 Organized crime ransomware attacks are primarily Microsoft Word\u00ae and Microsoft 1197  \nExcel\u00ae files with embedded executables and macros40. 1198  \n\u2022 The Hangover41 group used malicious RTF and Microsoft Excel\u00ae files.  1199  \n\u2022 China has been attributed using malicious im ages (e.g., CV", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}110{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "109", "chunk": "E 2013 -390642) against targets 1200  \nto gain a presence on the workstation.  1201  \n\u2022 Multiple nation -state affiliated Advanced Persistent Threats (APT), including North 1202  \nKorea attributed actors , are exploiting COVID -19 to deliver content -based attacks43. 1203  \n\u2022 APTs are increasingly using encrypted HTTP connections44 with dynamic URLs or hard 1204  \nto block URLs (like Facebook\u00ae, Github\u00ae) to host malicious content and they use 1205  \npolymorphic45 techniques to evade  antivirus.  1206  \nThe MITRE ATT&CK\u00ae framework ( https://attack.mitre.org ) has a robust listing of different 1207  \nattack mechanisms and techniques including with attribution. The \u201csoftware\u201d and \u201cgroup\u201d tabs 1208  \non the website are a good place to start.  1209  \nContent and protocol -based threats  can be effectively mitigated in a CDS using advanced content 1210  \nfiltering technologies . CDS filtering is discuss ed in Section 7.5 Filtering . 1211  \n \n37 https://media.kasperskycontenthub.com/wp -\ncontent/uploads/sites/43/2018/03/07205202/The_Mystery_of_Duqu_2_0_a_sophisticated_cyberespionage_actor_ret\nurns.pdf  \n38 https://securelist.com/blackenergy -apt-attacks -in-ukraine -employ -spearphishing -with-word -documents/73440/  \nand https://www.welivesecurity.com/2016/01/03/blackenergy -sshbeardoor", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}111{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "110", "chunk": " -details -2015 -attacks -ukraini an-news -\nmedia -electric -industry  \n39 https://www.infose curity -magazine.com/news/mi crosoft -zero-day-traced -russian  \n40 https://arstechnica.com/information -technology/2016/04/ok -panic -newly -evolved -ransomware -is-bad-news -for-\neveryone  \n41 https://unit42.paloaltonetworks.com/updated -backconfig -malware -targeting -Govern ment -and-military -\norganizations  \n42 https://www.fireeye.com/blog/threat -research/2014/01/trends -in-targeted -attacks -2013.html  and \nhttps://threatpost.com/multiple -chinese -espionage -campaigns -could -be-linked-to-central -operation/102934  \n43 https://resources.malw arebytes.com/files/2020/04/200407 -MWB -COVID -White -Paper_Final.pdf  \n44 https://socpub.com/articles/watchguard -report -finds -two-thirds -malware -encrypted -17049  \n45 https://digitalguardian.com/blog/what -polymorphic -malware -definition -and-best-practices -defending -against -\npolymorphic -\nmalware#:~:text=Definition%20of%20Polymorphic%20Malware,bots%2C%20trojans%2C%20or%20keyloggers.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 49 of 397 \n Polyglots  1212  \n", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}112{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "111", "chunk": "Polyglots are files that are more than one file type simultaneously. They are increasingly being 1213  \nused for data attacks especially via email attachment s and web-based download s of content. 1214  \nThey can also be a very effective mechanism for data exfiltration. Most polyglot research and 1215  \nresulting attacks in the last 10+ years has focused on using polyglots to trick the user in opening 1216  \na file that they think is one format (usually PDF or HTML) while it is actually an executable.  1217  \nSome notable examples are:  1218  \n\u2022 https://medium.com/swlh/polyglot -files-a-hackers -best-friend -850bf812dd8a  1219  \n\u2022 https://cyware.com/news/attackers -are-using -polyglot -images -in-malvertising -attack s-to- 1220  \nhide-their-malicious -payloads -e0615041  1221  \n\u2022 https://github.com/mindcrypt/polyglot  1222  \n\u2022 https://g ithub.com/corkami  1223  \n\u2022 https://troopers.de/wp -content/uploads/2011/04/TR11_Wolf_OMG_PDF.pdf  1224  \n\u2022 https://truepolyglot.hackade.org  1225  \n\u2022 https://chefsecure.com/courses/xss/recipes/polyglots -the-ultimate -xss-payloads  1226  \n\u2022 https://www.cse.chalmers.se/~andrei/ccs13.pdf  1227  \n\u2022 https://www.gcst.ae/11 -biggest -cyber -security -threats -in-2021  1228  \n 1229  \nIn 2010, NSA did an experiment using Microsoft Office 2003\u00ae and the ol", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}113{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "112", "chunk": "d binary Microsoft 1230  \nOffice\u00ae format to demonstrated how a single file can be a Microsoft Word\u00ae, Excel\u00ae and 1231  \nPowerPoint\u00ae all at the  same time. This can be easily used to exfiltrate data. It is unlikely a 1232  \nhuman reviewer would catch this type of issue unless they tried to open the file in all three 1233  \nprograms . It has been shown by Corkami and others that successful polyglots can support  1234  \nMacOS\u00ae, Linux\u00ae and Windows\u00ae executables.  PDF and HTML are frequently chosen as the 1235  \nbase data type for polyg lots because the specifications and their associated implementations 1236  \nshare several  common traits:  1237  \n 1238  \n1) The specifications are complex and ambiguou s.  1239  \n2) The specifications allow for content to be in the file that will not be rendered .  1240  \n3) The specifications have \u201choles\u201d that allow unvalidatable content to be present  1241  \na) In PDF, %PDF- is used to identify the file is as a PDF . It must appear in the first 1023 1242  \nbytes of the file. Polyglot malware developers frequently use the first 1000 bytes of 1243  \nthe PDF to insert the beginning of a n executable then jumps into a blob (usually what 1244  \nappears to be \u201cvalid\u201d encrypted content) in the PDF to  execute the malicious payload . 1245  \nb) Prior to HTML5,", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}114{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "113", "chunk": " web browser developers were told to ignore element and attributes 1246  \nit did not recognized46. Unfortunately,  that is still common with modern browsers.  1247  \n \n46 https://www.w3.org/TR/html401/appendix/notes.htmlUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 50 of 397 HTML5 also has custom data attributes47 (i.e., data-*) in w hich nearly any 1248  \narbitrary data can be stored and they are accessible via JavaScript.  1249  \n4) They both support JavaScript . 1250  \n5) They both support comments . 1251  \n6) They allow embedding of images48.  1252  \n 1253  \nPolyglot  developer s use these and other characteristics of file format s to \u201cweave\u201d the file format 1254  \ntogether.  1255  \n 1256  \n 1257  \n  1258  \n  1259  \n \n47 https://html.spec.whatwg.org/multipage/dom.html#embedding -custom -non-visible -data  (Section 3.2.6.6) and \nhttps://www.sitepoint.com/how -why-use-html5 -custom -data-attributes  \n48 See the base64 capability in the Data URL ( https://datatracker.ietf.org/doc/html/rfc2397#section -2) which can be \nused to embed an encoded image directly in HTML file.UNCLASSIFIED//FOR OFFICI AL USE ONL", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}115{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "114", "chunk": "Y//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 51 of 397 7 Foundational Concepts  1260  \nThis section describes the core CDS foundational concepts that are used to understand the 1261  \nrequirements described later in this document.  1262  \nThe genesis of the RTB Strategy was the realization that for most of the history of CDS 1263  \ndevelopment within the USG, there has been little in the way of formal design and 1264  \nimplementation guidance that is based on an understanding of actual threats and core engineering 1265  \ndesign principles (e.g., failsafe design). This document attempts to rectify that shortcoming.  1266  \nTo thoroughly understand this document, it is strongly recommended that the reader first read the 1267  \nNSA Publication Policy Enforcement Failur e Analysis (PEFA)49, version 3.0, 25 April 2013.  As 1268  \ndefined in that paper, \u201cPEFA is an architectural analysis used to assess the number of 1269  \ncomponents that must be compromised in order to violate the security of a system, as defined by 1270  \nits security policy.  PEFA takes inspiration from traditional failure analysis, while gener alizing 1271  \nthe concept of f", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}116{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "115", "chunk": "ailure  to include improper implementations and malicious activity. The key 1272  \nprinciple behind PEFA is that redundant and independent enforcement of security policy 1273  \nincreases the work that goes into a successful attack. PEFA assesses architectural strength in 1274  \nterms of the number of independent components that must cease enforcement before some 1275  \nsecurity policy is no longer enforced at all.\u201d  This document assumes the re ader has read and 1276  \nunderstands the PEFA paper.  1277  \nA CDS is only as secure as its weakest component. All layers of the CDS stack including, but not 1278  \nlimited to, physical hardware, firmware, operating system, and filtering software, should 1279  \nimplement the concept of \u201cDefense in Depth.\u201d  1280  \n7.1 Secure by Design  1281  \nOne of the key principles of RTB is \u201cSecure by Design\u201d and the design patterns, principles, and 1282  \nrequirements in this document are intended to reinforce that principle. The \u201cSecure by Design\u201d 1283  \nprinciple has an implicit acknowledgement that it is not possible to test any reasonably complex 1284  \nsystem to the point that it can be determined to be secure. Unlike cryptographic systems where 1285  \nthe algorithms can be proven valid for a period of time (based on computational r equirements to", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}117{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "116", "chunk": " 1286  \nbreak) and the implementations can be proven secure via formal methods, a software based CDS 1287  \nis simply  too complex to prove mathematically that it is correct and secure.  The \u201cSecure by 1288  \nDesign\u201d principle in RTB attempts to add enough redundan cy and resilience to the system such 1289  \nthat the damage caused by faults of individual components can be contained to prevent a fail 1290  \nopen condition50. Additionally, this allows testing efforts to focus on tho se components, 1291  \n \n49 Email ncdsmo @nsa.gov  to get a copy of this paper.  \n50 In the context of CDS, a \u201cfail open condition\u201d means that the CDS is performing functions without any security \nenforcement in place. In the case of a transfer CDS, this means the filters are not being invoked but data is still being \ntransferred.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 52 of 397 determine d through analysis of desig n and implementation , that are likely to present the greatest 1292  \nrisk of failure or improper/unsafe implementation.  1293  \n7.2 Principles of Least Privilege , Least Knowledge , & Least Functionality  1294  ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}118{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "117", "chunk": "\nRTB leverages  three foundational computer security principles  as the basi s for many of its 1295  \nrequirements. These  principles are:  1296  \n1. Principle of Least Privilege  (POLP) . The Principle of Least Privilege  (CDS Context)  1297  \nstates tha t users and processes in a CDS  should only have the necessary privileges to 1298  \nperform its function and nothing more .  1299  \na. This principle has been the basis for  the implementation of RBAC and MAC  1300  \nmechanisms used in CDS.  Linux Capabilities and SECCOMP are also used to 1301  \nhelp implement POLP.  1302  \nb. For example, if a CDS had a protocol adapter  that needed to bind to  a privileged 1303  \nport (<1024) then the Linux Capability CAP_NET_BIND_SERVICE  can be used 1304  \nto give the process the ability to bind to the port without running the pro cess as 1305  \nroot  thus, limiting the amount of privilege the process needs.  1306  \n2. Principle of Least Knowledge  (POLK)51 \u2013 The Principle of Least Knowledge (CDS 1307  \nContext) states that users and processes in a CDS should: (1) only have access to the 1308  \ninformation necessary to perform its function and not hing more and (2) only 1309  \ncommunicate with processes for which it is intended and nothing more.  1310  \na. Much of the Process Isolation Requi", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}119{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "118", "chunk": "rements (PIR), System Integrity 1311  \nRequirements (SIR), and Operating System Security Requirements (OSSR) 1312  \nsections of this document are intended to enforce the POLK principles by 1313  \napplying multiple layers around processes to prevent lateral movement by an 1314  \nadversary within the CDS, privilege escalation, and prevent exfiltration of CDS 1315  \nconfiguration data and software off the CDS.  1316  \nb. For exam ple, if the processes in a linear  pipeline have knowledge of (e.g. , read  1317  \naccess to) other pipeline components\u2019 configurations and software (e.g., binaries 1318  \nand libraries) and  if that filter or protocol adapter is compromised then access to 1319  \nthat information could enable an attacker to compromise other components of the 1320  \nsystem. This is especially problematic for protocol adapters which are externally 1321  \nfacing and thus easier to directly a ttack and exfiltrate from. If a compromised 1322  \nprotocol adapter could read all the filter binaries and their configuration files, then 1323  \nan attacker could exfiltrate the information off the CDS, reverse engineer the 1324  \nbinaries, and then develop exploits against t hose processes that could be exploited 1325  \nby content  sent to the CDS.  1326  \n \n51 https:/ /en.wikipedia.org/", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}120{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "119", "chunk": "wiki/Law_of_DemeterUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 53 of 397 3. Principle of Least Functionality  (POLF)52 \u2013 The Principle of Least Functionality  (CDS 1327  \nContext) states that processes in a CDS should only perform its essential functions and 1328  \nno more .  1329  \na. The POLF principle is \u201cenforced\u201d via architectural patterns  and concepts (see 1330  \nRAIN in the next section) that emphasize decomposing CDS processes (especially 1331  \nthe filtering pipelines) into distinct independent evaluable functions.  1332  \nb. For example, in a linear pi peline for an XML CDS  there would typically be two 1333  \nPas, two independent XML schema validators, and two independent XML 1334  \nStylesheet Transformation engines.  In this example  POLF is implemented by each 1335  \ncomponent of the pipeline performing a specific function. The protocol adapter 1336  \nreceives the data to  be filtered and sends it to the XML schema validator to 1337  \nvalidate the  data against a schema  and then if the data is well-formed  the XML 1338  \nStylesheet Transformation  filter is used  to transform the data or a", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}121{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "120", "chunk": "pply 1339  \nlogical/ policy enforcement  filtering . In many older generation CDS, all three 1340  \nfunctions were frequently in a single process \u2013 that would violate POLF.  1341  \nc. Within the context of RTB, CDS processes and especially pipeline process es 1342  \nshould be designed and implemented to perform only a single core function (e.g., 1343  \nfor filters see the list in Section  7.5.3  Common Functions of Content Filters ).  1344  \nThe use of POLP, POLK, and POLF, if implemented throughout the design  of the CDS , help to 1345  \nminimize the attack surface of the CDS and its individual processes.  1346  \n7.3 Redundan t, Always Invoked, Independent Implementations, and Non - 1347  \nBypassable (RAIN) Explained  1348  \nThe core design concept with which all CDS used by the USG must now comply is called 1349  \nRAIN53. This design concept is an instantiation of PEFA within the context of CDS. The RAIN 1350  \nacronym is defined as:  1351  \n\u2022 Redundant  1352  \no Security -relevant c omponents ( including  filters  and domain separation ) are 1353  \ninvoked twice for each unique function ( e.g., a CDS with two JPEG filters , using 1354  \nboth a diode and software -based  MAC for domain separation ) 1355  \n \n52 See NIST SP 800 -171A, Section 3.4.6 (https://nvlpubs.nist.gov/nistp", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}122{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "121", "chunk": "ubs/SpecialPublications/NIST.SP.800 -\n171A.pdf) and NIST SP  800 -53 Rev 5 CM -7 Least Functionality \n(https://nvlpubs.nist.gov/nistpubs/SpecialPublicatio ns/NIST.SP.800 -53r5.pdf)  \n53 RAIN is loosely related to the acronym NEAT (non -bypassable, evaluable, always invoked, and tamper \nproof/resistant) that has long been used in the development of Encryption devices. However, Encryptors are \nconsiderably simpler th an CDS and formal methods evaluation of a modern CDS with non -trivial datatypes is \nsimply not practical. The RAIN approach is more applicable to the primary design concerns of a CDS. While adding \ntamper resistance to a CDS, especially tactical, is a requir ement \u2013 it is not a core security requirement for the \nmajority of CDS.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 54 of 397 o Redundant does not mean that the components being invoked must be 1356  \nindependent implementations \u2013 just that the components are invoked twice  1357  \n\u2022 Always Invoked  1358  \no Security -relevant c omponents ( especially  filters) are always executed . 1359  \no Best implemented in a pipeline design pattern  wi", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}123{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "122", "chunk": "th a linear flow . Always invoked 1360  \ncan be implemented with two (2)  or more components (usually filters) in parallel 1361  \n\u2013 however this is not recommended  because  it can make achieving a non - 1362  \nbypassable design more comp lex. Filtering for a single file should be in series. 1363  \nThe filtering  in parallel of multiple files is allowed; however,  for dataflows that 1364  \nrequire in -order delivery the use of parallel filtering of multiple files is not 1365  \nrecommend ed. 1366  \n\u2022 Independent Implementations  1367  \no Reducing or eliminating single points of failure in the CDS is the core objective 1368  \nof independent implementation.  1369  \no Security -critical components (usually filters and orchestration engines) must have 1370  \nmore than one independent implementation ( e.g., two JPEG  filters using different 1371  \nvendor s\u2019 JPEG libraries). Ideally, the independent implementation s would be on 1372  \nseparate hardware platforms  with different operating systems.  Separate hardware 1373  \nplatforms are defined as systems with different  NICs, GPUs,  CPUs ( e.g., AMD\u00ae  1374  \nvs. Intel\u00ae , ARM \u00ae vs. X86, X86 vs. SPARC \u00ae), and supporting chipsets.  1375  \no In some environments, independent implementations for domain separation will 1376  \nbe required  and", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}124{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "123", "chunk": ", in most cases , the independent  separation will require hardware - 1377  \nbased  separation . See section 0. 1378  \no Different developers shall  be used to implement the different implementations to 1379  \nreduce the li kelihood of the same programming  or logic  mistake  occurring twice.  1380  \nThe developers:  1381  \n\u25aa Can share  common requirements, data format , and  protocol specification s.  1382  \n\u25aa Can share  common test data  but each developer  is strongly encouraged to 1383  \ndevelop their own test data.  1384  \n\u25aa Can share  a common  Application Programming Interface  (API)  1385  \nspecification but not the code.   1386  \n\u25aa Must not participate in code reviews or design discussions for the other 1387  \nimplementation.  1388  \n\u25aa The design of the com ponents shall not be shared between the developers.  1389  \no Use of different programming languages for each implementation and its 1390  \nsupporting libraries is strongly encouraged.  1391  \no Use of different compilers (or compiler collections) for the different 1392  \nimplementations i s strongly encouraged (e.g., GNU Compiler Collection54 vs. 1393  \n \n54 https://gcc.gnu.org  vs. https://llvm.orgUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFI", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}125{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "124", "chunk": "ED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 55 of 397 LLVM55). 1394  \no Reuse of OS provided libraries is allowed , though  discouraged,  in independent 1395  \nimplementations. However, the core software and libraries that implement the 1396  \nprimary  function must be independent. For example, if a develope r created two 1397  \nXML filters and used RHEL\u00ae \u2019s version of libxml2 in the first filter then the 1398  \nsecond filter  must use a different XML library ( e.g., Xerces -J or Saxon) since  the 1399  \ncore function of the filter  is XML filtering.  However, RHEL\u00ae \u2019s glibc would be 1400  \nreused between the filters.  1401  \no Supporting function s (e.g., a custom IPC wrapper library) may be reused but 1402  \ndiverse implementation s (e.g., glibc  vs. mus l) are preferred . If diverse 1403  \nimplementations are available and not used, the  CDS developer is required to 1404  \nexplain why a diverse implementation is not achievable.  1405  \no Implementations must implement the POLF concept.  1406  \no The ability to evaluate the correctness and completeness of a component is critical 1407  \nto ensuring that it is saf e, secure, and only performing  the required function . 1408  \n\u2022 Non-Bypassable  1409  \no The system is desig", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}126{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "125", "chunk": "ned such that security -relevant components ( e.g., filters) 1410  \ncannot be circumvented. U sually this implies some type of MAC  and DAC 1411  \nenforced linear flow in the system although there are other ways (sometimes with 1412  \nless assurance) to implement the capability ( e.g., implementing one -way controls 1413  \nat intermediate stages of the linear flow or using filter reports signed by each fil ter 1414  \nrequired for the data flow) . 1415  \nEssentially , RAIN attempts to ensure that no single failure and no single exploit can compromise 1416  \nthe CDS. H owever, as is demonstrated throughout this document, there are compromises that 1417  \nmust be made in certain areas based on current technology limitations.  In all cases, RAIN shall  1418  \nbe applied at the overall system level in addition to the sub -system level56.  For example, if the 1419  \nCDS will be connected to  one or more high threat network s (HTN), then the use of a single box 1420  \nsoftware CDS is not sufficient to counter the threat.  In this environment, it is necessary to 1421  \nimplement redundancy in the domain separation mechanism using  hardware enforced  one-way 1422  \ntransfer  mechanisms  or hardware enforced filtering . Cascading and Chaining (see Unacceptable 1423  \nDesign Patterns 4 and ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}127{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "126", "chunk": "5  in Section 8.2) of software CDS running on commodity CPU and 1424  \noperating  systems does not meet the independent domain separation requirement.   1425  \nThere are some subsystems in a CDS where Redundant and Independent portions of RAIN do 1426  \nnot apply. This include s: 1427  \n1) Protocol Adapters  1428  \n \n55 LLVM is not an acronym . \n56 In this context \u201csystem level\u201d is also referring to other components of a cross domain solution architecture (e.g. , \nsimple diode solutions) in addition to just a single box software CDS. \u201cSub -system level\u201d refers to the software CDS \nin this context.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 56 of 397 2) Normalization Functions  1429  \n3) Journaling, Auditing and Loggi ng Subsystems  1430  \n4) Event Management/Policy Enforcement Subsystems  1431  \n5) Remote Management Subsystems  1432  \n6) Remote Monitoring Subsystems  1433  \n7) Syste m Administration Subsystems  1434  \n8) Installation and Backup/Recovery Subsystems  1435  \nThe RAIN design concept and the design patterns described in  this document are intended to 1436  \naddress the practical reality that ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}128{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "127", "chunk": "in any modern CDS processing modern data types , it is simply 1437  \nnot possible to prove mathematicall y the system is safe and secure . If sufficient redundancy and 1438  \nindependence are implemented and  the design is solid , the ability of the system to preven t fail 1439  \nopen condition s should be substantially reduced.  1440  \nImplementing RAIN in the design of a CDS is required  for the  CDS to be  RTB compliant.  1441  \nCDS deployments that fail to implement redundant and independent filtering are not considered 1442  \nRTB compliant.  1443  \n7.4 Platform Security  1444  \nOne of the main tenets behind RTB is the improvement in the platform security of the CDS. The 1445  \nplatform includes the operating system, hardware, and supporting software (not directly related 1446  \nto the purpose of the device).  This section discusses the various technologies used to build 1447  \nmodern CDS and why a combination of technologies is required to build a modern secure CDS.  1448  \n7.4.1  The Evolution  of the MAC  1449  \nPrior to RTB, the primary security enforcement mechanism  for CDS operating on the  Solaris\u00ae 1450  \nor Linux\u00ae operating systems were  DAC57 and MAC. In the case of MAC , it was primarily based 1451  \non the combination of  the Bell -LaPadula  Confidentiality Model5", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}129{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "128", "chunk": "8 with the Biba  Integrity 1452  \nModel.59 This combination is frequently referred to as BLB. These model s were groundbreaking 1453  \nin their approach to describing how computer systems should handle protecting the 1454  \nconfidentiality and integrity of processes and data. For most of the 1980s through approximately 1455  \n2015 the majority of CDS used by the USG use d the B LB approach for the MAC enforcement .  1456  \nUsing BLB for CDS resulted in CDS with  arbitrary hierarchical  relationship s between processes  1457  \n \n57 DAC is basically Read/Write/Execution permissions associated with Users/Groups/World. All Unix\u00ae and \nLinux\u00ae based syste ms use a similar DAC model though many have extended it over the year s with extended \nattributes. DAC will not be discussed in this section since it is well understood and not sufficient  for protecting a \nsystem.  \n58 https://en.wikipedia.org/wiki/Bell%E2%80%93 LaPadula_model  \n59 https://en.wikipedia.org/wiki/Biba_ModelUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 57 of 397 when none existed . While  this approach may be useful in  some types of MLS systems (", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}130{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "129", "chunk": "e.g., 1458  \nmulti -level databases, multi -level file servers) it led to overly complex MAC policies for most 1459  \nCDS  and frequently led to CDS being implemented as a  single process or a small number of 1460  \nprocesses. Historically, MLS CDS did not,  and still do not, implement  good design practices like 1461  \nPOLP, POLK, POLF , and especially RAIN. In order to enforce a dataflow on a traditional MLS 1462  \nCDS , exceptions had to be implemented in the MAC policy to allow data to move.  Additionally, 1463  \nthe implementati on of BLB led to a common misperception amongst security engineers that 1464  \nrelabeling data (e.g., a file on disk) was all that was needed to \u201csafely\u201d move the file between 1465  \nlevels. This has the side effect of many MLS systems lacking any real filtering of the content.  1466  \nEssentially, MLS MAC uses operating system labels as the primary deciding factor instead of 1467  \nfiltering to determine if content should be shared. While label s are a very important factor in a n 1468  \nMLS database or file store , they are not the primary fac tor in a transfer CDS.  Additional ly, the 1469  \nlabel s are the file system label and not internal to the objects \u2013 there was no actual association. It 1470  \nwas common to have classified MLS file stores  ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}131{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "130", "chunk": "with objects that were internally label led 1471  \nunclassified.  1472  \nTo addres s these issues, new MAC  enforcement concepts were developed, like Domain and 1473  \nType Enforcement  (DTE)60.  DTE is focused on controlling how a process interacts with the 1474  \nsystem  including with other  processes and files . DTE is used to  precisely  enforce information 1475  \nflows between processes. Most modern transfer and access CDS are implemented o n operating 1476  \nsystems that use DTE (e.g., SELinux  Policy ) as the MAC mechanism . The design patterns in this 1477  \ndocument assume a MAC model that focuses on flow en forcement and process isolation rather 1478  \nthan process hierarchy.  Many DTE -based systems can be leveraged to also implement  the BLB 1479  \ntype of MLS policy.  1480  \n7.4.2  MAC is not Enough  1481  \n(U//FOUO)  As the complexity and innovation in cyberattacks has increased, it has become 1482  \nincreasingly evident that DAC and MAC alone are not sufficient for the development of secure 1483  \nplatforms.  The major limitations in DAC and MAC are that they generally do not address 1484  \nseveral  classes of attack including  (but not limited to) : 1485  \n1) (U//FOUO)  Kernel e xploitation via defective System Calls  1486  \n2) (U//FOUO)  Return -oriented and jum", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}132{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "131", "chunk": "p -oriented programming (ROP/JOP) attacks61 1487  \n3) (U//FOUO)  Data exfiltration from a CDS due to CDS internal lateral movement  1488  \n4) (U//FOUO)  Destination environment attack due to CDS internal lateral movement  (not 1489  \n \n60 https://en.wikipedia.org/wiki/Type_enforcement , \nhttps://www.usenix.org/legacy/publications/library/proceedings/security95/full_papers/badger.pdf , \nhttps://www.nsa.gov/Portals/70/documents/resources /everyone/digital -media -center/publications/research -\npapers/the -inevitability -of-failure -paper.pdf , \nhttps://scholarworks.wm.edu/cgi/viewcontent.cgi?article=3219&context=etd  \n61 https://en.wikipedia.org/wiki/Return -oriented_programmingUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 58 of 397 related to insufficient filtering)  1490  \n5) (U//FOUO)  Physical access attacks and attacks via physical components  1491  \n6) (U//FOUO)  Resource exhaustion attacks  1492  \n7) (U//FOUO)  Privilege escalation attacks  1493  \n(U//FOUO)  Additionally, MAC policy can be v ery complex to create and analyze. It takes 1494  \nanalysts with years of experience to determine if the MAC po", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}133{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "132", "chunk": "licy is correctly  enforc ing the 1495  \nstated security argument and if the state d security argument is itself sufficient for the system it is 1496  \ntrying to protect . Historically CDS have relied  on MAC as the primary security enforcement 1497  \nmechanism so if there was mistake in the MAC policy or if MAC was disabled there was nothing 1498  \nelse other than DAC and some integrity monitoring of the filesystem protecting the system . 1499  \nThere are technologies that have been develop ed to address the above concerns . The class of 1500  \nattack to mitigation  mapping for those technologies is below.  How these technologies are 1501  \nimplemented in a CDS is described later in this document.  1502  \n 1503  \nTable 2 \u2013 Class of Attack to Technology Mitigation Mapping  1504  \n(U//FOUO)  \nClass of Attack  Technology Mitigation  \n(U//FOUO)  Kernel exploitation \nvia defective System Calls  SECCOMP  \n(U//FOUO)  ROP/JOP attacks  Control Flow Integrity implementations in chips, \noperating systems, and compilers  \n(U//FOUO)  Data exfiltration from \na CDS due to CDS internal lateral \nmovement  SECCOMP, MAC, DAC, Namespace s, Uni -directional \nIPCs , Modular Pipeline Components  \n(U//FOUO)  Destination \nenvironment attack due to CDS \ninternal lateral movement  SECCOMP, MAC, DAC, Names", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}134{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "133", "chunk": "pace s, System Integrity \nChecker (SIC), Configuration Integrity Checker (CIC) , \nApplication Allowlisting , Modular Pipeline Components  \n(U//FOUO)  Physical access \nattacks and attacks via physical \ncomponents  Secure Boot, Trusted Boot, Encrypted Disks , Active Anti -\nTamper  \n(U//FOUO)  Resource exhaustion \nattacks  CGROUPS  \n(U//FOUO)  Privilege Escalation  MAC, DAC, SECCOMP, Linux Capabilities, SETUIDUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 59 of 397 (U//FOUO)  \nClass of Attack  Technology Mitigation  \nAttacks  Wrapper Programs , Compiled m emory -safe languages  \n(U//FOUO)  Modification of \nfilesystem  DAC, MAC, SIC/CIC, Application Allowlist s, Secure \nBoot, Trusted Boot  \n(U//FOUO)  \n 1505  \n7.5 Filtering  1506  \nThis section covers the fundamental concepts and principals behind content filt ering in cross 1507  \ndomain solutions. The filtering is the act of processing content or a protocol  to reduce data 1508  \nattack, data hiding, and data disclosure risks.  There  are a few core principles that need special 1509  \nemphasis as they are reflected throughout this paper:  1510  \n\u2022 (U//FOUO)  ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}135{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "134", "chunk": "Most content and protocol -based  attacks are crafted to exploit  syntactic or 1511  \nsemantic (see Section 6.5.1 ) parsing problems within end  user application s. A lower  1512  \nnumber of problems , but still significant , are attacks that exploit logical problems  in the 1513  \nprograms  and systems . CDS  software  are potential ly susceptible to the same type s of 1514  \nproblems  as end user software.  The design patterns a nd other security requirements in 1515  \nthis document are intended  to address both the content -based  attack s through the CDS 1516  \n(e.g., the core purpose of a transfer CDS ) and the content/protocol attacks  directed  1517  \nagainst the CDS.  1518  \n\u2022 Normalizing data into a simpler common form, apply ing filter policies , and rebuilding the 1519  \noriginal format has been shown to be the most effective way to stop syntactic  and 1520  \nsemantic based attacks  without destroying the usability and flexibility of the original data 1521  \ntype. Thi s document strongly emphasizes this technique over all others. Testing, 1522  \noperational use, and multiple real-world implementations have demonstrated that this 1523  \ntechnique  can be used for most  USG -used file types that are transferred through CDS.  1524  \n\u2022 Implemen ting randomized loss via fil", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}136{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "135", "chunk": "tering is a highly effective means to neutralize  1525  \nembedded  malware in many data types which use large binary blobs ( e.g., audio, images, 1526  \nvideo) and can substantially reduce covert channels (e.g., embedded steganography and 1527  \nmalwar e command and control  (C2)). No technology can eliminate  covert channels and 1528  \nstill maintain usable  content and/or data rates.  1529  \n\u2022 Modern CDS filters are expected to have the capability to address l ogical problems in the 1530  \ndata.  Logical filtering is the primary means for address ing non-steganography based data 1531  \nhiding/data loss prevention issues . Logical filtering is the primary mechanism to apply 1532  \nfiltering policy to data. Compliance with the Data Owners Guide (DOG)  for a cr oss 1533  \ndomain data flow  is usually implemented in logical filtering. For example, fixed format 1534UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 60 of 397 filters are expected to be able to handle logical filtering mechanisms like co-constraint 1535  \nvalidation, field modification, if -then-then-that operations, and geograph ic bounding 1536  \n", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}137{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "136", "chunk": "boxes.  1537  \n\u2022 In a traditional MLS  based CDS, the regrading function is considered a transfer function 1538  \nand the content generally requires fi ltering prior to regrading.  Some exceptions might be 1539  \npossible for an MLS Database dependent on the design of t he database schema and how 1540  \nit enforces constraints on the data.  1541  \nThe design patterns, techniques, and detailed security requirements (e.g., Process Isolation 1542  \nRequirements (PIR)) in this document are intended to address attacks against the CDS.  1543  \n7.5.1  The Golden Ru les of Filtering  1544  \nIn all filtering systems and especially  those  in CDS, there are three golden rules that any well - 1545  \ndesigned and secure filtering systems will implement. The requirements in this document are 1546  \nintended to help ensure the CDS implement s the following three golden rules:  1547  \n\u2022 Cleanliness  1548  \n\u2022 Correctness  1549  \n\u2022 Integrity  1550  \nA filtering solution that fails to implement these Golden Rules of Filtering cannot be trusted to 1551  \nperform its filtering functions securely and accurately  1552  \n Cleanliness  1553  \nCleanliness  is the ability of a filtering solution to guarantee that content (e.g., any ext racted 1554  \ncontent, generated audit data, or reports) from multiple", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}138{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "137", "chunk": " jobs, users, or sessions is not permitted to 1555  \n\u201ccross contaminate\u201d information from a particular filtering job with information from a 1556  \nconcurrent or subsequent filtering job.  1557  \nFor example, if a u ser submits a Microsoft Word\u00ae  document with an embedded Joint 1558  \nPhotographic Experts Group (JPEG) image to a CDS and a second user submits another 1559  \nMicrosoft Word\u00ae  document that also contains an embedded JPEG image to the same CDS, then 1560  \nthe filtering solution  must ensure that both of the Microsoft Word\u00ae  documents and the extracted 1561  \ncontent from those documents (i.e., the text and the JPEG images) never commingle. The 1562  \nfiltering solution must also ensure that after the extracted content is filtered, the extracted  1563  \ncontents that are releasable are reassociated with the Microsoft Word\u00ae  documents from which 1564  \nthey came, even when the filtering solution is handling multiple concurrent filtering jobs.  1565  \n Correctness  1566  \nCorrectness  is the ability of a filtering solution to perform the requested filtering operations 1567  \naccording to specified  dataflow filtering policy . Correctness implies that the filtering solution has 1568  \nbeen validated through some combination of source code analysis, for mal methods, exhau", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}139{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "138", "chunk": "stive  1569  \npositive and negative  testin g, and adversarial emulation including use of data /protocol  fuzzing 1570UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 61 of 397 techniques . 1571  \n Integrity  1572  \nIntegrity  is the ability to determine whether a filtering solution is operating securely and in a 1573  \n\u201cknown good stat e.\u201d Historically , most integrity controls are implemented in many cross domain 1574  \nsolutions through the combined use of Mandatory and Discretionary Access Control mechanisms 1575  \nand a file-based  integrity checker (e.g., Aide, TripWire \u00ae, and Samhain). In an RTB co mpliant, 1576  \nadditional mechanisms (see 7.4.2 MAC is not Enough ) are required  (See GAR,  PIR, SIR, and 1577  \nOSSR sections) . 1578  \n7.5.2  Core Filtering Concepts  1579  \nAll robust content filtering systems have mechanisms to implement the following concepts:  1580  \n\u2022 Syntactic  \u2013 Verifies the content being transferred structurally complies with the data 1581  \ntype\u2019s  specificatio n. This answers the question \u201cis the data well formed ?\u201d (e.g., is it a 1582  \nvalid CSV or XML file)  1583  \n\u2022 Semanti", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}140{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "139", "chunk": "c  \u2013 Verifies the \u201ckeys and values \u201d62 of the content comply with  data type\u2019s  1584  \nspecification.  This answers the question \u201cis the data what it is supposed to be ?\u201d (e.g., is 1585  \nthe angle field a positive in teger  between 0 and 359?, is the person\u2019s nationality a  3-letter 1586  \nalphabetic string ?) 1587  \n\u2022 Logical  (also called Policy  Enforcement ) \u2013 Verifies the \u201ckeys and values \u201d of the content 1588  \nare correct according to t he specific situation/use case.  This answers the question \u201cis the 1589  \ndata compliant with the constraints of my environment ?\u201d (e.g., is the angle for my rotator 1590  \nbetween 0 and 89?, is the person\u2019s nationality USA?)  1591  \no It applies mission specific policies/rules to the data to prevent data spills, data 1592  \nexfiltration , malware C2 and augmentation, exploit delivery, exploit execution, 1593  \nand malware implantation  1594  \no Policy Enforcement filtering may include sanitization, transformation, 1595  \ntransliteration, and normalization actions  (see below)  1596  \no This may require historical knowledge of messages to prevent skewing attacks.  1597  \n7.5.3  Common Functions of Content Filters  1598  \nContent filters are a critical security component of all transfer cross domain solutions, and these 1599  \nfilters can p", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}141{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "140", "chunk": "erform a variety of functions. These functions are delineated into four major 1600  \ncategories:  1601  \n\u2022 Content verification  1602  \n\u2022 Content inspection  1603  \n \n62 It is understood that  not all data types have \u201ckeys\u201d. The \u201ckeys and values\u201d are intended to represent the concept of \nstoring data in a file.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 62 of 397 \u2022 Content suspi cious activity checking  1604  \n\u2022 Content sanitization, cleansing, and transformation  1605  \nIndividual filters could perform one or more of these functions though separating the different 1606  \nfunctions into different filters would result in a more secure system. It is common  in a CDS to 1607  \ncombine inspection and the sanitization, cleaning, and transformation functions of a specific file 1608  \ntype into a single filter for performance and complexity reasons.  However, the RAIN 1609  \nrequirements must still be met.  1610  \n Content Verification  1611  \nContent Verification  ensures that the data type of the submitted content is in fact the type it 1612  \nappears to be. A well -written verification filter will compare th", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}142{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "141", "chunk": "e submitted content\u2019s structure 1613  \nwith the structure of the corresponding specification or standard for t hat content. The content 1614  \nverification function should be performed prior to any inspection or sanitization action.  1615  \nA ve ry simple and somewhat unreliable form of verification is checking the magic number63. 1616  \nThis approach is sometimes used in CDS that  proces s Complex Data because it is a fast way to 1617  \nroute data to the appropriate  filters . If the magic  number  was not correct ( perhaps because of a 1618  \nmalicious file) the content filters would stop the malicious file from being transferred.  1619  \nThe syntactic and semantic  concepts are implemented in this function.  1620  \n Content Inspection  1621  \nContent inspection  analyzes the submitted content to verify that it complies with a defined 1622  \nsecurity policy (e.g., determining conformance of the content to allowed file constructs and 1623  \ncontent portions, identifying file constructs and content portions that are not allowed, and 1624  \ndetermining whether or not the content passes an antivirus  scan).  1625  \nThe syntactic, semantic, logical and policy enforcement concepts are implemented in this 1626  \nfunction.  1627  \n Content Suspicious Activity Checking  1628  \nA Suspici", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}143{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "142", "chunk": "ous Activity Checker  (SAC) is a device that evaluates or executes content submitted to a 1629  \nCDS in a secure manner  and using an appropriate application. This is frequently  called Behavior 1630  \nAnalysis. A SAC  will then monitor the execution or processing of the content for suspicious 1631  \nactivity. SACs  are implemented using  \u201cdetonation chambers\u201d or \u201csandboxes,\u201d and they are often 1632  \nimplemented as a highly specialized and heavily instrumented  hypervisor64. A SAC is n ormally a 1633  \n \n63 https://www.geeksforgeeks.org/working -with-magic -numbers -in-linux  and \nhttps://en.wikipedia.org/wiki/List_of_file_signatures  \n64 An instr umented hypervisor is a hypervisor that has been modified to provide robust introspection capabilities into \nthe execution of the operating system and its applications to support monitoring of process execution flow and \noperating system interaction (e.g., s ystem calls, file and network operations).UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 63 of 397 custom server appliance provided by the SAC vendor. It could operate as  a single level  sidecar to 1634  \nth", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}144{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "143", "chunk": "e CDS or in the environment around the CDS.  Section 7.5.6.2 . 1635  \n Content Normalization, Sanitization, Cleansing, and Transformation  1636  \nContent normalization , sanitization,  cleansing, and transformation  modify content submitted to 1637  \na CDS such that the content , once processed,  will compl y with a predefined security policy. For 1638  \nexample , content sanitization, cleansing, and transformation could remove potential malware 1639  \nfrom content that was submitted to the CDS.   1640  \nContent normalization  (also called canonicalization ) converts the data to a simpler common 1641  \nform wi thout loss of information. For example, most fixed format text and binary data can be 1642  \nconverted to XML without loss of information. Most bitmap images formats ( e.g., JPEG, PNG, 1643  \nGIF, TIFF) can be converted into raw bitmaps without loss of information. The n ormalized form 1644  \nis then filtered  by applying  sanitization and cleansing actions and the data is converted back to 1645  \nthe original data type usually with the loss of some  information  (e.g., due to lossy recompression  1646  \nof the image ). Normalization is very effecti ve at stopping data attacks and some types of data 1647  \nhiding (like those related to information hiding within the structur", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}145{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "144", "chunk": "e of content, e.g., whitespace in 1648  \nXML  between attributes and elements ). Normalization for data types is the rough equivalent of a 1649  \nprotoco l break used with network protocols.  1650  \nContent sanitization  or cleansing  removes  or modifies  specific  data within the content in a 1651  \nmanner that renders the original data unrecoverable (e.g., deleting tracked c hanges from a 1652  \nMicrosoft Word\u00ae  document, removing metadata about the document\u2019s author , changing the 1653  \ncolor of the pixels in an image , flattening a multi -layer vector drawing into a single -layer image ). 1654  \nNote that content sanitization or cleansing does not replace the original content wi th \u201csubstitute\u201d 1655  \ncontent.  Whitespace is not considered \u201csubstitute\u201d content.  1656  \nContent transformation  typically uses one of the two methods:  1657  \n1) It modifies  specific data within the content such that (a) the original data is unrecoverable 1658  \nand (b) the original dat a has been replaced (e.g., reducing the precision of the 1659  \nlatitude/longitude value for a coordinate or replacing the first five numbers of a social 1660  \nsecurity number with the \u201cX\u201d character). Note that content transformation replaces the 1661  \n\u201ctransformed\u201d portion of the original content with \u201csubsti", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}146{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "145", "chunk": "tute\u201d content.  1662  \n2) The format of the content is changed typically from one data type to another. For 1663  \nexample, a PNG  image could be transformed to a JPEG  image or HTTPS POST could be 1664  \ntransformed to a SFTP PUT. When this type of transformation action occurs on a 1665  \nprotocol, it is sometimes called a \u201cprotocol break.\u201d  1666  \nA commonly used filtering technique  in modern CDS  to address Data Attacks in Complex Data 1667  \ntypes is a variant of the normalization process called Content Disarm and Reconstruction (CDR). 1668UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 64 of 397 CDR65 has been shown in both Government  (e.g., NSA and DHS CISA) and commercial testing 1669  \nto be highly effective at stopping malicious attacks, malware C2, malware au gmentation, and 1670  \nmalware initiated exfiltration.  CDR implementations generally work by implementing the 1671  \nfollowing process:  1672  \n1) Validate that the file conforms to its specification . 1673  \n2) Extract embedded content from the file . 1674  \n3) Remove anything known to be unsafe (e.g ., macros, embedded executable), anythi", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}147{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "146", "chunk": "ng that 1675  \nis not recognize d, or anything that cannot be safely modified to conform to the 1676  \nspecification . 1677  \n4) Optionally remove or block content that can cause data loss (e.g., tracked changes, 1678  \ncomments, documents with inapp ropriate security markings or dirty words) . 1679  \n5) Optionally add watermarks or metadata to support tracking of content . 1680  \n6) Rebuild the file . 1681  \nFor data formats like images, the bitmap data can be further sanitized by modifying the pixel and 1682  \ncolor space data in subtle  ways to defeat or at least minimize the amount of steganography 1683  \nencoded data ( e.g., exfiltration, malware C2, malware augmentation, malicious JavaScript for 1684  \nwebsites).  CDR is not sufficient to address Data Hiding issues without addition al processing of 1685  \nthe normalized data.   1686  \nThe policy enforcement concept is implemented in th is filter.  1687  \n7.5.4  Structured, Semi -structured , and Unstructured Data  1688  \nHistorically, data has been grouped into three broad classes according to its degree of structure: 1689  \nstructu red data, semi -structured  data, and unstructured data. These broad classes have been the 1690  \nbasis for scoring many CDS risk assessments. However , this approach is not valid and that the 1", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}148{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "147", "chunk": "691  \nsize and degree of structure inherent within the data being transferred b y a CDS is not an 1692  \neffective metric of risk. It is the  complexity required to validate that the structure is compliant 1693  \nwith a specification ( e.g., an XML schema ), the ability to normalize the data into common 1694  \nsimpler form (e.g., binary normalized into XML) ,  and the ability to safely constrain the data 1695  \nsuch that it is within a defined set of bounds is a better basis for risk assessment.   1696  \n7.5.5  Specification Complexity and Ambiguity  1697  \nContent filtering is a difficult problem due to the complexity of the standards and  specifications 1698  \nthat define the files and protocols to be filtered. Many standards and specifications include 1699  \ndifferent types of data, which are themselves defined by their own complex specification or 1700  \nstandard. As a result, the analysis of a single file f ormat may lead to the additional analysis of the 1701  \nmultiple data types that could be embedded within the file format under investigation.  1702  \nIt is also quite challenging to write applications and parsers to handle such a wide variety of data 1703  \n \n65 https://en.wikipedia.org/wiki/Content_Disarm_%26_Reconstruction .UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}149{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "148", "chunk": "USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 65 of 397 types. This challe nge is complicated by the enormous number of permutations that are possible 1704  \nwithin a file\u2019s internal structure, even when these permutations do not result in changes to the 1705  \nvisual appearance of the file when rendered. To demonstrate this concept, three PDF files were 1706  \ncreated  from the same Microsoft Word\u00ae source file ; each PDF file had a different internal 1707  \nstructure even though the visual appearance of all three files were identical. Below is the test  1708  \nprocedure  used:  1709  \n1. Open the Microsoft Word\u00ae file in Microso ft Word\u00ae 2016 . 1710  \n2. While in Microsoft Word\u00ae 2016 , save the file as a PDF. This is the first version of the 1711  \nPDF.  1712  \n3. While in Microsoft Word\u00ae 2016 , print the file using the Adobe Acrobat \u00ae PDF print 1713  \ndriver for Windows. This step creates a second version of the PDF.  1714  \n4. Open the same Microsoft Word\u00ae file used in the first step with Microsoft Word\u00ae for 1715  \nMac 201 6. 1716  \n5. While in Microsoft Word\u00ae for Mac 2016 , save the file as a PDF. This creates the third  1717  \nversion of the PDF.", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}150{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "149", "chunk": "  1718  \nThis procedure resulted in three different PDF files that, when opened with Adobe Acrobat \u00ae, 1719  \nwere visually identical. Their internal structures, however, were completely different. The ability 1720  \nto have vastly different internal structure s and representations for the same visual appearance 1721  \nsubstantially increases the complexity of filters , especially those addressing data hiding and data 1722  \ndisclosure problems,  to accurately  process that d ata. 1723  \nThe use of custom extensions is another way in wh ich high levels of complexity may be 1724  \nintroduced into files and protocols. Many specifications include ambiguous terminology, such as 1725  \nvendor -specific terms. Specifications may also include placeholders for \u201capplication data,\u201d 1726  \nwhich introduce blocks of data with no  publicly  known structure, syntax, or meaning. The 1727  \ninclusion of vendor -specific terminology and application data placeholders generally complicates 1728  \nthe task of content filtering . This kind of specification ambiguity makes it difficult to determine 1729  \nwhether or not these features will increase the data transfer risk associated with the file type or 1730  \nprotocol under examination.  1731  \nUltimately, as the complexity and ambiguity within a file", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}151{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "150", "chunk": " type specification or protocol 1732  \nspecification increase s, the data transfer risk increases as well. In contrast, specifications that 1733  \ndefine file types and protocols using a strict and simple definition reduce data transfer risk, 1734  \nregardless of whether that file type or protocol is considered structured, semi -structured , or 1735  \nunstructured according to traditional standards.  1736  \nOne should also consider the effect of specification complexity and ambiguity on the 1737  \napplications that are intended to support the r endering of files and protocols.  As the degree of 1738  \ncomplexity an d ambiguity within a file type or protocol increases, so does the number of 1739  \npotential vulnerabilities. This increase in application vulnerability is due , in part, to the  need for 1740  \napplications to be more  \u201cforgiving\u201d of the variations in the files and protoc ols that implement the 1741  \ncomplex and ambiguous specifications.  This concept even has a name: The Robustness Principle. 1742UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 66 of 397 The Robustness Principle can be summarize", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}152{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "151", "chunk": "d by the statement \"Be liberal in what you accept, 1743  \nand conservative in what you send \u201d and was defi ned in Internet Engineering Task Force (IETF) 1744  \nRFC -1122 .66 While originally written to apply to protocol parsing, the concept has been widely 1745  \nimplemented in applications processing all types of data. Unfortunately, implementation of this 1746  \nprinciple has led t o substantial vulnerabilities in many  applications because of the complex logic 1747  \n(e.g., exceptions) required to parse data not compliant with the specification.  It is for this reason 1748  \nspecifically that secure and effective content filtering becomes both necessary and challenging.  1749  \nData types and protocols that are based on machine readable specifications are generally easier 1750  \nand safer to filter than those that are not.  1751  \nCDR can redeem the robustness principle by taking a risky file, normalizing it and removing the 1752  \nextraneous elements, and producing a compliant yet equivalent file.  1753  \n7.5.6  Common Filtering  Techniques  1754  \nThe following section s describe  the common  types of filter ing techniques that are  used in CDS 1755  \nand pros and cons of each mechanism.  1756  \n Signature/Heuristic  Filtering  1757  \nSignature and heuristic filtering techni", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}153{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "152", "chunk": "ques use known malicious content to develop rules and 1758  \npatterns that are then compared with content to determine i t is malicious. The most common 1759  \nimplementation of the signature/heuristic approach is antivirus engines. In a non -CDS 1760  \nenvironment s repudiation scoring is  commonly used. Embedded antivirus engines are used in all 1761  \ntransfer CDS acceptable design patterns thou gh they are not commonly used in tactical CDS due 1762  \nto the use of datatypes that antivirus engines  do not  support.   1763  \n 1764  \nPros  Cons  \nVery Fast Cannot defend against zero-day attacks  \nEliminates known bad  Does not address malware C2  and malware \naugmentation  \nVery good scalability  Does not work against poly/metamorphic and \nencrypted malware  \nCan be integrated on a CDS but the Can only tell if file is bad, but not i f it is goo d \n \n66 https://tools.ietf.org/html/rfc1122, Section 1.2.2UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 67 of 397 Pros  Cons  \navailability of FVEY67 based antivirus \nengines for Linux is decreasing  \nPrimarily used for complex document formats \nand images  Does no", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}154{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "153", "chunk": "t address data hiding and data \nexfiltration issues.  \nMight do basic syntactic filtering.  Not effective against formats not commonly \nused in the commercial sector  \n Does not implement semantic, logical or \npolicy enforcements concepts. Syntactic \nfiltering is simplistic.  \n 1765  \n Suspicious Activity Check ing (SAC)  1766  \nSusp icious Activity Checking systems are widely used in enterprise environment s to detect 1767  \nmalicious content primarily  arriv ing in email. Because of the time  (usually 5 -10 minutes)  it takes 1768  \nfor analysis of the content , the technique is not commonly used inline for low latency, high 1769  \nthroughput system s like web browsing.  A SAC system could  potentially be  integrated with ADP - 1770  \n1, AD P-3, APD -4, and ADP -5 design patterns as a sidecar. However, their  real value for CDS 1771  \nenvironments is in the CDS Defensive Cyberspace Operations out -of-band network to assist in 1772  \nthe automated analysis of quarantined and other journaled content.  1773  \n 1774  \nPros  Cons  \nGood at detecting if content is malicious  Slowest filtering mechanism  (5 to 10 minutes \nper file)  \nProven effective at detecting some classes of  \nzero-day attacks  Has very limited ability to address Malware \nC2 and augmentation . This is u sually det", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}155{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "154", "chunk": "ected \nby monitoring processes making abnormal \ncommunications (e.g., Microsoft Word \u00ae \nopening a socket to a remote external server) . \n \n67 Anti-virus engine that is developed by a company incorporated in a FVEY nation and the development is done in \nthe FVEY nations.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 68 of 397 Pros  Cons  \nCan be implemented as a sidecar to a CDS  Does not address data hiding and data \nexfiltration issues.  \n Cannot  be integrate d on a CDS  \nCan be effective against polyg lot attacks  Supports only a limited set of file types  and \nprimarily those that are based on applications \nthat run on Microsoft Windows\u00ae like \nMicrosoft Office\u00ae  and Adobe Acrobat\u00ae . The \ntargeted application must be lo aded in the \ndetonation chamber  and the detonation \nchamber  software has  to be tuned  for the \ncorrect behavior of the application in order for \nthe detection to work . \n Does not implement syntactic, semantic, \nlogical or policy enforcements concepts.  \n Lack of a \u201cuser on the system\u201d to activate the \nmalware. For example, s ometimes you must \nread the document for several minutes, or", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}156{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "155", "chunk": " \nscroll to page 7, or click OK to continue for \nthe malware to start .  \n The SAC detonation chamber environment \ncan be detected by ma lware which can \nshutdown to avoid detection.  \n 1775  \n Content Disarm and Reconstruction (CDR)  1776  \nThis is the most used  technique in CDS today to process complex document formats. It is also 1777  \nfrequently called Deep Content Inspection and Sanitization (DCIS).  CDR/DCIS filters are 1778  \ntypically implemented in two parts:  1779  \n\u2022 Inspection  which e nsure s that the data conforms with data type\u2019s  specification . Inspection 1780  \nrelies on a robust understanding of syntactic structure and semantic meaning  of the 1781  \ncontent.  1782  \n\u2022 Sanitization , sometimes called \u201cWrit ing Out Known Good\u201d , removes  anything that 1783  \ncannot be filtered or verified to be safe  and if possible,  for the data type, randomiz es the 1784  \ninternal structure  (e.g., this is  commonly done in PDF files).  1785UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 69 of 397 Most  CDR/DCIS systems use recursion and decom position techniques to extract and filter the 1786  \nembed", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}157{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "156", "chunk": "ded content in the file. Complex documents (e.g., PDF and Microsoft  Office \u00ae) and 1787  \narchive file formats (e.g., Zip, tar) contain various embedded data types  or objects  (e.g., text, 1788  \nOLE objects, ActiveX\u00ae Controls, images, embedded executables) each of which must be 1789  \nextracted and filtered individually .  The d ecomposition process extracts objects and sends them 1790  \nto be filtered through the filtering pipeline . Recursion techniques are used to \u201cdrill down\u201d 1791  \nthrough the embedded objects to find all the objects that need to be filtered. Filters must set 1792  \nlimits on the amount of recursion to prevent resource exhaustion attacks  1793  \nCDR/DCIS can be used in all transfer ADPs ; however, ADP -3, ADP -4, and ADP -4 are 1794  \nspecifically optimized for CDR/DCIS techniques.  Use of this technique with ADP -6 is not 1795  \nrecommended  due to the complexities of rebuilding the file bit -for-bit the same with two 1796  \ndifferent implementations.  1797  \nPros  Cons  \nDoes not rely on signatures or knowledge of \nprevious attacks  Requires a bit/byte level understanding of the \nfile/protocol  \nResulting file usually very close to original \nwith minimal damage/changes  and usually \ndoes not result in loss of functionality of the \ndata type.  Speci ficat", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}158{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "157", "chunk": "ions frequently do not  match \nimplementations  though this has become less \nof a problem over the years  \nIt is the o nly reliable mechanism for valid text \nextraction for dirty /clean  word searching  for \ncomplex documents  Some data hiding and data disclosure analysis \nmay require internal \u201crendering\u201d of the file  \nImplements  syntactic, semantic, logical /policy \nenforcements concepts  Does not work with streaming content  \nFast and scalable especially if  the content is \nstored in memory instead of on disk   \nMultiple commercial FVEY vendors \nimplement robust CDR/DCIS engines   \nCan and frequently is  used in combination \nwith other techniques. For example, an \nextracted image from a Microsoft Word\u00ae \ndocument could be filtered using \nnormalization techniques and the n reinserted.   \n 1798UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 70 of 397 \n Format Conversion   1799  \nThis technique c onverts a file to another similar (usually simpler  and safer ) format before 1800  \nconverting it back to the original file format . A commonly implemented example of format 1801  \nconversation is the converting PDF", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}159{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "158", "chunk": " files to PostScript\u00ae back to PDF. This  is effective at 1802  \nstopping most PDF data attacks because PostScript is focused solely on printing and the  data 1803  \nattack concerns in PDF are simply not present  in PostScript\u00ae.  Some conversions like Office 1804  \nOpen XML ( OOXML ) to Open Document Format (ODF)  back  to OOXML are not sufficient ly 1805  \ndifferent to provide security  value. In this case, ODF and OOXML are nearly feature identical so 1806  \nmany issues  (especially data hiding, data disclosure and embedded content)  are common to both 1807  \nformats.   1808  \nData hiding and disclosure filtering must be done prior to the format conversion as some format 1809  \nconversion techniques modify content in ways that their detection after conversion is problematic  1810  \nor impossible.  1811  \nFormat conversion  filtering can be used with all transfer CDS ADPs.  Use of this technique with 1812  \nADP -6 is not recommended for complex document types  due to the complexities of rebuilding 1813  \nthe file bit -for-bit the same  with two different implementations . 1814  \n 1815  \nPros  Cons  \nCan disrup t malware by altering the file  Does not handle disclosure risks (can \nincrease)  \nCan remove unwanted or risky feature in the \nconversion process  Might disrupt functional", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}160{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "159", "chunk": "ity of the \nfile/protocol  \nCan remove hidden data when layers are \nremoved  Increases attack surface at the converter \napplication  \nVery effective against polyg lot attacks   \n 1816  \n Normalization/Canonicalization  1817  \nThis technique converts content from a specialized form to its standardized or raw for m.  This 1818  \ntechnique is widely used and effective for filtering fixed format data (e.g., military messaging), 1819  \nimages, audio,  and video. The normalization process can usually occur off the CDS and is 1820  \ngenerally not considered security relevant. This is due to the filtering subsystem\u2019s ability to filter 1821  \nthe normalized data. For example, an external system could convert a proprietary bitmap image 1822  \nformat on a Microsoft Window Server\u00ae (because the software only runs on Microsoft 1823  \nWindows\u00ae) to a raw bitmap.  The CDS woul d filter the  raw bitmap . If the conversion failed to 1824  \nfunction  correctly  on the Microsoft Windows Server\u00ae , the CDS image filters would fail or 1825UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 71 of 397 destroy the unconverted data.  1826 ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}161{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "160", "chunk": " \nHowever, the denormalization process may have to reside on the CDS for some data types. The 1827  \ndenormalization process is security relevant when it contribute s to either validation or loss 1828  \ninjection into the data type. Images, video, and audio are examples of data types where the 1829  \ndenormalization process is security relevant. For example, in video the canonical form  is image s 1830  \nper second  and for audio the canonical form can  be Pulse -Code Modulation (PCM ). While the 1831  \nindividual filters can valid ate the structure of the image or add loss (e.g., blurring or smoothing) 1832  \nto the pixel, the most effecti ve mechanism to reduce data attack is generation of a lossy 1833  \nH.264/H.265 stream.  1834  \nA widely used implementation of normalization for fixed format ASCII/ Unicode/binary file 1835  \ntypes is the used of Data Format Description Language with the Apache Daffodil\u00ae parser . The 1836  \nnormalized data format is usuall y XML.  1837  \nThis technique works well for data types and protocols  and usually in all CDS ADPs. It is 1838  \nespecially popular in ADP -2 and ADP -6. 1839  \n 1840  \nPros  Cons  \nThere is no loss of fidelity in the data during \nthe canonicalization process  By itself provides limited filtering value for \ndata hiding/discl", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}162{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "161", "chunk": "osure . \nCan be very effective for removing malware, \nmalware C2 communications, and data \nexfiltration  Only works if there is a canonical form of the \ndata.  \nCan be used as a protocol break   \nWorks very well for fixed format data, \nimagery, video, and audio   \nEffective  against polyg lot attacks   \n 1841  \n Flattening  1842  \n This filtering technique converts a data type or protocol to a different  and less complex data type 1843  \nor protocol. For data types, the flattening technique usually involves rendering the original 1844  \ncontent into a presentation format.  For example, a Microsoft PowerPoint\u00ae file can be flattened 1845  \ninto a series of bitmap images (e.g., PNG or JPEG). Flattening is very useful  in environment s 1846  \nwhere data is coming from a known dirty and unsafe network and the recipient of the data just 1847  \nneeds to view the content and not modify it. It is rarely used on CDS themselves due to frequent 1848  \nneed to use t he source application (e.g., Microsoft PowerPoint in the above example), but it is 1849UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 72 of 397 occasionally", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}163{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "162", "chunk": " used on devices around the CDS to prepare the files for transfer though the CDS.  1850  \nThis technique works well for data types and protocols and usually in all CDS A DPs. Use of this 1851  \ntechnique with ADP -6 is not recommended for complex document types due to the complexities 1852  \nof generating the flattened  file bit -for-bit the same  with two different implementations.  1853  \n 1854  \nPros  Cons  \nVery e ffective in removing data attacks  \nespecially if the less complex data \ntype/protocol is also filtered  Not effective  for detecting or eliminating data \ndisclosure  risks  \nCan reduce  some  data hiding risks  (by \nremoving layers)  The conversion m ay require using vendor \nlibraries or complex applic ations that are \ndifficult to verify  \nVery effective against polyg lot attacks  High probability the resulting data \ntype/protocol will differ in some content and \nwith major reduction in functionality from the \noriginal data type /protocol  \n Converting back to the original format usually \nis usually  impossible  \n 1855  \n7.5.7  Why does filtering work?  1856  \nSome of the  reason s why content filtering is effective are:  1857  \n1. Malware is fragile. Most malware techniques rely on a specific set of conditions like a 1858  \nspecific operating system version, CPU ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}164{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "163", "chunk": "architecture, and application version. Just like 1859  \nchanges in environment can cause the malware to fail , changes in the structure and 1860  \ncontents of a data type can have a similar effect i n causing the malware to fail to activate. 1861  \nThe changes  from filtering can result in the initial phase of the exploit (e.g., macros, shell 1862  \ncode) not activating, the malware payload being corrupted or removed, or both.  1863  \n2. File-based malware tends to misrepresen t itself  (e.g., claims to be one type when it is 1864  \nreally a different type) . Filtering can detect that the file is not what it claims to be  then 1865  \neither  fail it or sufficiently mutilate it in such a way that the malware is not executable.  1866  \nExcept for the signa ture/heuristic techniques, filtering will detect that the file is not what 1867  \nit appears to be.  1868  \n3. Malware exploits defects in parsing, usually by providing a syntactically, semantically, 1869  \nand logically wrong content. Filtering will either fail the malformed cont ent to correct it 1870UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 73 of 39", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}165{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "164", "chunk": "7 thus reducing the likelihood of a shell code execution.  1871  \n4. Malware developers like to hide payload in portions of files used for metadata storage, at 1872  \nthe end of the file, between segments/markers in a file, and via steganographic techniques 1873  \nin the data area of files . Techniques like extracting embedded content and filtering it, 1874  \nrebuilding the file based on \u201cknown good\u201d, or converting to another data type either 1875  \neliminates or sufficiently modifies the embedded content to make it unrecoverable.   1876  \n5. Any information in illegal locations will be removed . 1877  \n6. Alteration of content may disrupt covert channels . 1878  \n7. Sanitizing or removing unnecessary fields will remove data that is not usually seen  by 1879  \nreviewers.  1880  \n8 CDS Design Patterns : Overview and Requirements  1881  \nThis section covers the design patterns for Transfer and Access CDS. A design pattern is a 1882  \ngeneral, reusable solution to a design or engineering problem. It is not a finished design but 1883  \nrather the core architectur al structure and, thus, may be missing supporti ng components and 1884  \nsystems.  In the context of software, a design  pattern is not sufficient to be transformed directly 1885  \ninto source code.68 1886  \nThis section cov", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}166{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "165", "chunk": "ers unacceptable and acceptable design patterns for the various types of CDS. 1887  \nSpecific instances of CDS implementations may vary from the design patterns in this docume nt. 1888  \nThe purpose of the patterns is to explain core concepts. Some deviation from the acceptable 1889  \npatterns, if implemented properly and with good rationale, may be acceptable.  1890  \n8.1 Introduction to Design Pattern Drawing s 1891  \nMost diagrams in this section  are showing  a two domain, bidirectional  CDS. The design patterns, 1892  \nconcepts, and pros/cons  also apply to a multi -domain configuration ( e.g., three or more 1893  \ndomains) . Specific guidance is given for multi -domain configurations when applicable.  1894  \nThe following information is provided to aid with understanding the diagrams : 1895  \n\u2022 Lines are used to indicate the transfer of data with in or to a system : 1896  \no Solid \u2013 If the system is a single box solution , then  the lines usually represent an 1897  \nInter -Proce ss Communication (IPC) mec hanism which includes internal file 1898  \ntransfer via the file system.  1899  \no Dashed/Dotted \u2013 If the system is a multi -box solution , then the lines usually 1900  \nrepresent a network connection ( e.g., either physical or virtualized inside a 1901  \nhypervisor) . 190", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}167{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "166", "chunk": "2  \n\u2022 Arrows indicate the d irection of the data flow either bidirectional  or one -way.  1903  \n \n68 See https://en.wikipedia.org/wiki/Software_design_pattern  and https://en.wikipedia.org/wiki/Design_patternUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 74 of 397 \u2022 Blue boxes indicate separate processes  (e.g., an instance of a computer  program that is 1904  \nbeing executed)  and functions . 1905  \n\u2022 Orange boxes indicate functions (possibly as threads)  within a process.  If the re is a single 1906  \nfunction in a process,  then only a blue box will be used.  1907  \n\u2022 Red and green boxes indicate High and Low, respectively, physical/virtual network 1908  \ninterfaces ( e.g., Ethernet, RS -232/422, USB, etc .). 1909  \n\u2022 Purple boxes indicate a physical or virtualized system ( e.g., server) . 1910  \n\u2022 The light brown/olive \u201ccan\u201d represent  the IPC mechanism and also includes file transfer 1911  \nvia filesystem.  1912  \n\u2022 Design Pattern diagrams  should not be considered a \u201ccomplete\u201d system.  1913  \no They are used to descr ibe data flow and architectural concepts ; they are  not all - 1914  \ninclusive.  19", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}168{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "167", "chunk": "15  \no They are also missing the audit /loggin g infrastructure, the C2 messaging system 1916  \nto control the system, error handling, monitoring/management, and/or other 1917  \nsubsystems necessary to build a production system.  1918  \n8.2 Unacceptable Design Patterns  (UDP)  1919  \nThis section describes the unacceptable design and de ployment patterns that have been used in 1920  \nprevious generations of CDS. The UDP s implement one or  more of the following unacceptable 1921  \ndesign pattern concepts (UDPC):  1922  \nUDP C-1: Any mistake in the process\u2019 code could result in a complete fail open situation for the 1923  \nCDS.  1924  \nUDP C-2: Due to the single process implementation, MAC and DAC enforcement  is ineffective.  1925  \nUDP C-3: Unidirectional  flow cannot be enforced, which enables exfiltration off the CDS of 1926  \ncode and c onfiguration (which can, in turn, be used for further exploit development).  1927  \nUDPC -4: There is no guarantee that, if there are redundant and independent filters, they will get 1928  \ninvoked.  1929  \nUDP C-5:  A programming logic mistake or faulty configuration file could cause the FOE to 1930  \nsend data to inappropriate filters or no filters at all, resulting in fail open conditions or conditions 1931  \nwhere data is not inspected.  1", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}169{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "168", "chunk": "932UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 75 of 397 \n UDP-1: The Single Process Guard  1933  \n 1934  \nFigure  2 \u2013 UDP-1: The Single Process Guard  1935  \nIn this pattern, which presents the  worst  possible  implementation , all functions of the CDS are 1936  \ncontained in a single process. Poor p rogramming logic, memory management, or protocol/data  1937  \nparsing can easily lead to a fault in the code and possibly malicious code execution. Because the 1938  \nprocess has access to both network interfaces, any failure that results in a fail open condition  for 1939  \nthe filters or malicious code execution will essentially turn the CDS into an open pipe. 1940  \nMAC/DAC enforcement including  SELinux , SECCOMP69, MLS, etc. will not prevent an attack 1941  \nor the fail open condition since the process already has access to all the resource s it needs ( i.e., 1942  \nthe network interfaces) to transfer data through the system . Additionally, since the protocol 1943  \nadapters  (PA) , filters, and filter orchestration engine  (FOE)  are all contained within the same 1944  \nprocess , an attacker could ex", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}170{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "169", "chunk": "filtrate all the process\u2019s code  and state , its configuration, and 1945  \npossibly other system files if the attacker is able to execut e arbitrary code. A compromise of the 1946  \nprocess would allow bidirectional  communications between all domains connected to the CD S. 1947  \nThis pattern exhibits all the UDPCs.  1948  \n 1949  \n UDP-2: The Nearly Single Process Guard  1950  \n 1951  \nFigure 3 \u2013 UDP-2: The Nearly Single Process Guard  1952  \nThis design pattern is essentially the same design as UDP -1, except the P as are separated into  1953  \nindividual processes. Even with this modification, any failure in a filter or the FOE could result 1954  \n \n69 SECCOMP or Secur e Computing Mode is a mechanism in the Linux\u00ae kernel to restrict which system calls \n(SYSCALL) an application can run. See https://en.wikipedia.org/wiki/SeccompUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 76 of 397 in a fail open situation and thus  an open pipe through the CDS. This pattern exhibits all the 1955  \nUDPCs . 1956  \n UDP-3 The \u201cStar\u201d Guard  1957  \n 1958  \nFigure 4 \u2013 UDP-3: The \u201cStar\u201d Guard  1959  \nThis pattern separates ou", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}171{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "170", "chunk": "t the P as, filters, and FOE into separate processes . It has also been 1960  \ncalled the \u201chub -and-spoke\u201d  pattern.  Hence,  a single process fault, except in the FOE, would not 1961  \nlikely result in  a complete fail open condition if there is redun dant and independent filtering , 1962  \nwhich , based on experience is rarely seen in this pattern . However, a logic mistake due to poor 1963  \nprogramming or a faulty configuration file can cause the FOE to impr operly route data through 1964  \nfilters and thus result in  a fail open situation. Also, if the FOE parses the data, instead of just 1965  \nmoving it between filters, then memory management and parsing attacks apply. This pattern does 1966  \nnot support using MAC and DAC to en force the non-bypassability and always invoked aspects  1967  \nof RAIN. There is no architectural mechanism to ensure filters get invoked.  This pattern exhibits 1968  \nUDPC -1 (if in the FOE), UDPC -2, UDPC -4, and UDPC -5. 1969  \n 1970UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 77 of 397 \n UDP -4 Cascading of CDS  1971  \n 1972  \nFigure 5 \u2013 UDP-4 Cascading of CD S  1973  ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}172{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "171", "chunk": "\nThis design pattern is focused on a CDS deployment pattern (i.e., the deployment architecture \u2014 1974  \nplacement and number of CDSs in the mission environment), not the internal implementation of a 1975  \nspecific CDS . In the cascading UDP,  two identical CDS are placed in series to transfer information 1976  \nacross mult iple different security domains.  This pattern is not acceptable because a  single  design or 1977  \nimplementation flaw or misconfiguration in the first CDS will also exist in the second CDS and 1978  \ntherefore an attac ker would be able to launch a cascaded attack that would : 1979  \n1. Give the attacke r access  (potentially bidirectional  if a software CDS) to HIGH from LOW  1980  \n2. Expose all domains to malware ingestion, malware C2, exfiltration of dat a and denial of 1981  \nservice attacks .  1982  \nIf the UDPCs are modified slightly such that \u201cprocess\u201d is changed to CDS and CDS is changed 1983  \nto \u201cCDS Deployment architecture\u201d, this pattern exhibits UDPC -1, UDPC -2, and UDPC -3. This 1984  \npattern is not acceptable even if it is only implemented in unidirectional man ner. 1985  \n 1986UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}173{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "172", "chunk": "BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 78 of 397 \n UDP -5 Chaining of CDS  1987  \n 1988  \nFigure 6 \u2013 UDP-5 Chaining of CDS  1989  \n 1990  \nSimilar to UDP -4, this design pattern is focused on a CDS deployment pattern not the 1991  \nimplementation of a specific CDS.  In the chaining UDP, two different CDS on different operating 1992  \nsystems are placed  in series to transfer information across multiple security domains.  This design 1993  \npattern increases the adversary\u2019s work factor because the adversary must find and exploit flaws, 1994  \nweaknesses or misconfigurations in different CDS technologies and defeat the policy enforcement 1995  \nmechanisms (e.g., protocol break) between the CDSs to ga in access to all domains. UDP -5 is a 1996  \ntherefore a better design pattern than UDP -4. As a practical matter, however, achieving the 1997  \nrequired operating system diversity is difficult since most CDS are running on the same 1998  \noperating system. Furthermore, implemen tations using this pattern are generally reliant on:  1999  \n1. Low trust commodity hardware (e.g., x86 -based servers) and  2000  \n2. Extensive use of shared software within the CDS (e.g., open source/closed source 2001  \nfiltering libraries;  open source support libraries [e.g., GNU L ibC])", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}174{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "173", "chunk": ".  2002  \nAs a result, there are simply too many opportunities for a single class of attack to compromise 2003  \nboth CDS . This pattern shall not  be used between Unclassified Networks or High Threat Networks  2004  \nand USG classified NSS.   2005UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 79 of 397 \n UDP -6 Switch or Server connecting Diodes  2006  \n 2007  \nFigure 7 \u2013 UDP-6 Switch or Server connecting Diodes  2008  \nThe use of a switch or server to connect the high side s of two or more pitcher /diode /catcher 2009  \nsolutions that are not an RTB compliant CDS is not allowed. If the switch or server is 2010  \ncompromised, then it would allow bidirectional  communications to the low side. This 2011  \nbidirectional  communication  would provide  a staging environment for an attack against the 2012  \nsoftware CDS.  The high side of the non -RTB compliant diode solutions must be separated and 2013  \nmust not be connected except via software CDS.  2014  \n8.3 Acceptable Design Patterns  (ADP)  2015  \n8.3.1  Transfer CDS Design Patterns  and Requi rements  2016  \nThis section covers the acc eptable CDS design", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}175{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "174", "chunk": " patterns. It provides requirements on h ow the 2017  \nADP will be implemented.  The ADP s do not cover all aspects of the CDS  implementation ; the 2018  \ndesign s are intended to convey architectural concepts. Some variat ion from the ADP is allowed 2019  \nso long as the design intent i s followed.  Variations from the ADP should be discussed with the 2020  \nNSA prior to implementation.  2021  \nThe below table provides guidance  on which types of data are recommended for which 2022  \nacceptable design pat terns.  Variations are allowed.  2023  \n 2024  \nDesign Pattern  Recommend ed Applicable Data Types  \nADP -1: The \u201cDouble Star\u201d Guard  DEPRECATED  \nADP -2: Multiple Domain Linear Assured Fixed Format DataUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 80 of 397 Pipeline  Streaming Data Flows (Fixed Format, Video, \nAudio, Modeling and Simulation information)  \nCan be used  for Complex Document Data but it \nis not an optimal architecture for that type of \ndata.  \nADP -3: Recursive Decomposition Pipeline  Fixed Format Data  \nComplex Document Data  \nADP -4: Redundant Recursive \nDecompositi on Pipelines  Fixed ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}176{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "175", "chunk": "Format Data  \nComplex Document Data  \nADP -5: Alternative Recursive \nDecomposition Pipeline  Fixed Format Data  \nComplex Document Data  \nADP -6: Linear Assured Pipeline with \nComparators  Fixed Format Data  \nStreaming Data Flows (Fixed Format, Video, \nAudio, Modeling and Simulation information)  \nFigure 8 \u2013 Recommend Data Pattern/Data Type Mapping  2025  \n 2026  \n ADP -1: The \u201cDouble Star\u201d Guard  \u2013 DEPR ECATED  2027  \nThis ADP has been deprecated and is no longer allowed to be used for any CDS entering 2028  \nthe LBSA process. It was put in the original RTB v1.0 to help legacy CDS migrate to RTB 2029  \nfaster. There are no RTB compliant CDS that ever used this pattern, and it is now 2030  \nconsidered obsolete.  2031  \n 2032  \n 2033  \nFigure 9 \u2013 ADP-1 The \u201cDouble Star \u201d Guard  2034  \nThis pattern combines two \u201cstar guard  patterns \u201d with independent implementations as well as 2035UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 81 of 397 filter report validators to cryptographically verify that all filters have been traversed before 2036  \nreleasing transferred information.  This pattern has the same attack ri", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}177{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "176", "chunk": "sk and core issues as the 2037  \nUDP -3 pattern if FOE1 and FOE2 are the same implementation. When  FOE2 has an independent 2038  \nimplementation along with independent and redundant filters from FOE1 then this pattern 2039  \npotentially could be acceptable.  However, acceptability also depends on whether other 2040  \nmechanism s are implemented to ensure the non -bypassability and always invoked aspects  of 2041  \nRAIN, since MAC and DAC cannot be fully leveraged to ensure filters get invoked. The 2042  \npreferred mech anism to address non -bypassability and always invoked in this pattern is the use 2043  \nof digitally signed filter reports by each filter and redundant and independent validation of the 2044  \nfilter reports both in the FOEs and in the Filter Report Validators . This pattern is usually used  for 2045  \nprocessing complex documents such as Microsoft Offic e\u00ae, PDF, images, and container /archive 2046  \nformats ( e.g., zip, tar ) that are not latency sensitive.  This design pattern is acceptable;  however,  2047  \nimplementation must address additional risks:  2048  \n\u2022 FOE1 and FOE2 must have different implementations (to avoid UDPC -1) 2049  \n\u2022 Filter Report  Validators must be implemented  (to avoid UDPC -4 and UDPC -5) 2050  \nWhile feasible, the use of this patte", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}178{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "177", "chunk": "rn is discouraged due to the added implementation complexity 2051  \nand therefore technical risk . 2052UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 82 of 397 \n ADP -2: Multiple Domain  Linear Assured Pipeline  2053  \n 2054  \nFigure 10 \u2013 ADP-2: Multiple Domain Linear Assured Pipeline  2055  \nThis pattern is a multi -domain version of the classic70 linear assured pipeline71 design pattern and 2056  \nfully implements all RAIN design concepts.  By design, the pattern has the appropriate 2057  \nmechanisms in place to counter the negative outcomes of the UDPCs. It also supports point -to- 2058  \npoint and point -to-multipoint transfers.  This is the primary  transfer CDS design pattern for high 2059  \nthroughput , low latency systems. It is frequently used for cross -domain transfers such as  military 2060  \nC2 messaging, video/audio streaming ( e.g., VTC and UAV), modeling an d simulation data, 2061  \nimagery, XML, and JSON  web s ervices. The outbound pipeline is the series of filters from the 2062  \norigin domain and the inbound pipeline is the series of filters into the destination domain. The 2063  \nDomain", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}179{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "178", "chunk": " Router (DR) inspects the metadata about the object, validates the filter reports (if 2064  \nenabled for that implementation),  then routes the content to one  (called a point -to-point transfer) 2065  \nor more (called a point -to-multipoint transfer, also called fan -out, and copy is created for each 2066  \ndestination domain ) domains based  on the metadata and filter  policy. In a multi -point scenario, 2067  \nthe same filter policy is used for each destination  domain. If a different policy is required for 2068  \n \n70 The classic assured pipeline is not presented here since it is a two domain solution and rarel y implemented. If a \ntwo domain solution is required then, remove the domain router and put the second set of filters inline with the first.  \n71 See Boebert, W. E., Kain, R. Y., \"A Practical Alternative to Hierarchical Integrity Policies.\" Proceedings of the \n8th Annual National Computer Security C onference, NBS, 1985, pp. 18 -27. \nhttps://csrc.nist.gov/CSRC/media/Publications/conference -paper/1985/09/30/proceedings -8th-national -computer -\nsecurity -conference -1985/documents/1985 -8th-NCSC -proceedings.pdfUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}180{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "179", "chunk": "ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 83 of 397 each destination domain, then the message should be copied at the protocol adapter and sent 2069  \nmultiple times through the pip eline so that different filter policies can be used. If the pipeline 2070  \npattern sufficiently ensures a linear flow non-bypassability, redundancy, and independence then 2071  \nfilter report validation may not be necessary \u2013 however for complex data types filter repor ts are 2072  \nrequired  since they can be used by users or administrators to determine why content failed.  2073  \nSome CDS implement separate  inbound/outbound assured pipelines for each data flow (or 2074  \ncustomer ) and others implement a single inbound/outbound assured pipeline for each domain. In 2075  \nthe latter use case, the individual processes  are typically  threaded72. It is strongly recommended 2076  \nthat if threading is used, that each data flow has its own thread and that the CDS does not process 2077  \ncontent for a single data flow in multiple threads  so that risks to data integrity inherent in multi - 2078  \nthreading architectures (like out -of-order delivery) are avoided .  2079  \nOn SELinux based systems, type enforcement policies and DAC permissions are used to enforce  2080  \nlinear flow w", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}181{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "180", "chunk": "ithin the pipeline. Also, the IPC  mechanism s used are one -way ( e.g., Queues, 2081  \nNamed Pipes, Si gnals, Queue/Shared Memory combination ). If bidirectional  IPC mechanisms  2082  \nare used ( e.g., TCP/IP or UDP/IP), then it may be possible  to exfiltrate data  from the filters, in a 2083  \nmanner similar to the problem in the Single Process pattern  (UDP -1). As such, bidirectional  IPC 2084  \nmechanism s are not allowed. Multi -Category Security (MCS) policy is used to separate multiple 2085  \ninstances of pipelines and their associate d type enforcement policies. Essentially, each domain 2086  \ngets one  or more unique categories and only the DR process is authorized to transfer data to an 2087  \nIPC in a different category. The type enforcement policy for each pipeline is the same for all the 2088  \ndomains , but because each instantiation of the policy is in its own category and has separate 2089  \nDAC permission, there is no risk of one domain\u2019s processes communicating with another 2090  \ndomain\u2019s processes except via authorized means ( e.g., the DR).  2091  \nIn the  Multiple Doma in Linear Assured Pipeline design pattern, for the data types that can be 2092  \nprecisely and consistently validated ( e.g., Fixed Format, XML/JSON, v ideo, audio, and some 2093  \nimagery),", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}182{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "181", "chunk": " if content fails in a filter in the  inbound pipeline, it will cause th e origin and 2094  \ndestination  domain  pipelines  to be shut down. The pipelines  are shut down because the inbound 2095  \npipeline should never get bad data and that  would indicate that  one or more of the filters in the 2096  \noutbound pipeline failed open.  However, for data typ es like Microsoft Office\u00ae  and PDF, where 2097  \nparsing is substantially more complex and variable due to inconsistencies in  the understanding  2098  \nand implementation  of the specifications by both filter developers and content application 2099  \ndevelopers  (e.g., Microsoft O ffice\u00ae  2016 vs. LibreOffice \u00ae 6), then automatically shutting down 2100  \nthe pipelines if content fails in the inbound pipeline would likely result in too many operational 2101  \nproblems. If a filter fails content in the outbound pipeline, the content is dropped and op tionally 2102  \njournaled. An outbound pipeline sh ould be shutdown if the number of failed message s per unit of 2103  \ntime is exceeded.  However, if a filter crashes in any pipeline, it must result in a pipeline 2104  \nshutdown. Filters must report all filtering results to the  Central Audit and Logging Daemon 2105  \n(CALD) so that the Event Management/Policy Enforcement processe", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}183{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "182", "chunk": "s can take corrective action. 2106  \n \n72 https://e n.wikipedia.org/wiki/Thread_(computing)#MultithreadingUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 84 of 397 See the Journaling, Auditing and Logging Subsystem Requirements in  Section  10.12 . 2107  \n ADP -3: Recursive Decomposition Pipeline  2108  \n 2109  \nFigure 11 \u2013 ADP-3a: Recursive Decomposition Pipeline  2110  \n 2111  \n 2112  \nFigure 12 \u2013 ADP-3b Multi -Domain Recursive Decomposition Pipeline  2113  \n 2114  \nThe ADP -3a and 3b pattern s are primar ily used to process complex documents such as Microsoft 2115UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 85 of 397 Office\u00ae , PDF, images, and container /archive formats ( e.g., zip, tar ). Like the previous ADP, this 2116  \ndesign p attern has the appropriate mechanisms in place to counter the negative outcomes of the 2117  \nUDPCs. Complex document data types typically contain multiple data types internally and are 2118  \noften fo", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}184{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "183", "chunk": "und inside other complex document types. For example, a Microsoft Off ice\u00ae  Word 2119  \ndocument can contain Microsoft Office\u00ae  PowerPoint \u00ae slides which, in turn, can contain JPEG 2120  \nimages which can contain XML based metadata.  It is the responsibility of the filters to extract 2121  \nembedded content, send it to the results processors as artifacts so that it can then be sent to the 2122  \njob scheduler for transfer to the appropriate filters for processing. The use of a recursive 2123  \ndecompositi on assured pipeline is ideally suited to address data types that contain an unknown 2124  \ndepth and type of embedded content. While it is possible to filter these types in a traditional 2125  \nlinear assured pipeline design, the lack of a recursive architecture makes p roper embedded object 2126  \nextraction and filtering very complex, which usually results  in insufficient and unsafe filtering 2127  \nbecause the filters tend to be overloaded in functionality to address the lack of a recursive 2128  \nfiltering architecture.  2129  \nIn these pattern s, each filter generates a digitally signed filter report that contain s the actions 2130  \nperformed, the results, the hashes of the original and filtered content, original and new filenames, 2131  \nand other metadata as required. T", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}185{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "184", "chunk": "he Results processor collects the filte r reports and combines 2132  \nthem into a single report for the content. This includes the reports of all embedded content 2133  \n(called artifacts). If the filter reports indicate an artifact failed filtering,  then the filter report is 2134  \nsent to the filter system that is  holding the artifact\u2019s parent file. That filter would then do one of 2135  \nthe following: fail the parent file, remove the failed embedded content and rebuild the file with 2136  \nonly successfully filtered content , or replace the failed embedded content with a placeh older and 2137  \nrebuild the parent file.  Either the results processor or the filter can send the failed content to the 2138  \nJournaling, Auditing, and Logging (JAL) subsystem via the Central Journal Daemon ( CJD) for 2139  \nquarantine. Both the results processor and the filte rs send filter reports to the JAL subsystem for 2140  \nstatistical and policy enforcement processing.  The results processor, while validating the final 2141  \nfilter report, verifies the right policy was used, the right filters were invoked, the content passed, 2142  \nand tha t it has the correct files. It then sends the filtered content and filter  reports to a redundant 2143  \nand independently implemented Filter Report Va", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}186{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "185", "chunk": "lidator  (FRV)  to repeat the same checks.  2144  \nIn the ADP -3a only a single FRV instance is used in each domain since it is a two -domain 2145  \nsystem  and only a single destination is possible  for a given flow . However , ADP -3b is a n n- 2146  \ndomain version and a second independent  FRV instance used in each receiving domain to verify 2147  \nthat the conten t is intended for that domain. Multi -domain versions of ADP -5 would look similar 2148  \nto ADP -3b and would have a second independent FRV instance  in each receiving domain.  2149  \nThis architecture ensures that  all content will be  filtered at least once73 however;  the R esults 2150  \nProcess or and Filter Report Validator  will ensure that all content has successfully been filtered at 2151  \nleast twice and that the correct filters were used for the identified data types. This enforces the 2152  \n \n73 Meaning at least one filter is invoked for every file received.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 86 of 397 non-bypassability and always invoked requirement s. In multiple domain CDS  (3 or more 2153  \ndomains) , there is a DR", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}187{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "186", "chunk": " between the Results Processor and the Filter Report Validator.  2154  \nOn SELinux based systems, type enforcement policies and DAC permissions are used to enforce 2155  \nlinear flow within the pipeline. Also, the IPC  mechanism s used are one -way (e.g., Queues, 2156  \nNamed Pipes, Signals, Queue/Shared Memory combination ). File copies, not moves, are  2157  \ntypically  used to transfer large files (>2GB) and traditional IPC  mechanism s are used for small 2158  \nfiles, notifications , and metadata transfers.  On Linux \u00ae, a file move is not considered safe 2159  \nbecause SE Linux cannot revoke access to memory  mapped files  however  the STOP \u2122 operating 2160  \nsystem  does not have this limitation74. On all operating systems, i f bidirectional  IPC mechanism s 2161  \nare used ( e.g., TCP/IP or UDP/IP) , then it is potentially possible to exfiltrate data from filters in a 2162  \nmanner similar to the problem in Single Process pattern  (UDP -1); therefore, bidirectional  IPC 2163  \nmechanism s are not allowed.  2164  \nThis design pattern is not appropriate for streaming data transfers, low latency transfers, or 2165  \ntransfers that require in -order delivery.  2166  \nIn the multiple domain variant of this pattern, the Domain Router is placed after the FRV and a 2167  \nsecond in", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}188{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "187", "chunk": "dependent FRV is placed in line after the Domain Router.  2168  \n 2169  \n ADP -4: Redundant Recursive Decomposition Pipelines  2170  \n 2171  \nFigure 13 \u2013 ADP-4: Redundant Recursive Decomposition Pipeline  2172  \nThis pattern is an expanded version of the Recursive Decomposition  Pipeline; therefore, it has 2173  \nthe appropriate mechanisms in place to counter the negative outcomes of the UDPCs. However, 2174  \nit differs in one key area; instead of having redundant and independent filter report validators, 2175  \nthis pattern implements a second comp letely redundant and independent re cursive decomposition 2176  \n \n74 Changes to RHEL\u00ae 7.5 kernel and higher have a resolve issue with memory map files that make moves unsafe. \nThere are also some proprie tary move implementations that have also been tested to be sufficiently safe to use in a \nCDS.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 87 of 397 pipeline. Independent f ilter report validation is implemented  in the two independent Results 2177  \nProcessors. In multiple domain versions , the DR sits between the first Results Process or and the 2178  \nsec", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}189{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "188", "chunk": "ond J ob Scheduler. The DR validates the job metadata, that the appropriate  filter policy was 2179  \nused for the source -destination domain pair , and that it has the correct data prior to sending the 2180  \ndata to the second pipeline.  Due to the second recursive decomposition pipeline , this approach is 2181  \nmore robust and secure than ADP -3. In some variations of the ADP -4 design pattern , the second 2182  \nFOE is the same implementation as the first , but the filters are independent  and an independent 2183  \nfilter report validator i s used.  2184  \nThis design pattern is not appropriate for streaming data transfers, low latency transfers, or 2185  \ntransfers that require in -order delivery.  2186  \nIn the multiple domain variant of this pattern, the Domain Router is placed after each Results 2187  \nProcessor1 and b efore Job Scheduler2.  The second  independent recursive decomposition 2188  \npipeline is also responsible for ensuring the content is filtered with the appropropriate filter 2189  \npolicy for the destination domain.  2190  \n 2191  \n ADP -5: Alternative Recursive Decomp osition  Pipeline  2192  \n 2193  \nFigure 14 \u2013 ADP-5: Alternative Recursive Decomposition Pipeline  2194  \nThis pattern is a variant of the Recursive Decomposition Pipeline. Like the other R", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}190{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "189", "chunk": "ecursive 2195  \nDecomposition Pipeline patterns, this one has the appropriate mechanisms in place to counter the 2196UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 88 of 397 negative outcomes of the UDPCs. In this variation the Job Scheduler  is broken into two 2197  \nredundant and independent processes, the Dynamic Router and Operations Evaluator. After 2198  \ncontent  is submitted to the Workflow Selector for file typing the Dynamic Router is invoked. 2199  \nThe Dynamic Router sends content  to filters, collects r esults, then sends content  to the next stage 2200  \nof the filter pipeline. Unlike the Dynamic Router, the Operations Evaluator never gets any 2201  \ncontent , reducing its threat surface. Instead, the Operations Evaluator receives the hash of the 2202  \ndata that was sent  into and out of each filter in the pipeline along with the filter\u2019s pass or fail 2203  \ndecision. The resulting hash chain is used to check the validity of the Dynamic Router\u2019s routing 2204  \ndecisions, assuring that the Dynamic Router was not compromised and the content  visited each 2205  \nfilter in the policy. Once conten", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}191{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "190", "chunk": "t  has finished traversing its pipeline the results collected by the 2206  \nDynamic R outer and Operations Evaluator  are combined in the Landing Zone. The content and 2207  \nfilter reports are then sent to a filter report valida tor for final validation . Failed content is sent to 2208  \nthe Fail Landing Zone so it can either be  delete d or sent  to the CJD,  but it may not move it on to 2209  \nthe rest of the system.  2210  \nThis design pattern is not appropriate for streaming data transfers, low latency transfers, or 2211  \ntransfers that require in -order delivery.  2212  \nIn the multiple domain variant of this pattern, the Domain Router is placed after the FRV and a 2213  \nsecond independent FRV  is placed inline after the Domain Router.  See ADP -3b. 2214  \n ADP -6: Linear Assured Pipeline with Compa rator s 2215  \n 2216  \nFigure 15 \u2013 ADP-6: Linear Assured Pipeline  with Comparators  2217  \nThis is a specialized version of ADP -2. This design pattern is intended for use in CDS with high 2218  \nthroughput (e.g., thousands  of messages per second) and extremely low latency (e.g., < 10ms) . 2219  \nEach Filter has two independent implementations that run in parallel  and wi th a comparator after 2220UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KO", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}192{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "191", "chunk": "R, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 89 of 397 the two filter implementations. The comparator validates  if output of the two filters match. If the 2221  \noutput from the two implementations does not match,  then the content fails. The comparator is 2222  \ncomparing a bitstream  \u2013 essentially a by te for byte comparison  of the two input streams.  Since 2223  \nthe comparator has no knowledge of the type or structure of the data its attack surface should be 2224  \nextremely low.  2225  \nIn the drawing above, the outbound pipeline is using a single comparator . This assumes that the 2226  \ntwo linear filter pipelines that feed into it are deterministic, result in the same output, and can 2227  \nmaintain time synchronization. The inbound pipeline is using a separate compar ator for each 2228  \nfilter \u2013 this approach is useful when ma intain ing time synchronization across multiple filters in a 2229  \npipeline is not practical ( e.g., reliable).   However, both approaches are equivalent from a security 2230  \nperspective.  2231  \nThis design pattern only works for data types for which the filter actions are deterministic given 2232  \nthe same input and filter policy.  This work", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}193{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "192", "chunk": "s very well for fixed format, XML, and similar data 2233  \ntypes  that have well defined specifications  and where the \u2018how and what \u2019 of the filter actions can 2234  \nbe consistently implem ented by independent de velopers . It does not work well for data types that 2235  \nhave ambiguous specifications  (e.g., Microsoft Office\u00ae ),  anytime that a filter action for a data 2236  \ntype can be addressed by more than one transform , data types where  the how (not the what) to 2237  \naddress an issue cannot be precisely or consistently defined75,  and filters that implement 2238  \nrandomization ( e.g., using random values for the high/low frequencies for a bandpass filter, 2239  \nrandom values for least -significant bit modifications in an image filter,  random v alues for how 2240  \nmuch to recompress a JPEG, etc.) . Essentially comparators only work when the filtering actions 2241  \ncan be precisely defined including what the internal structural (for the output file) changes  of the 2242  \nfiltering actions will be and that the implementation have  a similar time to execution.  2243  \nA multiple domain version of this pattern would use the same domain router approach used in 2244  \nADP -2 and would include redundant and independent filters and compa rators in the receiving 2245  \ndo", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}194{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "193", "chunk": "mains.  2246  \n8.3.2  Access CDS Design Patterns  and Requirements  2247  \nAccess CDS can be implemented using different architectures:  2248  \n1) Virtual Machine (VM) Based, which can be used for both desktop and server variants of 2249  \nAccess CDS.  2250  \n2) Remote Virtual Desk top Infrastructure (VDI), which is used in the server variant of 2251  \nAccess CDS.  2252  \nAccess CDS are primarily used for desktop reduction which reduces the number of Personal 2253  \nComputers and sometimes networking at a user\u2019s desk. There are multiple variations on thes e 2254  \ntwo categories of Access CDS including hybrids that combine both. The sections below provide 2255  \n \n75 For example, for Microsoft Office\u00ae, a filter action could be to remove tracked changes (i.e. the what) from a \ndocument, but how to do that has not been precisel y defined.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 90 of 397 an overview of the acceptable design patterns for Access solutions.  2256  \n 2257  \n ADP -7: Virtual Machine Based Access CDS  2258  \n 2259  \nFigure 16 \u2013 ADP-7: Virtual Machine Based Access  CDS 2260  \nVirtual Machine b", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}195{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "194", "chunk": "ased Access CDS leverage a concept called Virtualization. Virtualization is the 2261  \nexecution of a \u201cguest\u201d OS on top of an OS called a hypervisor (or virtual machine monitor, 2262  \nVMM).  In virtualization, the guest OS is abstracted from the underlying hardware . There are two 2263  \ntypes of hypervisors:  2264  \n1. Type 1 Hypervisor76  - Runs  on bare metal (i.e. , directly on the hardware). This is the 2265  \nmost efficient form of virtualization and has the lowest attack surface.  2266  \n2. Type 2 Hypervisor77  - Runs on top of an OS (e.g., Linux \u00ae, Solaris\u00ae ). 2267  \nThe Virtual Machine (VM) is  the guest OS78 that is running on the hypervisor . 2268  \nThe three core functions that must be implemented in a Virtual Machine based Access CDS are:  2269  \n1. Process (Virtual Machine) Separation  2270  \n2. Network Separation  2271  \n \n76 Examples include VMware ESXi\u00ae, Citrix XenServer\u00ae, Red Hat\u00ae KVM, Microsoft Hyper -V\u00ae, Green Hills \nIntegrity\u00ae, Lynx Software Technologies LynxSecure\u00ae  \n77 Examples include VMware Workstation/Fusion\u00ae, Oracle VirtualBox\u00ae  \n78 Examples include Microsoft Windows\u00ae or Red Hat\u00ae Enterprise Linux\u00aeUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}196{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "195", "chunk": ", ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 91 of 397 3. Storage Separation  2272  \nIn VM -based CDS, the underlying Type 1 Hypervisor or trusted OS (in the case of the Type 2  2273  \nhypervisor ) implements MAC to separate the different VMs. Generally, e ach user facing  VM is 2274  \noperatin g at a different security level however , it is common for support VMs to be operating at 2275  \nthe same level of its associated user VM, at the level of a network interface, or at some artificial 2276  \nlevel (like SYSTEM HIGH or SYSTEM LOW).  The platform has different network interface 2277  \ncards (NIC) ( e.g., Ethernet) for each security domain. But in some cases, one security domain 2278  \nmight be tunneled over another security domain using IP Security ( IPSec ) Tunnels. When 2279  \nimplementing IPSec Tunnels, Service VMs are used to provide NIC isolation and provide 2280  \nseparation and protection for each of the IPSec Tunnels.  If IPSec Tunnels are used , then  they 2281  \nmust comply with the guidance and rules established by the NSA\u2019s Commercial Solutions for 2282  \nClassified (CSfC)79 program and usually the Mobile Access Capability Package (MACP)80. 2283  \nVM-based CDS are commonly used in Tactical and Enterprise Environments especially when 2284  \nthe nu", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}197{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "196", "chunk": "mber of security domains is small.  2285  \nThis t ype of VM -based architecture applies to both desktop  and server  Access CDS . 2286  \n\u2022 In the desktop  implementation, the Access CDS provides a user access to multiple 2287  \ndomains concurrently. Each domain has its on each  VM (e.g., usually running Microsoft 2288  \nWindows\u00ae) and network connection . If the implementation uses CSfC , a single physical 2289  \nnetwork might be used however each VM will be tunnel led over that physical network 2290  \nusing CSfC compliant tunnels.  Each of the CSfC tunnels will be in their own VMs . 2291  \n\u2022 In the server  implem entation , the Access CDS is hosting  virtual machines for multiple 2292  \ndifferent security domains concurrently. For example , a Server -variant  of an  Access 2293  \nCDS could host multiple instances of a Microsoft Windows \u00ae environment  (e.g., 2294  \nMicrosoft Exchange\u00ae, Microsoft Active Directory\u00ae, Microsoft SharePoint Server\u00ae , and 2295  \nMicrosoft Windows 10 \u00ae desktops)  each at a different Secret Releasable level.   2296  \nThe separation  and security  requirements  for desktop and server variants of an Access CDS  are 2297  \nthe same.   2298  \nAn Access CDS can be used to host a transfer CDS. The requirements for the use of 2299  \nvirtualization technologies in", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}198{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "197", "chunk": " a CDS are described in Section 12. 2300  \n \n79 https://www. nsa.gov/resources/everyone/csfc  \n80 https://www.nsa.gov/resources/everyone/csfc/capability -packages/#mobile -accessUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 92 of 397 \n ADP -8: Remote VDI Access CDS  2301  \n 2302  \nFigure 17 \u2013 ADP-8: Remote VDI Access CDS  2303  \nRemote VDI based Access CDS typically consist of the three components:  2304  \n1) A Virtual Desktop Infrastructure81 on the low domains  hosting a separate guest OS for 2305  \neach user that is connected ; 2306  \n2) A System High Client usually running on a Trusted OS; and  2307  \n3) A CDS that is filtering the VDI protocol between the VDI system and the System High 2308  \nClient. This CDS can be connected to one or more VDIs in one or more security d omains. 2309  \nThe CDS  does a protocol break for the VDI protocol and use s a simple, highly 2310  \ninspecta ble, and ver ifiable  protocol between it and the system high client.  This portion of 2311  \nthe Access CDS is a Transfer CDS.  2312  \nRemote VDI based Access CDS generally scale very well to a large number of concurrent 2313", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}199{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "198", "chunk": "  \nsecurity domains and are the dominant Access CDS in Enterprise environments. While they can 2314  \nbe used in Tactical environments, that use case is rare except for shipboard. The system high 2315  \nclient should  be connected to a private system high network purpose built for the clients.  2316  \nThere are Remote VDI based CDS implemented in software and hardware. The hardware -based 2317  \nRemote VDI based CDS may be authorized to connect to a broader range of networks and 2318  \npotentially between U and TS. Hardware -based Remote VDI CDS usually provide just a single 2319  \nlow/single high domain p air per hardware device . Software based Remote VDI CDS are 2320  \nrestricted to one level of separation (U to S, S to TS but not U to TS).  2321  \n  2322  \n \n81 Examples include VMware Horizon\u00ae, Citrix XenDesktop\u00aeUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 93 of 397  2323  \n ADP -9: Tactical Access CDS with Embedded Transfer CDS  2324  \n 2325  \n 2326  \nFigure 18 \u2013 ADP-9: Tactical Access CDS with Embedded Transfer CDS  2327  \nThis design pattern is a combination of multi -domain transfer CDS hosted on ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}200{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "199", "chunk": "an Access CDS 2328  \nServer variant. In a tactical configuration , the configuration of the system is fixed at installation 2329  \ntime and u sually only one guest VM  (primarily the system high guest VM)  is allowed to access 2330  \nthe display and input devices (e.g., mouse, bezels, touchscreen, keyboard) . In most tactical 2331  \nenvironments, the low side is the Controller Area Network Bus (CANbus) for the v ehicle and has 2332  \nno external communications  and is generally considered low threat . However, i f the low side 2333  \ncommunicates externally then it usually is considered high threat  and this design pattern would 2334  \nnot apply.  2335  \n8.3.3  Tactical Transfer CDS Design Patterns  and Requirements  2336  \nThis section provides  some example  tactical CDS design patterns to provide a foundation for 2337  \ndescribing different techniques  and technologies that address common problems with tactical 2338  \nCDS including loss of physical control of the device; space, weight , and power (SwaP) concerns; 2339UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 94 of 397 reconfigurability and reusabili", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}201{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "200", "chunk": "ty; and long-term operations , maintenance , and support  costs. 2340  \nVariations are expected and should be discussed with the N CDSMO prior to implementation.  2341  \nWhile these design patterns only show two domains  for clarity , a multiple domain solution can 2342  \nbe implemented provide d sufficiently large field programmable gate arrays (FPGAs)82 are used.  2343  \n FPGAs for Tactical CDS  2344  \nFPGAs are esse ntial to tactical CDS designs. FPGAs provide  flexibility for the initial design 2345  \nprocess and provide for future updating of capabilities. In addition, FPGAs are used in a variety 2346  \nof industries that prioritize the protection of complex electronic system \u2019s intellectual property. 2347  \nAs such, Commodity FPGAs have built in security features that are ideal for tactical CDS . 2348  \nAny design pattern using FPGAs must provide security protections for the CDS during shipping 2349  \nfrom a manufacturing facility, storage at depot, nor mal operations, and loss of physical control.  2350  \nThe tactical CDS design patterns described in this section require one or both types of FPGAs 2351  \ndescribed below.  2352  \n1. SRAM -based FPGA (SFPGA)  (e.g., Intel\u00ae, Xilinx\u00ae) SFPGA  use a configuration 2353  \nbitstream file that prog rams the logical arrangement of re", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}202{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "201", "chunk": "sources on the device every 2354  \ntime power is applied.  The configuration file is typically loaded from a separate 2355  \nmemory device like a flash memory. There is a measurable time delay before the 2356  \nSFPGA is programmed during boot and the logic becomes active. An SFPGA can be 2357  \nused for protocol termination and rebuild,  data normalization,  content filtering , 2358  \nunidirectional flow enforcement, and domain separation. Anti -tamper functionality 2359  \nimplemented in the SFPGA adds critical additio nal layers of security to the tactical CDS.  2360  \n 2361  \n2. Non-Volatile FPGAs (NVFPGAs)  (e.g., MicroSemi\u00ae, Lattice\u00ae) have a configuration 2362  \nthat is programmed prior to final assembly of the system and does not require reloading 2363  \nevery time power is applied . NVFPGA functionality is active as soon as power is 2364  \napplied. The addition of a NVFPGA to a CDS design pattern that uses SFPGAs is 2365  \ncritical to ensure the system security during the time while the SFPGA configuration file 2366  \nis loaded.  An NVFPGA can be used as the sole FPGA in a CDS, if the logic resources 2367  \nare sufficient for a given design.  2368  \n 2369  \nIf the FPGA is not capable of implementing independent USB, Ethernet, or PCIe controllers, 2370  \nthen additional FPGA", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}203{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "202", "chunk": "s or USB/Ethernet/PCIe ASIC will have to be used in the other domains 2371  \nconnected to the FPGA.  2372  \nIn RTB v4.1, the below patterns included the use of CPU that was part of the FPGA package that 2373  \ncould be used for CDS remote management and monitoring.  Unfort unately, due to the method 2374  \n \n82 https://www.eetimes.com/all -abou t-fpgas  and https://electronics.stackexchange.com/questions/405158/why -are-\nsram -based -fpga-used-more -than-nvm-based -fpgaUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 95 of 397 that those CPUs were integrated with the FPGA there was a potential for a security issue. The 2375  \nCPU could reconfigure  the FPGA. While  there were some mechanisms to prevent the FPGA 2376  \nbeing reconfigure d by the CPU , it was decide d that those mechanism unnecessarily increase d the 2377  \ncomplexity and security of the CDS  especially when implementing the CDS Anti -Tamper 2378  \nrequirements . Therefore, the use of FPGA s with embedded physical CPUs is no longer allowed 2379  \nfor Tactical CDS. They are allo wed for Datacenter  class CDS.  CDS implemented  against  RTB 2380 ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}204{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "203", "chunk": " \n4.1 with the CDS Anti -Tamper requirements will be allowed to use FP GAs with the embedded 2381  \nCPU but fencing mechanisms must be implemented to prevent the CPU from being able to 2382  \nreconfigure the FPG A. 2383  \n ADP-10: Two Domain Tactical CDS based on CPUs with FPGAs  2384  \nThis design pattern is an example of a tactical CDS using commodity CPUs (e.g., Intel\u00ae, 2385  \nAMD\u00ae, ARM\u00ae, PowerPC\u00ae) and FPGAs to provide filtering, separation, and anti-tamper 2386  \nsecurity to a CDS while still supporting reconfigurability.  Filters implemented in an  FPGA must 2387  \ncompl y with the HW CR requirements . The use of soft cores83 running software to host the filters 2388  \nis not allowed, but  soft cores may be used for protocol adapters  and data 2389  \nnormalization /denormalization . Care should be taken to reduce or eliminate the use of an 2390  \noperating system to run the protocol adapter in order to reduce long term operations and 2391  \nmaintenance (e.g., patching) costs.  If ARM\u00ae CPUs are being used, it is strongly recommended 2392  \nthat CPUs and boards be compliant with ARM\u2019s SystemReady standards84 to obtain robust 2393  \ncommercial operating system vendor support. There is no requirement that the two dataflow 2394  \ncommodity CPUs be the same make/model chip or diff", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}205{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "204", "chunk": "erent  make/model chips . 2395  \n 2396  \n \n83 A soft core CPU is an implementation of a CPU running inside of the SFPGA.  \n84 https://developer.arm.com/architectures/system -archite ctures/arm -systemready/specificationsUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 96 of 397  2397  \nFigure 19 \u2013 ADP-10: Two Domain Tactical CDS Using CPUs and FPGAs  2398  \nThe SRAM -based FPGA can send  logs out a dedicated Ethernet or USB port .  2399  \nIf the commodity CPUs are implementing filter pipelines then at least one of ADP (s) 1 through 6 2400  \nwould apply. The commodity CPU s are not required to implement filtering if filtering in the 2401  \nFPGA(s) meets RTB requirements  (see Section 8.3.4 ). Some solutions may use the commodity 2402  \nCPUs solely as  protocol adapters and data normalization/denormalization functions. Normally 2403  \ndenormalization is not considered security relevant (from a filtering perspective) but it is for 2404  \nsome data formats like images, video, and audio. If the denormalization is determ ined to be 2405  \nsecurity relevant then security requirements and pipeline design for that CPU", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}206{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "205", "chunk": " would have to 2406  \ncomply with RTB pipeline design and security requirements.  If the CDS is going to be connected 2407  \nto an HTN the low side should not implement security relev ant filtering \u2013 the filtering should 2408  \nonly be in the FPGA(s) and/or high side CPU.  2409  \n Watchdog NVFPGA (WNVFPGA)  2410  \nThe WNVFPGA is the system security master that oversees the CDS security posture 2411  \nimmediately when power is applied and during normal operations. All  security sensors 2412  \nprovisioned for anti -tamper capabilities are monitored and processed by the WNVFPGA. The 2413  \nWNVFPGA carries out the decryption of any SFPGA configuration bitstream file. The 2414  \nWNVFPGA is responsible for the initial and any subsequent programmi ng of the SFPGA once 2415  \nthe security state of the CDS is established by the WNVFPGA. Due to the large number of 2416UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 97 of 397 security features86  the WNVFPGA supports, the size and logic capabilities of the WNVFPGA 2417  \nare much greater than the Sentinel NVFPGA (SNVFPGA).  2418  \n Sent inel NVFPGA (SNVFPGA)  2419  \nTh", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}207{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "206", "chunk": "e SNVFPGA works with the WNVFPGA during normal powered operations but primarily 2420  \nacts to ensure the CDS is secure when normal operational power is off for short or long periods 2421  \nof time. The SNVFPGA is a low -power device that can run on a battery. To support low -power 2422  \noperation, the SNVFPGA has less built -in security features87  than the WNVFPGA. The low - 2423  \npower nature of the SNVFPGA means that only a critical subset of the system security sensors 2424  \nthat the WNVFPGA monitors are connected to the SNVFPGA. The SNVFPGA still provides 2425  \ncritical security monitoring in situations such as planned or unplanned power outage, storage, 2426  \ntransit to depot, or any other time when a tactical CDS is not operating under normal system 2427  \npower. Hold -up capacitors  for the SNVFPGA are required to provide power for a secure system 2428  \nshutdown and destruction of critical program information if the battery is removed or the battery 2429  \nvoltage drops below a functional level.  2430  \nADP -10 provides the highest CDS functionality in an y of the FPGA based design patterns and 2431  \nprovides the highest level of security. The space , weight, power,  and cost of ADP -10 is the 2432  \nhighest of all the FPGA based design patterns.  2433  \n ADP -11:", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}208{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "207", "chunk": " Two Domain Tactical CDS without commodity CPUs  2434  \nThis design pattern is an example of a tactical CDS using only FPGAs. It differs from ADP -10 2435  \nby not using commodity CPUs and requiring the use of a soft core  CPU  inside the SFPGA to 2436  \nperform management functions ( Figure 20). This pattern is particular ly useful in systems that 2437  \nneed to transfer simple data formats with guaranteed latencies  or throughput requirements that do 2438  \nnot change for long periods  of time (5 -15 years). This pattern is ideal for weapon systems and 2439  \nsensors. Because of the lack of software , this type of system has very minimal patching 2440  \nrequirements over the expected operational lifetime of the system.  The SFPGA provides all the 2441  \nCDS fi ltering and separation functionality. The WNVFPGA and SNVFPGA fill the same roles 2442  \nas described in ADP -10.  2443  \n \n86 For example, https://www.microsemi.com/document -portal/doc_download/136534 -ug0753 -polarfire -fpga-\nsecurity -user-guide  \n87 For example, https://www.microsemi.com/document -portal/doc_download/132037 -ug0443 -smartfusion2 -and-\nigloo2 -fpga-security -best-practices -user-guideUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIF", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}209{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "208", "chunk": "IED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 98 of 397   2444  \n 2445  \nFigure 20 \u2013 ADP-11: Two Domain Tactical CDS Using FPGAs (No CPUs)  2446  \nADP -11 provides a high level of CDS functionality but possibly less than ADP -10 due to the 2447  \nlack of the  commodity CPUs.  ADP -11 necessitates the CDS functionality be implementable in 2448  \nthe logic resourc es of an SFPGA. SFPGAs have considerable logic capabilities, but this 2449  \napproach may still require some functionality trade -offs to fit. The space, weight, power,  and 2450  \ncost of ADP -11 will generally be less than that of ADP -10, but the cost of the SFPGA requir ed 2451  \ncould  be considerably higher than the SFPGA found in ADP -10.  2452  \n ADP -12: Two Domain Tactical CDS using only NVFPGAs  2453  \nThis design pattern ( Figure 21) works for CDS implementations that require less system 2454  \ncomplexity and lower space, weight, power,  and cost than ADP -10 or ADP -11. An ADP -12 CDS 2455  \nimplementation must be able to support all required filtering and separation functionality solely 2456  \nin a NVFPGA88.  A separa te WNVFPGA is not needed if there are enough logic resources and 2457  \nsecurity features in the selected NVFPGA. An SNVFPGA is still n", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}210{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "209", "chunk": "eeded to provide security in 2458  \nthe situations outlined above when primary system power is not present.  This pattern has the 2459  \nsame b asic use case advantages as ADP -11. However , due to the smaller size of most NV FPGA s 2460  \nthe complexity and number of concurrent data types and protocols that can be supported will be 2461  \nmuch lower.  2462  \n 2463  \n \n88 https://www.embedded.com/flash -fpgas -give-designers -more -flexibility/UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 99 of 397  2464  \nFigure 21 \u2013 ADP-12: Two Domain Tactical CDS Using Only NVFPGAs  2465  \n 2466  \n ADP -13: Two Domain Tactical CDS for minimum SWAP  2467  \nADP -13 (Figure 22) is a design pattern for a tactical CDS where SWAP requirements are 2468  \nsignificantly lower than ADP -12. An example of an ADP -13 application would be a battery 2469  \npowered soldier wearable CDS. Low power NVFPGAs can provide a limited set of CDS 2470  \nfunctionality. The  NVFPGA in this design pattern can still support security sensor detection and 2471  \nresponse. ADP -13 replaces the SNVFPGA of previous design patterns with an extremely low ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}211{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "210", "chunk": "2472  \npower security integrated circuit89.  The security integrated circuit  increases the syste m security 2473  \nby working in parallel with the security functions of the NVFPGA to provide a dispersed 2474  \nsecurity architecture . It is  similar to the other ADPs , but still sati sfies the SWAP  requirements of 2475  \na small form factor. Networking and power can be provide d over USB or a Power -over-Ethernet 2476  \n(PoE) connection.  2477  \n 2478  \n \n89 An example of a security manager integrated circuit is a MAX36051 \nhttps://www.maximintegrated.com/en/products/embedded -security/security -managers/MAX36051.htmlUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 100 of 397  2479  \nFigure 22 \u2013 ADP-13: Two Domain Tactical CDS for Low SWAP  2480  \n Tactical CDS with FPGA ADP Comparison  2481  \nThe table below shows the tradeoffs for functionality, security, and SWAP for  ADP -10 through  2482  \nADP -13. 2483  \nTable 3 \u2013 Tactical CDS with FPGA ADP Comparison  2484  \nADP  CDS Functionality Supported  Security Protection  SWAP  Required  \n10 Highest  Highest  Highest  \n11 High  High  High  \n12 Medium  Medium  M", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}212{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "211", "chunk": "edium  \n13 Limited  Limited  Low \n8.3.4  Hardware Content Filtering Device s (HCFD)  2485  \nAn HCFD is a hardware -based device that implement s hardware -based  separation, unidirectional 2486  \nflow enforcement, protocol reconstruction , and the protocol  filtering  of a Protocol Filtering 2487  \nDiode ( PFD)  while also syntactically and semantically filtering the content being transferred . An 2488  \nHCFD can support bi -directional operation (in a single device) when used with an appropriate 2489  \n(for the data types  and protocol s) software CDS on either the high side  (preferred) or as part of a 2490  \npitcher/catcher solution (see OWTDP -7). The syntactic and semantic filtering is intended to 2491  \nsignificantly  reduce the ability to attack the high side software CDS (e.g., protocol adapters, 2492  \nfilters) by reducing  the need to implem ent the more costly and complex OWTDP -4C design 2493  \npatterns.  The rule of three (see OWT -12) still applies for HCFD. The third filter is the hardware 2494  \nfiltering.  Hardware filtering implementations are encouraged to also implement logical filtering.  2495  \nWhen used in combination with a software CDS, the HCFD does not need a second redundant 2496  \nand independent implementation of the hardware filter since it is imple", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}213{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "212", "chunk": "menting the \u201crule of 2497  \nthree\u201d filter.  The semantic filter must be implemented in such it will only allow specifi ed 2498UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 101 of 397 messages types to pass. For example, if the HCFD is filtering XML it must  be able to verify the 2499  \nXML complies with the specific schema(s) loaded in the device.  2500  \nAn HCFD may also be a CDS  if the hardware filtering  implements RAIN and logical f iltering so 2501  \nit can fully address the data attack and data loss prevention concerns for the data types being 2502  \nprocessed (see ADP -10 through ADP -13). HCFD are primarily implemented in FPGAs.   If an 2503  \nHCFD is intended to be a CDS then the filtering must be redun dant and  a second implementation 2504  \nwill be required. While the content -based attack paths against a hardware based CDS are 2505  \nsubstantially lower, there is still  the possibility of logic flaws in the implementation of the filter 2506  \nlogic \u2013 thus the need for a seco nd independent filter implementation.  2507  \nInside the HCFD, the hardware -based filtering is done prior to the one -", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}214{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "213", "chunk": "way transfer function . 2508  \nSoftware running on commodity CPUs or software cores may be  used for protocol termination 2509  \nand data normalization.  HCFD are not required to process only normalized dat a. However, the 2510  \nuse of normalized data formats i s recommend ed to reduce HCFD complexity and increase 2511  \nflexibility.  2512  \nHCFD are required to have the capab ility to send logs to a DCO OOB.  2513  \nThe core implementation requirements for HCFDs are in Section 15.5. Section OWTDP -7:  Bi- 2514  \nDirectional Transfer with Hardware Filtering  is an example of a n HCFD used in combination 2515  \nwith a multi -domain software CDS between unclassified  and multiple classified networks.  2516  \n 2517  \nFigure 23 - ADP-14 Example of HCFD  used in Enterprise Environments  2518  \nIn this example, Filter A and Filter A\u2019 can be the same FPGA logic but must be a different 2519  \ninstantiation of that logic . Filter A and Filter A\u2019 would likely have different ru lesets  depending 2520  \non the dataflows going in each direction.  2521  \nThe Green and Red Commodity CPUs are primarily used to host protocol adapters and data 2522UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}215{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "214", "chunk": " TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 102 of 397 normalization/denormalization functions. Whi le this drawing shows them as hard cores, they 2523  \ncould also be soft cores running within the FPGA fabric.  The use of soft cores is not 2524  \nrecommended for performance r easons.   The Red and Green Commodity CPU s boot from 2525  \nstorage devices controlled by the FPGA.  The FPGA is responsible for decrypting the Commodity 2526  \nCPU images.  2527  \nThe Management CPU can be a physical CPU separate from the FPGA, a CPU embedded within 2528  \nthe SFPGA (e.g., Xilinx Zynq \u2122 or Intel Stratix \u2122), or a soft core CPU  (e.g., Intel NIOS\u00ae, 2529  \nXilinx MicroBlaze\u00ae or RISC -V90\u00ae CPUs) implemented in the FPGA fabric. The Management 2530  \nCPU is not allowed to process any dataflow traffic.  It is recommended that network/USB 2531  \nconnections to the commodity CPUs be routed through the FPGA firs t for protocol level 2532  \nfiltering.   2533  \nADP -14 is not intended to be used in tactical environments.  2534  \n  2535  \n \n90 https://riscv.orgUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}216{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "215", "chunk": "\nPage 103 of 397 8.4 Design Patterns  and Requirements  using One -Way Transfer 2536  \nMechanisms (OWTDP)  2537  \nThis section covers the design patterns using One -Way Transfer (OWT) mechanisms as part of a 2538  \nCDS arc hitecture . This section assumes the reader has read the Pitcher /Diode /Catcher  (PDC) 2539  \ndefinition in Section 3: CDS Definitions.  2540  \nAll OWT mechani sms must be implemented in hardware to guarantee  their one -way 2541  \nfunctionality  and thus their security. Software based technologies are not sufficient to meet the 2542  \none-way transfer requirements in this section. The below list of definitions describes one -way 2543  \ndevices used in OWT solutions.  2544  \n\u2022 In electronics, a diode  is an electrical or optical device design ed to transfer a signal in a 2545  \nsingle direction.   2546  \n\u2022 Taps are a type of diode that is specifically designed to mirror  (i.e., copy) all network  2547  \ntraffic  it receives to two or more destination  networks . Taps do not inspect, modify,  or 2548  \ndiscriminate on the traffic they transfer . Many taps are passive optical devices with no 2549  \nelectrical components.  2550  \n\u2022 A cyber tap  is a variant of a tap that meets the design and testing requirements  stated in 2551  \nthe NCDSMO\u2019s  Cyber  One-Way Taps", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}217{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "216", "chunk": " Technical Requirements  document.  2552  \n\u2022 In the CDS  community the term diode has a more specialized and nuanced definition 2553  \nwhich is : a Simple CDS Diode (SCD)  is a device (usually optical or FPGA based) that 2554  \ntransfers selected data via a  specific protocol (e.g., UDP ) in a single direction.  2555  \n1. Most CDS  community diodes are surrounded by  a pitcher (sends data) and catcher 2556  \n(receives data) to handle the conversion of bidirectional protocols ( e.g., SFTP , 2557  \nHTTPS) used on the operational networks to a protocol that can be transmitted 2558  \nover the diode. When a SCD is combined with a simple pitcher and catcher , to 2559  \nonly handle protocol termination and rebuild , the combination system is  called a 2560  \nSimple Diode Solution (SDS) . 2561  \n2. Historically, most diodes have been Ethernet cards with a n optical Y -splitter cable 2562  \nand possibly special firmware to allow the cards to reliably send Ethernet packets 2563  \n(a bidirectional protocol) unidirectionally. Some pitcher/catchers have a dditional 2564  \nsoftware to optimize the network packet utilization to enforce specific throughput 2565  \nand latency requirements for the different data flows transiting the device. These 2566  \ndiodes do not filter any data,  so the y do ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}218{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "217", "chunk": "not protect the catcher from data link  2567  \nlayer ( e.g., Ethernet ), network layer (e.g ., IP), and transport layer (e .g., UDP) 2568  \nattacks . 2569  \n3. SCDs are not intended to  prevent  attacks against the software CDS on the high 2570  \nside of the diode . SCDs  do prevent direct  attacks against the software CDS  and 2571  \ncan prevent exfiltration of data from the high side due to an attack against the 2572  \nhigh side . SCDs  increase the complexity of low -to-high attacks by preventing 2573  \ndirect access to the software CDS and preventing the use of a bi -directional 2574  \ncommand and control chan nel for the malware.  2575UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 104 of 397 4. This type of diode does not implement a protocol break.  2576  \n\u2022 Protocol  Filtering Diodes  (PFD)  (see OWT -17 below)  implement filtering , in hardware,  2577  \nfor data link, network,  and transport layers. The filtering terminate s and rebuild s all 2578  \npackets  and validate s the packet metadata to reduce  the potential protocol attacks against 2579  \nthe catcher.  While the  PFD\u2019s protocol termination", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}219{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "218", "chunk": " and protocol rebuild can be done in 2580  \nsoftware  on separate CPUs or on a FPGA soft core CPU s, for performance reasons it is 2581  \nnot recommended to use software for protocol termination  and rebuild . The hardware 2582  \nmust syntactically, sema ntically, and logically  validate the metadata being transferred 2583  \nbetween the protocol adapters. The PFD does not filter the payload data but it  is strongly 2584  \nrecommended that the hardware  verify the integrity (e.g., CRC/ hash) of the payload. 2585  \nUnder no circumstances can Ethernet (or similar layer 2 protocols), IP, TCP, UDP , 2586  \nICMP, or similar protocol s transit the PFD. Essentially any protocols handled by the 2587  \nnetwork card or the kernel are prohibited from transiting the PFD a nd must be rebuilt in 2588  \nthe destination  domain . The typical metadata allowed are a destination unique ID91, 2589  \nsource IP or source unique ID , CRC /hash of the payload, sequence number, and length of 2590  \nthe payload. Each of these are validated in hardware  to be syntactically , semantically , and 2591  \nlogically  correct and CRC /hash  (if present)  is validated against the payload.92 This type 2592  \nof diode is implement ing a protocol break.  The rationale for the protocol break is to 2593  \naddress the fo", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}220{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "219", "chunk": "llowing two problems : 2594  \n1. If a low side pitcher  was compromised, it is possible that the diode NIC driver and 2595  \nfirmware could be reverse engineered and a remote exploit found that could be 2596  \nused to  exploit the high side NIC and then  compromise the high side catcher.  2597  \n2. If a low side pitcher was compromised,  it is possible to generate malformed IP 2598  \nand UDP packets that could exploit the high side catcher when received.  2599  \nFor the purpose s of the drawings in this section the term diode applies to both simple CDS diode 2600  \nand protocol filtering diodes.  2601  \nHardware -based separation  mechanisms like optical diode s, FPGA based diode s, and 2602  \nelectro/optical tap s provide  guaranteed domain separation  and, in some implementations, a 2603  \nprotocol break . Hardware -based separation provides a redundant separation mechanism to the 2604  \noperating system kernel\u2019s mandatory access control mechanism. OWT devices do not address 2605  \ncontent -based  security issues like delivery o f malware, malware C2, malware -based  exfiltration, 2606  \nand insider threat -based  exfiltration . When using an OWT, a robust filtering solution is required  2607  \nfor content inspection  and sanitization . In an OWT system, the pitcher is the devi", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}221{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "220", "chunk": "ce that receives 2608  \ndata from the origin domain, filters it, and sends it o ver the OWT device to the catcher . The 2609  \ncatcher is the device that receives data from the OWT, filters it, and sends it to system(s) in the 2610  \ndestination domain.  2611  \n \n91 This is usually mapped to an IP Address and Port number of the destination side of the diode.  \n92 Example s of PFD filtering include verify ing source IP is a structurally correct IP and logically correct for the \nattached network, verifying a sequence number is a positive integer , validates the destination ID is a known  ID.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 105 of 397 CDS developers of PDC solutions are strongly recommended to move all filtering to the high 2612  \nside o f the solution. Non-security relevant n ormalization and denormalization will still be 2613  \nallowed on low side  (to support integration with  HCFDs)  however security relevant 2614  \ndenormalization (e.g., lossly recompression of vi deo or audio) must remain on the high side  2615  \n(unless performed in an HCFD) . Support for low side filtering  in a PDC  will", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}222{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "221", "chunk": " be deprecated in a 2616  \nfuture  release of this document . See Section 1.7. 2617  \nThe following is a list of requirements that apply to one-way transfer  implementations. Some of 2618  \nthese requirements refer  to the OW T Design Patterns  and it may be helpful for the reader to read 2619  \nthe requirements, then review  the OWT Design Patterns , then reread the requirements.  The 2620  \nrectangular (purple) and rounded rectangle  (red, green & purple)  boxes in the OWTDP drawings 2621  \nare physical systems not logical function s. 2622  \nOWT -1 If an OWT solution\u2019s pitcher or catche r are implementing filtering then they  shall 2623  \nimplement a Transfer CDS ADP.   An acceptable variant of putting filtering on the low 2624  \npitcher /catcher is to put all filtering on the high side of the di ode. However, a linear MAC 2625  \nenforced pipeline is still required from the Protocol Adapter to the Diode interface even if 2626  \nno filters are in the pipeline.  2627  \nOWT -2 Remote Management and Monitoring of the OWT  low side  server (e.g. , pitcher or 2628  \ncatcher) shall  be implemented  via an Out -of-Band (OOB) management network 2629  \nconnection  that is  separate from the high side server (e.g. , pitcher or catcher)  of the 2630  \nOWT.   2631  \nOWT -3 A single Defensiv", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}223{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "222", "chunk": "e  Cyber space  Operations (DCO)  of CDS OOB  network  (called DCO 2632  \nof CDS OOB or DCO OOB)  may be used  for monitoring  both the high and low sides of 2633  \nan OWT  system  if separate OWT  (e.g., Cyber Taps)  devices are used to send the audit, 2634  \nlogging, and journaling data to the OOB.  2635  \nOWT -4 The Pitcher and Catcher shall  individually implement RAIN principles  with respect to 2636  \ntheir implementation of a filtering pipeline.  2637  \nClarification:  The pitcher and catcher each have filtering pipelines.  It is not intended that 2638  \nthe pitcher and catcher each have redundant filters. For example, if the pitcher and 2639  \ncatcher are implementing an XML pipeline only two XML schema validation filters 2640  \nwould be re quired not four.  One for each device.  2641  \nOWT -5 The Catcher \u2019s implementation of independent  filtering  shall  be different from the 2642  \nPitcher \u2019s implementation.  2643  \nClarification: The pitcher and catcher must use different implementations of the filt ers. 2644  \nOWT -6 In environments where one -way devices a re used for Low -to-High and High -to-Low 2645  \ndataflows, the low side Pitchers/ Catchers shall  use different filter implementation(s) than 2646  \nthe high side Pitchers/ Catchers.  This prevents an adversary t", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}224{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "223", "chunk": "hat compromises a low  side 2647  \nPitcher and low  side Catcher from knowing the high side implementation.   2648  \nOWT -7 Deleted. Duplicates OWT -8. 2649UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 106 of 397 OWT -8 Hardware based separation shall be used between HTN  and classified USG NSS. This 2650  \nimplements redundancy and independence in the domain separation mechanism along 2651  \nwith the software -based  domain separation that  is implemented  on the pitcher and 2652  \ncatcher.  This applies to both Access and Transfer CDS.   2653  \nClarification: Essentially the software CDS portion of the solution implements one level 2654  \nof separation using operating system MAC and the hardware -based  separation 2655  \nimplements the second independent redundant separation.  2656  \nOWT -9 High Threat Networks  shall not use the same Pitcher/Catcher filtering software that 2657  \nwould be used on the USG Classified NSS network s. The HTN s must  always  use the low 2658  \nside pitcher/catcher software. This reduces the risks of the HTN s being able to cause a 2659  \nfail open condition through the CDS. ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}225{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "224", "chunk": " The high side described in OWT -6 is the portion 2660  \nused on USG Classified NSS.   See OWTD P-5 and Figure 35. 2661  \nOWT -10 The high side software in a diode configuration, normally reserved for use on USG 2662  \nNSS, shall  be used on  the high side of the second diode in the OWTDP -5 configuration. 2663  \nSee OWTD P-5 and Figure 35. 2664  \nOWT -11 The site-specific  system level CDS deployment architecture  which includes the CDS  2665  \nproduct name (with or without version)  and supporting systems , how the systems  are 2666  \nconnected,  details of the CDS DCO architecture,  and how they  are implemented and 2667  \nconfigured shall be treated as classified, at a minimum of Confidential93.  2668  \nRationale: This requirement  reduces  exposure of CDS deployment details that could be 2669  \nused by  an adversary  to develop an approach to exploit the system. Adversary  2670  \nunderstanding of the nature of the filtering mechanisms  in the filtering domain (see 2671  \nOWTDP -3) or on the high side could negate some of the value of the diode separation.  2672  \nOWT -12 The Rule  of Three  \u2013 Three independent filter implementations shall be implemented  2673  \nfor bidirectional  dataflow s betwe en HTN and USG Classified NSS.   2674  \nRationale : The purpose of the rule of ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}226{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "225", "chunk": "three is to increase the complexity of an attack,  2675  \noriginating from the low domain, from establishing bidirectional  communications 2676  \nthrough the CDS infrastructure . For example, if an attacker managed to compromise 2677  \nthe multi -domain software CDS in OWTDP -4a or OWTDP -4c and there was no 2678  \nindependent filter on a separate system for the download path then a fully 2679  \nbidirectional  communication could occur. The third filter is intended to reduce that 2680  \nrisk. 2681  \n \n93 This does not necessarily imply that the actual CDS documentation including design documents are classified. \nWhile this may change in the future, as of the date of issuance of this document CDS documentation are classified, \nat a minimum, as CONTROLLED UNC LASSIFIED INFORMATION with SP -PROPIN, SP -EXPT (except for \nFMS CDS), and SP -CTI restrictions. ITAR 121 Category XIII (b) (4) applies to CDS used by the USG to protect \nNSS. Specific USG programs may decide that the documentation for CDS developed for or used  by the program is \nclassified higher than CUI.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}227{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "226", "chunk": "107 of 397 OWT -12.1 At least one of the implementations must be on a different CDS  or similar device  2682  \n(e.g., commercial filtering  appliance). S ee OWTDP -4c.  2683  \nOWT -12.2 The third filter may be on the high-side pitcher , however the system shall ensure the 2684  \nfilter is always invoked  and not bypassable . The filter must be  evaluated  by the 2685  \nNCDSMO . 2686  \nClarification : The evaluat ion of the robustness of the third filter implementation and 2687  \nintegration with the pitcher may in clude some level of lab testing. The use of filter 2688  \norchestration engines for hosting the third filter on the pitcher is generally not  2689  \nrecommended du e to the difficulty in proving it is not bypassable.  2690  \nOWT -12.3 If a commercial filtering appliance (e.g., XML firewall) is used , then  it shall have at 2691  \nleast two network interfaces.  2692  \nClarification : The two network interfaces are needed for requirement  OWT -12.4.  2693  \nOWT -12.4 If a commercial filtering appliance is used , then it  shall be physically and directly 2694  \ninline between the CDS and the pitcher.  2695  \nOWT -12.5 The rule of three filter must not exist on components connected  to any HTN.  2696  \nRationale : HTN s are by definition high risk networks and putting secur", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}228{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "227", "chunk": "ity critical CDS 2697  \nsoftware on an HTN is unsafe. Additionally, the rule of three is intended, in part, to 2698  \nprevent high side data from be exfiltrated to the low side so the fil ter needs to  operate  2699  \non the high side.  Lastly, knowledge of the specific rule of three implementation could 2700  \nprovide the adversary with the necessary details to defeat it if they also defeated the 2701  \nCDS.  2702  \nOWT -13 If the diode solution is impl emented using fiber optics, then the fiber cable connecting 2703  \ntwo devices (e.g., NICs) must be a single optical  strand.   2704  \nOWT -14 If the diode solution is implemented using fiber optics, then single strand transceivers94 2705  \nthat support transmit and receive  must not be used for the optical transmitter s and 2706  \nreceiver s. The use of diplexers is also not allowed . 2707  \nOWT -15 If the diode solution is implemented using  conventional  fiber optic  NICs (e.g., Ethernet 2708  \ncards with or without custom one -way firmware) then the receiv ing NIC\u2019s transmitter 2709  \nport must be physically and permanently disabled (e.g., pouri ng opaque non -light 2710  \ntransmitting epoxy in the transmission port).  2711  \nOWT -16 If the diode solution is implemented using fiber optics and conventional NICs (e.g., 2712  \nE", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}229{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "228", "chunk": "thernet cards with or without custom one -way firmware) then either the transmi tter 2713  \nNIC\u2019s receiver port must be physically and permanently disabled (e.g., pouring opaque 2714  \nnon-light transmitting epoxy in the transmission port) or an optical Y cable must be used 2715  \n \n94 As an example, https://community.fs.com/blog/single -strand -fiber -solution -is-it-right -for-you.html  this is NOT \nallowed as part of a one -way transfer solution.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 108 of 397 to backfeed the transmission signal  into the transmission port.   2716  \nOWT -17 Protocol Filtering Diode solution s shall implement hardware -based  protocol filtering .  2717  \nClarification:  There is no requirement that Ethernet, IP, or UDP be used in a diode. 2718  \nCustom protocols  are allowed so long  as they are properly filtered .  2719  \nOWT -17.1 When network protocols are handled by the PFD, then hardware filtering shall 2720  \ninclude a normalization function that converts packets (OSI layers 1 -4) into a normalized 2721  \nform, filtering the normalized data in hardware and then rebuil ding ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}230{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "229", "chunk": "the outbound packet 2722  \nbased on known good filtered data.  2723  \nClarification:  Payload filtering is out -of-scope for this requirement.  2724  \nOWT -17.2 If a custom protocol is being used by the diode, then a protocol filtering diode shall 2725  \nfilter, in hardware, that protocol ( e.g., flow id, sequence number, CRC) .  2726  \nClarification:  Payload filtering is out -of-scope for this requirement.  2727  \nOWT -17.3 Software protocol adapters (e.g., perhaps running on soft cores in a FPGA) may be 2728  \nused to terminate protocols  (e.g., OSI layer 1 -4), the PFD shall filter in hardware all 2729  \nmetadata necessary to reconstruct the protocol  in the destination domain.  2730  \nOWT -18 In OWTDP -4 design patterns for the Low-to-High ( L2H) catcher and the High -to-Low 2731  \n(H2L) pitcher shall not be connected to the same common switch.  2732  \nRationale: The common  switch substantially increases the attack risk and reduces the 2733  \nvalue of the diode because if the catcher is compromised then inclusion of the switch 2734  \nwould allow for a full loop from L2H2L  whic h could then be used to attack the 2735  \nsoftware  CDS . 2736  \nOWT -18.1 The L2H catcher and H2L pitcher must have physically separate connections to the 2737  \nsoftware CDS  including connecting t", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}231{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "230", "chunk": "o different Ethernet ports on the software CDS .  2738  \nOWT -18.2 The L2H catcher and H2L pitcher connections  to the software CDS may  include a 2739  \nswitch.  2740  \nClarification : Multiple L2H catchers (with the same source domains) could use a 2741  \ncommon switch connected to one or more software CDS but the H2L pitchers would 2742  \nnot be allowed to connect to the  same switch.  Figure 24 and Figure 25 are examples 2743  \nof unacceptable design patterns on how to use switches in OWTDP -4. They are 2744  \nunacceptable because there is now a bidirectional  path between high side pitcher and 2745  \nhigh side catcher in which no CDS is physically  inline.  Virtual routing and 2746  \nforwarding (VRF) and VLANs95/VXLANs96 are not an acceptable form of separation.  2747  \n \n95 https://en.wikipedia.org/wiki/VLAN_hopping , http://rikfarrow.com/Network/net0103.html ,  \n96 Virtual Extensible LANUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 109 of 397  2748  \nFigure 24 \u2013 OWT -18 Unacceptable  Design Pattern  #1 2749  \n 2750  \n 2751  \nFigure 25 \u2013 OWT -18 Unacceptable Design Pattern #2  2752  \nOWT -19 In the O", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}232{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "231", "chunk": "WTDP -4 design patterns , the network between the L2H catcher and software 2753  \nCDS and network between the software CDS and H2L pitcher shall operate  at a 2754  \nminimum of SECRET  (called \u201cgrey secret\u201d in the drawings).  2755  \nOWT -19.1 The \u201cgrey secret\u201d networks and systems connected to the grey network shall not  be 2756  \nroutable  to user networks  (e.g., SIPRnet, JWICS, et c.). The \u201cgrey secret\u201d network and 2757  \nassociated system s should be classified at no less than the secret releasable  level.  2758  \nClarification:  The hardware separation of the diode is considered the second 2759  \nindependent domain separation  mechanism of the overall  CDS solution . The 2760  \noperating system MAC policy is the first domain separation mechanism. The \u201cgrey 2761  \nsecret\u201d networks are private networks th at are part of the internals of the CDS system.  2762UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 110 of 397 OWT -20 If the diode functionality is implemented in an FPGA , then the code (e.g., VHDL, 2763  \nSystemVerilog)  used to implement the diode and the communications including 2764  \ninterfaces t", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}233{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "232", "chunk": "o commodity C PUs and the printed circuit board (PCB) shall  be provided 2765  \nduring the LBSA testing. The design schematic of the PCB will also need to be provided.  2766  \nOWT -21 For OWTDP -4 design patterns, the \u201cgrey network\u201d pitcher  and catchers may have a 2767  \nsecond diode installed to send  \u201cgrey network\u201d  logs to the DCO  of CDS  OOB .  2768  \nOWT -21.1 Intermediary switches and load balancers may send their logs to the \u201cgrey network\u201d 2769  \npitcher/catchers for trans mission to the DCO of CDS OOB . 2770  \nOWT -22 For OWTDP -4 design patterns, a common pitcher (called the DCO OOB pitcher) may 2771  \nbe used for the high side CDS/commercial filtering appliance . 2772  \nOWT -22.1 Each device must have a dedicated direct connection from the device into a 2773  \ndedicated DCO OOB pitcher . 2774  \nOWT -23 The pitcher and catcher must have IP forwarding disabled in the kernel.  2775  \nRationale:  The intent here is for the pitcher and catche r to rebuild the IP  and packets  2776  \nand create  new IP/TCP packets. Forwarding packets increases attack and exfiltration 2777  \nrisks.  See the definition of the PFD on why rebuilding the packets is necessary.  2778  \nOWT -24 Diode solutions leveraging  commod ity NICs  (e.g., Ethernet cards) for the diode shall 2779  \nuse differ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}234{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "233", "chunk": "ent vendor NICs  in the pitcher and catcher to reduce potential of firmware or 2780  \ndriver exploit s97 on the low side pitcher being used to attack the high side catcher.   2781  \nOWT -24.1 The NICs  used for the diodes  shall not use the same chipsets  or drivers . 2782  \nClar ification:  This is intended to prevent adversarial  compro mise of a low side pitcher 2783  \n/catcher from determining what NIC card and driver are used on the high side of the 2784  \ndiode  and thus develop ing exploits against it.  2785  \nOWT -25 In deployments with separate H2L and L2H PDC systems , the management interfaces 2786  \nof each PDC path shall not be connected together.  2787  \nClarification: In this configuration there would be a low pitcher and high catcher for 2788  \nL2H and a high pitcher and low catcher for H2L so a total of four possible 2789  \nmanagement inter faces. The two high devices must have physicall y separate 2790  \nmanagement systems. The two low devices cannot  connect to any high management 2791  \nsystem.  The two low device s potentially could share a single low management 2792  \nnetwork though this is not recommended.  2793  \nRationale:  Connecting the CDS management networks for H2L and L2H PDC instances  2794  \n \n97 https://www.intel.com/content/www/us/en/security -c", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}235{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "234", "chunk": "enter/advisory/intel -sa-00069.html , \nhttps://security.ias.edu/broadcom -netxtreme -ethernet -card-possible -remote -vulnerability , \nhttps://www. blackhat.com/presentations/bh -usa-07/Bulygin/Presentation/bh -usa-07-bulygin.pdfUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 111 of 397 provides a mechanism for an adversar y to move laterally between the H2L and L2H 2795  \nPDC instances . 2796  \nOWT -26 An HCFD shall implement separate  instances of  syntactic and semantic filtering for 2797  \neach direction of transfer.  2798  \nOWT -27 An HCFD shall  implement a separate instance of a one-way transfer function  after the 2799  \nfiltering logic for each direction of transfer.  2800  \nOWT -28 An HCFD may reuse , but with a separate instance, the syntactic and semantic filtering 2801  \nand one -way transfer logic . 2802  \nOWT -28.1 The rulesets may be reused if there are no direction of flow specific filtering rules.  2803  \nClarification : The H2L and L2H rules have no need to be different if there is no specific 2804  \nmission requirement  for filtering of rules based on direction of dataflow.  2805  \nOWT -2", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}236{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "235", "chunk": "9 In an PDF or HCFD,  all data flow control and filtering logic must be implemented in 2806  \nhardware logic.  2807  \nClarification: An example of data flow control is a one-way transfer function.  An 2808  \nexample of hardware logic is VHDL in an FPGA.  2809  \nOWT -30 An HCFD may implement  Protocol Adapters in software running on soft core  CPUs  2810  \non the FPGA .  2811  \nOWT -31 A HCFD or a PFD may provide a back -channel  ability to notify the sending system  2812  \nthat the destination system is down ; however , the data rate cannot exceed more than  1 bit 2813  \nper destination per minute.  2814  \nOWT -31.1 The back -channel functionality shall  be implemented entire ly in hardware logic.  2815  \n  2816UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 112 of 397 8.4.1  OWTDP -1: Traditional Diode Pattern  2817  \n 2818  \n 2819  \nFigure 26 \u2013 OWTDP -1: Traditional Diode Patt ern 2820  \nThis pattern is the typical unidirectional dataflow design pattern. It can be used High -to-Low or 2821  \nLow-to-High but not simultaneously at the same site. Pitcher s and Catchers are ru nning  a trusted 2822  \nOS and im", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}237{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "236", "chunk": "plement one of the ADPs for a transfer CDS.  The Pitcher and Catcher implement 2823  \nredundant, independent mechanisms.  As mentioned earlier, t he filters used on  the high side must 2824  \nonly ever be used on the high side . This addresses the concern of a compromise of the low side 2825  \nbeing used to exploit the high side be cause of reuse of the filters on the high side.  For example, if 2826  \nthe low side Pitcher/ Catcher is using libxml2 , then the high side Catcher/ Pitcher should use 2827  \ndifferent XML filters (e.g., Xerces -J) than the low  side. 2828  \nOWTDP -1 Variant  1: The preferred implementation of OWTDP -1 for low-to-high transfer  is to 2829  \nimplement no filtering on the pitcher  (in low domain) and implement all filtering on the catcher  2830  \n(in high domain) . If this is done, then one of the two approaches below must be implemented : 2831  \n1. The diode solution must be a PFD and not one -way NICs  installed in the pitcher and 2832  \ncatchers; or  2833  \n2. The low pitcher must be built to RTB standards with a pipeline,  but the pipeline cont ains 2834  \nonly protocol adapters for the external interface and diode.  2835  \nThese two approaches are designed to reduce the impact of a compromised low side pitcher from 2836  \nimpacting the security of t", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}238{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "237", "chunk": "he high side catcher. If the low side pitcher  was compromised, it is  2837  \npossible that the diode NIC driver and firmware could be reverse engineered,  and a remote 2838  \nexploit found that could  be used to compromise the high side catcher. It is for this reason, that in 2839  \nOWTDP -4a, 4b, and 4c, that the multi -domain  CDS cannot be physic ally connected to a diode 2840  \nNIC.  2841  \nNon-security relevant n ormalization functions can remain on the low side.  2842UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 113 of 397  2843  \nOWTDP -1 Variant  2: A potentially acceptable variant of OWTDP -1 for high-to-low transfer is 2844  \nto implement all filtering on the pitcher  (in high domain) and implement no filtering on the 2845  \ncatcher (in low domain) . If this is done  the low catcher  must be built to RTB standards with a 2846  \npipeline, but the pipeline contains only protocol adapters for the external interface and diode.  2847  \nNon-security  relevant denormalization functions can remain on the low side.  2848  \n 2849  \n8.4.2  OWTDP -2: Traditional Diode Pattern for  Bidirectional Data Flow s ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}239{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "238", "chunk": "2850  \n 2851  \nFigure 27 \u2013 OWTDP -2: Traditional Diode Pattern for Bidirectional Data Flows  2852  \nThis pattern is a variation of the Traditional Diode Pattern and is used to implement bidirectional 2853  \ndataflows. This has the same guidance and concerns as the Tradition al Diode Pattern but wit h the 2854  \nadded requirement that  three independent filters (per data type) must be used . Both low systems 2855  \nuse the same filters and the high Pitcher and high Catcher each use different implementations.  2856  \nThis is to ensure that  if one high side  implementation  is compromised by an adversary, the other 2857  \nhigh side implementation is not known. For example , for an XML dataflow, the low side 2858  \nPitcher/ Catcher could use libxml2, while the high side Pitcher  uses Xerces -J, and  the high side 2859  \nCatcher uses Woodstox. In this pattern the Implementation B Catcher and Implementation C 2860  \nPitcher are separate physical servers.  2861  \nOWTDP -2 Variant : See OWTDP -1 Variant above. The R ule of Three (OWT -12) still applies.  2862  \n  2863UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}240{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "239", "chunk": "114 of 397 OWTDP -3: Diode Sandwich  Pattern  2864  \n 2865  \nFigure 28 \u2013 OWTDP -3: Diode Sandwich Pattern  2866  \nThis pattern is used in scenarios when the low side is an HTN  and/or knowledge of the existence 2867  \nand components of the CDS must be minimized. It may be used for Low -to-High or High -to- 2868  \nLow dataflows. When used in a Low-to-High configuration, as shown in Figure 28, the low side 2869  \nPitcher should perform minimal processing  of the data and  instead send it to  filter ing domain  for 2870  \nprocessing . By wrapping the filtering with diodes, it reduces the direct attack surface and 2871  \nrequires t he adversary to execute an  attack on the filters in the destination domain with no 2872  \nfeedback on success or failure . The filtering domain  can leverage commercial appliances if 2873  \nsufficiently independent and physically in series . If only commercial appliances are used as the 2874  \nsole filtering mechanism  in the filtering domain , then an independent filter system must be used 2875  \non the high side . 2876  \nIf two diode sandwich architectures are deployed (in parallel) for bidirectional  communications,  2877  \nthen the filterin g domains must be physically separate and the rule of three still applies \u2013 there 2878  \nmust  be independent fi", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}241{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "240", "chunk": "ltering in each filtering domain and in the high domain . Diode A should 2879  \nbe used on the low side and Diode B should only be used on the high side.  2880  \nIf the Pitcher/Diode/Catcher Implementation  B is an SDS,  then there  must be a software CDS on 2881  \nthe high side of SDS B . See OWTDP -4A, 4B, and 4C.  2882  \nIf a bidirectional  data flow is needed , then this design pattern should be paired with OWTDP -4A, 2883  \n4B, or 4C if the Impl ementation B diode is a SDS. 2884  \nIf used in situations where non -attribution is critical then the low side software and hardware 2885  \ncomponents (inclu ding Diode A ) should be not attributable to the organization or to the country.  2886  \nThis is the preferred OWTDP for no n-attribution environments.  In non -attribution environments 2887  \nit is recommended that the Implementation A pitcher not do any content filtering or 2888  \nmanipulation.  Essentially the Implementation A pitcher  should acquire the data, package it so it 2889  \ncan go over the diode, and then send it  to the diode . Please contact the NCDSMO if you are 2890  \nimplementing this approach for non -attribution environments.  2891UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OF", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}242{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "241", "chunk": "FICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 115 of 397 8.4.3  OWTDP -4: Multi -Domain CDS w/ High Thre at Connections  Pattern s 2892  \nThis set of design patterns describes how to use a software CDS , usually one that supports 3 or 2893  \nmore domains,  in combination with pitcher/diode/ catcher systems to support unidirectional  and 2894  \nbidirectional  data flows.  2895  \nIn the following design patterns the catcher for the l ow-to-high and pitcher for high -to-low data 2896  \nflows, must be a separate device from the multi -domain CDS. Inserting diodes into the multi - 2897  \ndomain CDS is not allowed.  The first multi -domain CDS must be directly ph ysically connected 2898  \nto the second multi -domain CDS via a cross -over cable . A private switch may be used if multiple 2899  \nmulti -domain CDS are used with a load -balancer.  2900  \nIn this set of design patterns, Diode Solution A and Diode Solution B  are independently 2901  \nimplemented RTB compliant pitcher/ diode/ catcher CDS . The actual physical diode 2902  \n(including software drivers) can be  the same, but the software CDS implementations around 2903  \nthem must be different.  The Simple Diode Solution is not a RTB compliant CDS . 2904  \nDesign patterns 4a and 4c a", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}243{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "242", "chunk": "re intended to be able to support bidirectional  communications.  In 2905  \nL2H query/response communication if the low side catcher needs to communicate with the low 2906  \nside pitcher via a direct network side channel (e.g. , Ethernet cro ss-over cable)  in order to support 2907  \nrouting the response back to the sender then that is allowed. The inverse is also allowed where a 2908  \nrequest from high to low is sent down, the low side catcher could communicate via a network 2909  \nside channel to the L2H pitcher  to send the query response back up.   2910  \n  2911UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 116 of 397 8.4.4  OWTDP -4a: Multi -Domain CDS w/ High Threat Connections Pattern (Bi - 2912  \nDirectional ) 2913  \n 2914  \nFigure 29 \u2013 OWTDP -4a: Multi -Domain CDS w/ High Threat Connections Pattern  (Bi-Directional)  2915  \nThis pattern is used in scenarios  where two or more domains nee d to be connected to a CDS and 2916  \none or more of the domains is an Unclassified network or a n HTN . This pattern includes the use 2917  \nof hardware -based  separation and a multi -domain software CDS.   If t", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}244{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "243", "chunk": "he HTN needs bidirectional  2918  \ncommunications, then separate  independe nt implementations  are needed for the 2919  \nPitcher/ Diode/ Catcher solution.  2920  \nHowever, the low -(from Unclassified or HTN) -to-high Pitcher/Di ode/Catcher solution does not 2921  \nneed to be a softw are CDS and thus RTB compliant \u2013 essentially the low -to-high diode solution 2922  \ncan be a simple pitcher that receives the data, packages it up and sends over the diode to the 2923  \ncatcher which in turn delivers it to the software CDS. The low -to-high Pitcher/Diode/Catcher in 2924  \nthis case is providing hardware enforced independent domain separation. The Catcher  must 2925  \nterminate  the low -to-high transport protocol (typically UDP/IP) and reconstruct to reduce 2926  \nprotocol level attacks against the multi -domain CDS. The high -to-low Pitcher/D iode/Catcher 2927  \nsolution must be an RTB compliant Pitcher /Diode/Catcher CDS.  2928  \nThe classified HTN can not use the same  Pitcher/ Catcher filtering  software that would normally 2929  \nbe used in the high domain. The classified HTN  must use the low side software  that is us ed in the 2930  \nunclassified HTN .  If the diode solution implements hardware -based  filtering ( e.g., in an FPGA) , 2931  \nthen two vendors might not be necess", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}245{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "244", "chunk": "ary depending on an analysis by NSA of the approach  used.   2932UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 117 of 397 8.4.5  OWTDP -4b: Multi -Domain CDS w/ High Threat Connections  Pattern (Uni - 2933  \nDirectional)  2934  \n  2935  \nFigure 30 \u2013 OWTDP -4b: Multi -Domain CDS w/ High Threat Connections Pattern  (Uni-Directional ) 2936  \nThis pattern is used in scenarios  where two or more domains nee d to be connected to a CDS and 2937  \none or more of the domains is an Unclassified network or a n HTN.  This pattern includes the use 2938  \nof hardware -based  separation and a multi -domain software CDS. This pattern is unidirectional , 2939  \nfor connections from the HTN, and shall only be used for transfers fro m Low to High.  However, 2940  \nas shown in Figure 30, the moderate threat and low threat domain may use the multi -domain 2941  \nsoftware CDS to communicate bidirectional ly with each other.  2942  \nIn this pattern , the pitcher and catcher are not required to  be a software CDS an d thus RTB 2943  \ncompliant. The Catcher must terminate the low -to-high transport protocol (typically UDP/IP) and ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}246{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "245", "chunk": "2944  \nreconstruct to reduce protocol level attacks against the multi -domain CDS. The 2945  \nPitcher/Diode/Catcher system is simply providing the  redundant , independent and hardware 2946  \nenforced domain separation.  However, it is strongly recommend ed that some basic filtering be 2947  \nperformed  on the pitche r so that content can \u201cfail fast\u201d and the  sender can be notified in the 2948  \norigin domain that content was not transferred.  2949  \nThe diode solution may implement  hardware -based  filtering ( e.g., in an FPGA ) to reduce the 2950  \nattacks against the multi -domain CDS.  2951  \n 2952UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 118 of 397 8.4.6  OWTDP -4c:  Dual Multi -Domain CDS w/ High Threat Connections Pattern (Bi - 2953  \nDirectional ) 2954  \n 2955  \nFigure 31 \u2013 OWTDP -4c: Dual Multi -Domain CDS w/ High Threat Connections Pattern (Bi -Dir) \u2013 Option 1  2956  \n 2957UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}247{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "246", "chunk": " 119 of 397  2958  \nFigure 32 \u2013 OWTDP -4c: Dual Multi -Domain CDS w/High Threat Connections Pattern (Bi -Dir) \u2013 Option 2  2959  \n 2960  \n 2961  \n  2962UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 120 of 397  2963  \n 2964  \nFigure 33 \u2013 OWTDP -4c: Dual Multi -Domain CDS + Commercial Filtering Appliance w/High Threat 2965  \nConnections Pattern (Bi -Dir) \u2013 Option 3  2966  \n 2967UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 121 of 397  2968  \nFigure 34 \u2013 OWTDP -4c: Multi -Domain CDS + CDS Inte grated with Diode  w/High Threat Connections 2969  \nPattern (Bi -Dir) \u2013 Option 4 2970  \nThis pattern is generally used in scenarios  where two or more domains nee d to be connected to a 2971  \nCDS and one  or more of the domains is an Unclassified network or a n HTN. This pattern 2972  \nincludes the use of hardware -based  separation and two independently implemented multi -domain 2973  \nsoftware CDS  (see variant  below) . This pattern is bidirec", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}248{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "247", "chunk": "tional . The two software CDS must be 2974  \ndifferent independently developed CDS implementati ons with different filtering 2975  \nimplementations.  The use of the second independent CDS system is intended to handle the 2976  \nsituation where , if the upward path is compromised  then the downward path is not automatically 2977  \ncompromised due to use of the same technolog y (e.g. , filters and protocol adapters).  The second 2978  \nmulti -domain software CDS, could be a software CDS or a commercial filtering appliance (with 2979  \nsome caveats) . In Option 3, where the same CDS implementation is used, there is a second 2980  \nfiltering appliance in  place to ensure that a compromise of the upward path does not result in a 2981  \ncompromise of the downward path. The options are described in more detail below : 2982  \nOption 1  allows for three variations for the second CDS:  2983  \n1. Implementation B is a completely different RTB compliant CDS with different filters 2984  \nand protocol adapters from implement ation  A. 2985  \n2. Implementation A\u2019 (pronounced \u201cA prime\u201d) is a modified version of Impl ementation 2986  \nA but all the filters  and protocol adapters  between A and A\u2019 must be different.  If 2987UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}249{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "248", "chunk": ", KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 122 of 397 the same rules engine is invoking the fil ters directly (e.g. , via fork/exec or directly 2988  \nlinked into the rules engine) then the rules engine also must be a different 2989  \nimplementation.  If using the same CDS platform , but with different filters  and 2990  \nprotocol adapters , is being considered  then this must be reviewed  and approved by the 2991  \nNCDSMO first .  Implementation A\u2019 must be physically in -line (with no extra  2992  \nnetwork connections  other than to a DCO log receiver ) between Implementation A 2993  \nCDS and the H2L pitcher.  2994  \n3. A commercial filtering appliance (e.g., XML firewall) could be implement ed as the  2995  \nthird independent filtering system. The commercial content filtering appliance must 2996  \nbe physically in -line (with no extra network connections  other than  to a DCO log 2997  \nreceiver ) between the Implementation  A CDS and the H2L pitcher. The filters must 2998  \nbe independent implementations of the CDS and use of a different operating  system  is 2999  \nstrongly encouraged.  This must be reviewed and approved by  the NCDSMO first.  3000  \nOption 1  is typicall", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}250{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "249", "chunk": "y used in situations such as  bidirectional  request/response systems (e.g. , 3001  \nWeb Services) where a request is sent to a high side system and the high side system  needs to 3002  \nrespond back to the requestor  on the low side. The pattern can also be used in high to low 3003  \nquery/response systems that need to return a response back to sender on high.  3004  \nIn Option 1, the moderate threat and low threat environments are only connect ed to CDS 3005  \nImplementation A. CDS Implementation A has bidirectional  communication with 3006  \nImplementation A\u2019/B/Commercial Filtering Appliance.  3007  \nOption 2  is similar to Option 1  Variant 1 but the Implementation A\u2019 or B CDS is directly 3008  \nconnected to the domains  and Implementation A does not communicate directly with 3009  \nImplementation A\u2019 or B . Because A\u2019 or B  are different from Implementation A , it does not 3010  \nneed to be physically in -line with Implementation A.   3011  \nOption 3  allows the Implementation A CDS to  be used instead of A\u2019  or B but requires  a 3012  \ncommercial filtering appliance between it and the H2L pitcher. In this option a second 3013  \nphysical instance of the Implementation A CDS is used  in line  with a commercial content 3014  \nfiltering appliance to implement the rule o f three.", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}251{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "250", "chunk": "  3015  \nOption 4  integrates a second physical CDS (Implementation B). The Implementation B is a n 3016  \nOWTDP -1 compliant CDS.  3017  \nImplementations A, A\u2019, and B and the commercial content filtering system must be on physically 3018  \nseparate servers  \u2013 shared hardware is n ot allowed.  Virtualizing the CDS  or the commercial 3019  \ncontent filtering system  is not allowed.  3020  \nThe Catcher attached to the software CDS must terminate the low -to-high transport protocol 3021  \n(typically UDP/IP) and construct a UDP or TCP connection to the software CDS  to reduce 3022  \nprotocol level attacks against the multi -domain CDS.  3023  \nIn this pattern, the pitcher and catcher are not required to be a software CDS and thus RTB 3024  \ncompliant. The Pitcher/Diode/Catcher system is simply providing the redundant, independe nt 3025  \nand hardware enforced domain separation. However, it is strongly recommended that some basic 3026UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 123 of 397 filtering be performed on the pitcher so that content can \u201cfail fast\u201d and the sender can be notified 3027  \nin the origin d", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}252{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "251", "chunk": "omain that content was not transferred.  3028  \nThe diode solution s may implement  hardware -based  filtering ( e.g., in an FPGA ) to reduce the 3029  \nattacks against the multi -domain CDS.  3030  \n 3031  \n8.4.7  OWTDP -5: Connections between Unclassified Networks  or HTNs Pattern  3032  \n 3033  \nFigure 35 \u2013 OWTDP -5 Architecture  3034  \nThis pattern covers connection s between an Unclassified Network and a HTN or between two 3035  \nHTNs.  This solution is connecting t wo Traditional Diode Solutions  (see OWTDP -1) back -to- 3036  \nback  with the high sides of the traditional diode solu tion connected together.  This approach 3037  \nresults on the low, and thus likely compromised side, as the only part of the solution that is 3038  \nexposed directly to the two HTNs.  This pattern is intended to protect the details of 3039  \nimplementations B and C and thus all ow the reuse of existing CDS solutions for connecting two 3040  \nHTNs.  3041  \n 3042  \n  3043UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 124 of 397 8.4.8  OWTDP -6:  One Way Transfer with Hardware Filtering  3044  \n 3045  \n 3046  \nFigure 36 \u2013 OWT", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}253{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "252", "chunk": "DP -6: One Way Transfer with H/W Filtering  3047  \nThis design patte rn is used to transfer data uni directional ly but with the added security benefit of 3048  \nhardware -based  filtering. In this pattern, software -based  filtering is still required on the Pitcher 3049  \nand Catcher. Typically , the software component s focus on content normalizat ion/ 3050  \ndenormalization and data hiding and data disclosure issues. Normalized data is generally easier 3051  \nto process in hardware. Well impleme nted filters for data hiding and disclosure in hardware are 3052  \ntechnically doable, but it substantially increases the complexity of the logic. If the hardware can 3053  \nsufficiently validate the syntactic and semantic aspects of the  normalized data, it will 3054  \ndramati cally reduce the data attack risk  of data from the originating domain compromising the 3055  \nfilters in the destination domain.  Solutions implementing robust hardware -based  filtering , along 3056  \nwith the appropriate software -based  filtering , can be used from U to TS SCI. These  solutions 3057  \nusually implement ADP -2, ADP -3, or ADP -4 for the software components of the filtering.  3058  \nHardware filtering solution should rely on the software to perform  audit and logging.  The use of 3059  \nhardwa", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}254{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "253", "chunk": "re -based  filtering is strongly encouraged and  will be required in future revisions of this 3060  \ndocument for connections from Unclassified and HTN to USG classified NSS . 3061  \n 3062UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 125 of 397 8.4.9  OWTDP -7:  Bi-Directional Transfer with Hardware Filtering  3063  \n 3064  \nFigure 37 \u2013 OWTDP -7a: Bi -Directional Transfer with H/W Filtering  3065  \n 3066  \nFigure 38 \u2013 OWTDP -7b Bi -Directional with an HCFD & Multi -Domain CDS  3067  \nDesign pattern OWTDP -7 patterns are  bidirectional version s of the OWTDP -6 pattern. The 3068  \nhardware filtering  logic can be the same for each direction, though the rulesets might be different 3069  \ndepending on the data being transferred. Unlike the OWTDP -2, where the high side Pitcher must 3070  \nimplement a third independent software -based filtering solution, the use of robu st hardware - 3071  \nbased filtering eliminates the need for the third independent filtering solution. The hardware 3072  \nfiltering must support full syntactic and semantic filtering of the data. However, the hardware - 3073  \nbased filtering ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}255{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "254", "chunk": "does not eliminate the need for softw are-based filtering on the Pitchers and 3074  \nCatchers.  The filters on pitcher/catcher implementations  A and B must be different. These  3075  \ndesign pattern s can be implemented in two separate FPGAs or a single large FPGA. In both 3076UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 126 of 397 cases, each data flow path has its own unique diode and filter(s) instances.  3077  \nOWTDP -7a Variant:  3078  \nIn this variant,  Implementation A pitcher/catcher can be combined on same physical dev ice and 3079  \nImplementation B pitcher/catcher can be combined on the same physical device.  3080  \nNon-security relevant n ormalization and denormalization functions can remain on the low side.  3081  \nOWTDP -7b Variant:  3082  \nIn this variant,  the high side pitcher/catcher is rep laced with a multi -domain software CDS.  The 3083  \nuse of the HCFD\u2019s syntactic and semantic filtering reduces the attack surface against the multi - 3084  \ndomain CDS allowing it to communicate bidirectionally with the HTN without the  complexity of 3085  \nOWTDP -4c. The simple diode/catcher (on lo", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}256{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "255", "chunk": "w side) is performing two functions:  3086  \n\u2022 Protocol Handling from/to the low side environment  3087  \n\u2022 Non-security relevant normalization (upward path) and denormalization  (downward path)  3088  \n 3089  \n8.4.10  OWTDP -8:  PCIe Card based Pitcher and Catchers  (Supplemental Design 3090  \nPattern)  3091  \n 3092  \nFigure 39 \u2013 OWTDP -8 PCIe Card Based Pitchers and Catchers  3093  \nThis is a supplemental design pattern to the above CDS ADPs. In this approach the pitchers and 3094UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 127 of 397 catchers are implemented on PCI Express card s and embedded inside of a software CDS  running 3095  \non commodity hardware . This approach is particularly useful in environments where the inbound 3096  \ndata is already UDP and thus can be sent dir ectly to the FPGA and in environments where  the 3097  \npitcher/catcher can be  simple enough that a low power ARM\u00ae CPU can be used  for protocol 3098  \ntermination.  3099  \nSolutions implementing these cards shall adhere  to the following requirements:  3100  \n1. All interaction to/from the card must be fully under the control o", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}257{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "256", "chunk": "f the FPGA.  3101  \n2. All PCIe logic, filters,  protocol filtering  diode logic, and Ethernet controller logic must be 3102  \nimplemented in VHDL.  3103  \na. PCIe logic communicating  with the host computer must be sepa rate logic blocks 3104  \nfrom the PCIe logic used to communicate with the Commodity CPU.  3105  \nb. The use of soft core CPUs  in the FPGA for filtering or data flow enforcement  are 3106  \nprohibited.  But they can be used for OSI Network Layer98 (e.g., IP) and above 3107  \nprotocol te rmination . 3108  \n3. The Commodity CPU must be physically independent of the  FPGA and must have no 3109  \ncontrol over the F PGA.  The Commodity CPU must be on a separate die99 from the 3110  \nFPGA.  3111  \n4. All VHDL bitstreams must be digitally signed and encrypted for each card  type and must 3112  \nbe verified by the card on boot.  3113  \n5. The Commodity CPU shall  only communicate with the host computer via the FPGA.  3114  \n6. The Commodity CPU may boot off a dedicated removable  flash  memory  card (e.g., SD).  3115  \n7. The Commodity CPU may boot off read -only storage un der the control of the FPGA.  3116  \na. The host computer may provide  the Commodity CPU software image ; however , 3117  \nthe image must be digitally  signed and the FPGA must validate  that the  sig", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}258{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "257", "chunk": "ned 3118  \nsoftware image is intended to run on this  Commodity CPU.  3119  \nb. Each Commodity CPU  must have its own digitally signed software image.  3120  \n8. The PCIe card shall be configured on system boot by the host computer using digitally 3121  \nsigned images.  3122  \n8.4.11  Special Circumstances OWT Requirements  3123  \nThere are two special circumstances where the RAIN filtering req uirements do not necessar ily 3124  \napply: intelligence data collection and DCO of CDS.  In these circumstances, the data is being 3125  \ntransfer red to a network and systems capable of safely handling dirty (e.g. , malicious) data. If 3126  \ncontent is filtered then critical data might not be delivered (e.g. , failed filtering) or the data might 3127  \nbe altered in such a way (e.g ., due to the filtering technique used) that its intelligence or 3128  \ndefensive value is reduced or elimin ated ( e.g., removal of steganographi c encoded information or 3129  \nan impl ant). In these case s, the purpose of the OWT device is to deliver the content from low to 3130  \n \n98 https://www.imperva.com/learn/wp -content/uploads/sites/13/2020/02/OSI -vs.-TCPIP -models.jpg  \n99 https://en.wikipedia.org/wiki/Die_(integrated_circuit)UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}259{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "258", "chunk": "JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 128 of 397 high as quickly and reliably as possible with no possibility of a back -channel . Therefore, the 3131  \nfiltering requirements for the data may be waved in these situations.  However , it is NOT 3132  \nappropriate for the transmission of data to a high side networ k where the end system cannot  3133  \nprotect itself from accidental detonation of potential malware.    3134  \nOWTDP -1 and OWTDP -3 design patterns are the primary patterns used in these two 3135  \ncircumstances.  3136  \nFor these uses, it is strongly recommended that the content be obfuscated and wrapped so that 3137  \naccidental detonation of the potentially malicious files does not occur on the d estination network. 3138  \nThe NCDSMO Suspect File Transmission Format (SFTF) Specification  (Doc ID: NCDSMO -S- 3139  \n00003 -002_01) is specifically designed to support the safe transfer of potentially malicious files 3140  \nthrough a CDS to a safe analysis environment  and should be considered as an option in these use 3141  \ncases.   3142UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED/", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}260{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "259", "chunk": "/FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 129 of 397 9 General Requirements  3143  \nThis section covers the general requirements for a CDS . 3144  \nA requirement that applies only to Datacenter CDS will be prefixed with [ DCCDS  (when it 3145  \napplies to all DCCDS  transfer types) , DCCDS -FF, DCCDS -SD, or DCCDS -CD]; if it only 3146  \napplies to a Tactical CDS , it will be prefixed with [TCDS] ; if it applies to both , then no prefix 3147  \nwill be provided . Additionally, the unique requirements for the four different CDS 3148  \nimplementati on models  will be identified by  having  the name of that  CDS implementation model 3149  \nadded to the CDS Class (e.g., DCCDS /TSB) . If the  CDS implementation  model does not appear, 3150  \nthen the requirement applies to all models.  If a ~ appears prior to a CDS class/model 3151  \ncombination , the requirement does not apply to that combination.  If an * appears as part of the 3152  \nCDS class/model combination , it means the requirement  matches all of that class or model.  For 3153  \nexample, ~ TCDS/ HB would mean the requirement  does not apply to Hardware Based Tactical 3154  \nCDS and ~*/TSB would mean it does not  apply to any class  with a TSB model, while DCCDS - 3155 ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}261{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "260", "chunk": " \nFF/* means that  it applies to  all models for the DCCDS -FF class . If a ^ appears prior to a CDS 3156  \nclass/model combi nation, the requirement is a SHOULD for th at class/model .  3157  \nIf a requirement has class/model combinations and also has sub -requirements, then unless 3158  \notherwise marked those sub -requirements apply to the stated class/model combinations on the 3159  \nparent requirements.  3160  \nIf a hardware -based CDS has software based components (e.g., a softcore running a protocol 3161  \nadapter or a software -based CDS management system) then any  software related  requi rements 3162  \nthat have a [~*/HB] exception for hardware -based CDS do apply  to the software components.   3163  \nIf a top -level (single digit) requirement (e.g., OSSR -20) is a MAY or SHOULD but not a 3164  \nSHALL and it has subordinate requirements (e.g., OSSR -20.1, OSSR -20.2, and OSSR -20.3) , 3165  \nthen those requirements do not apply unless the top-level  requirement is implemented.   3166  \nThe requirements in this document are hierarchical  in nature. If the parent requirement (e.g., 2.0) 3167  \ndoes not apply then the sub -requirements (e.g. , 2.1, 2.2, and 2.3) do not apply. For example, 3168  \nOSSR -20 is about implemente d NTP support on the CDS. If the CDS developer im", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}262{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "261", "chunk": "plements 3169  \nNTP support then OSSR -20, OSSR -20.1, OSSR -20.2, OSSR-20.3, and OSSR -20.4 apply (unless 3170  \notherwise stated).  If the parent requirement is a SHOULD or a MAY  and it is implemented in the 3171  \nCDS and the child requirements are SHALL then they must be implemented if the parent is 3172  \nimplemented.  3173  \nSome requirements may have rationale , clarification , or testing  paragraphs after them . 3174  \nRationale is used to explain why the requirement exists or why it is written a c ertain way. 3175  \nClarification provides amplifying  guidance on how to implement the requirement. Testing 3176  \nprovides specific guidance to testers for a requirement . The Threats and Weakness ( T&W ) line 3177  \nare the mapping s discussed in Section  Threat and Weakness (T&W) Mapping -.  3178UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 130 of 397 9.1 Safety Requirements  (SR) 3179  \nCDS technologies that introduce a safety risk or risk to human life require additional 3180  \nqualification testing and validation of safety controls ( e.g., DO-178B/178C100) that will not be 3181  \ncovered herein. T", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}263{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "262", "chunk": "hese considerations are outside of the scope of this document.  3182  \n9.2 Training  Requirements  (TR) 3183  \nTR-1 The CDS developer  shall  develop in-person and electron ic training courses that cover 3184  \nsystem installation , system configuratio n including configuration of the dataflow  policy, 3185  \nroutine operations  and maintenance activities , disaster recovery, performance monitoring, 3186  \nlog analysis , dataflow  troubleshooting,  end u ser training , and DCO101 of the CDS . 3187  \nTR-2 The CDS developer shall have the ability to support training onsite at the customer . In 3188  \ncases, where the CDS is deployed at multiple sites the training can be provide d a single 3189  \nlocation.  3190  \nTR-3 The CDS developer shall provide digital  training materials  (e.g., computer -based  training, 3191  \nvideos, documentation ) that cover all the required training material with the 3192  \ndelivery /installation  of the CDS.  3193  \nTR-4 The CDS developer shall  provide  a mechanism for customer s to receive  annual refresher 3194  \ntraining that cover s all the required training material.  3195  \nTR-5 The CDS developer shall develop  and provide  a training course and certification process to 3196  \ntrain and certify CDS administrators and CDS filter policy developers", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}264{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "263", "chunk": " (for those CDS 3197  \nthat support user/s ite developed ruleset).  3198  \nTR-6 The CDS developer shall provide  a training course and documentation on how to create 3199  \nand validate filter polic ies for their CDS .  3200  \nClarification:  This course is intended for both the customer purchasing the CDS and the 3201  \nauthorizing official\u2019s staff responsible for review ing and approving filter policies.  3202  \nTR-6.1 For programmable ruleset -based parsers, the CD S developer shall provide a reference 3203  \nmanual describing the language and all defined functions.  3204  \nClarification:  Programmable  ruleset -based parsers are typically used for fixed format 3205  \ndata parsing . 3206  \nTR-6.2 For programmable ruleset -based parsers, the CDS developer shall provide a 3207  \nprogramming manual that describes how to use the language to develop rulesets.  3208  \nTR-6.2.1 The programming manual mu st contain examples that exercise  the full capabilities of 3209  \n \n100 That can be obtained fro m https://www.rtca.org/standards  \n101 Sometimes called Computer Network Defense (CND).UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}265{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "264", "chunk": "SAU, SWE, QAT  \nPage 131 of 397 the languages and functions provided .  3210  \n9.3 CDS Throughput Requirements  3211  \nDataflow throughput requirements shall be provided separately from this document  and will be 3212  \nbased on specific program requirements . When provided, CDS throughput requirements should  3213  \nbe expressed as: the number of messages , of a specific type/size/complexity , per unit of time. 3214  \nSystem throughput requirements should take into account wh ether encryption is being used for 3215  \ntransport to/from the CDS. The use of bits/second is generally not an effective approa ch to 3216  \nmeasuring CDS performance .102 3217  \n9.4 CDS Latency Requirements  3218  \nDataflow  latency requirements shall be provided separately from this document.  Latency 3219  \nrequirements should be  expressed in milliseconds  per data type  per data flow . In a system that 3220  \nincludes a CDS, latency needs to be allocated to the CDS to account for the time i t takes CDS 3221  \nfunctions to execute.  The allotted latency time may vary by protocol type and/or message type.  3222  \n9.5 CDS Availability Requirements  3223  \nSystem availability requirements shall be provided separately from this document  and will be 3224  \nbased on specific progra m requirements . 3225  \n9", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}266{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "265", "chunk": ".6 Preventative Maintenance Requirements  (PMR)  3226  \nPMR -1 The CDS  design shall support  all Preventative Maintenance functions being performed  3227  \nat the system operating location or organization\u2019s depot facility.  3228  \nClarification: Preventative Maintenance includes installation of software and hardware 3229  \nupdates, review and backup of system logs, and other actions required to maintain  the 3230  \nsecurity and availability of the sy stem. Remote management may be used to 3231  \naccomplish these tasks.  This does not preclude other requirements, as stated in this 3232  \ndocument, related to remote management of the CDS.  3233  \n9.7 Network Cabling Requirements (NCR)  3234  \nNCR -1  [TCDS/*] USB cables connected to the CDS system should be secured  using MIL -DTL - 3235  \n38999M connectors.  3236  \nNCR -2 [TCDS/*] Communications interfaces  connected to the CDS  system should  be secured  3237  \n \n102 In the past, bits per second has been used as a performance requirement for CDS, but this is largely a useless \nnumber since the vast majority of CDS do not operate on ind ividual packets of data. Transfer CDS operate on \ndiscrete chunks/strings of data.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCL", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}267{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "266", "chunk": "ASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 132 of 397 using  connectors and techniques specified in  MIL-DTL-38999 Revision M  with 3238  \nAmendment 2 or higher . 3239  \n9.8 Network ing Related Requirements (NRR)  3240  \nThis section only applies to CDS that have network connections including Ethernet or 3241  \nAsynchronous Transfer Mode (ATM) .  3242  \nNRR -1 All CDS  operating system s and applications shall support both Ipv4 and I pv6 3243  \nnetworking stacks  however , which ones are active  for a specific installation  depends on 3244  \nthe operational environment of the CDS.  3245  \nNRR -2 [DCCDS]  Transfer and MLS CDS shall support, at minimum, four physical network  3246  \ninterfaces:  two for dataflows, one for management, and one for DCO.  In OWT based 3247  \nsystems , the pitcher  and catcher will each have four network interfaces including the 3248  \nOWT connection.  3249  \nNRR -3 [TCDS] Transfer and MLS CDS shall support, at minimum, three  physical network 3250  \ninterfaces:  two for dataflows, and one for management  and DCO.  3251  \nNRR -4 [ACDS] Access CDS should  support, at minimum, two physical network interfaces:  one 3252  \nfor dataflows and one for management  and monitoring . 3253  \nNRR -4.1", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}268{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "267", "chunk": " [ACDS]  If an Access CDS has only one physical interface it shall support remote 3254  \nmanagement a nd monitoring via NSA\u2019s Commercial Solutions for Classified  approved 3255  \nencrypted tunnels  (e.g., IPSEC, MACSEC) . 3256  \nNRR -5 The CDS shall have a management interface that is  treated as system high  except for the 3257  \nlow side management network  interface of a OWT  solution.  3258  \nNRR -6 Deleted . 3259  \nNRR -7  CDS  may use IPSEC  or MACSEC  virtual private network  (VPN)  software to provide 3260  \ncryptographic separation for CDS remote management and monitoring functions v ia the 3261  \nsystem high dataflow network . 3262  \nClarification:  An IPSEC or MACSEC VPN is not allowed to be used for tunneling the 3263  \nmanagement interface of  the high side pitchers and catchers in design patterns OWT - 3264  \n4a, 4b, and 4c . 3265  \nNRR -7.1 The VPN software shall use a Federal Information Processing Standard (FIPS) 140 -2 3266  \nor 140 -3 validated Commercial National Security Algorithm  (CNSA)  implementation 3267  \nand the virtual private network software shall  be evaluated against the appropriate 3268  \nNational Informa tion Assurance Program (NIAP ) protection profile104. 3269  \n \n104 See https://www.niap -ccevs.org , NIAP  PP-Module for VPN Client  v2.2 or hi", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}269{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "268", "chunk": "gher for IPSEC or Extended \nPackage for MACsec Ethernet Encryption Version 1.2UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 133 of 397 NRR -7.2 The remote management and remote monitoring functions should each use  a dedicated 3270  \nphysical network  interface .  3271  \nClarification: The remote management and monitoring interface s would then be 3272  \nconnected to the same physical network as the system high dataflow network 3273  \ninterface,  but communications  would be separated from the dataflow netw ork via the 3274  \nIPSEC and MACSEC  tunnel.  3275  \nNRR -8 Network interface controllers (NIC) shall not be shared between network interfaces.   3276  \nClarification:  For example,  in a multi -port Ethernet card each physical interface must 3277  \nhave its own Ethernet controller.  A multi -port Ethernet card with a single controller 3278  \ncan be connected to a single security domain for the purpose of link-bonding (i.e., 3279  \nlink aggregation)  the channels to improve throughput , redundancy/failover, or both .105  3280  \nRationale:  If a shared Ethernet controller is used to connect to multiple s", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}270{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "269", "chunk": "ecurity domains, 3281  \nthen if that controller is remotely exploited it would be possible for an attacker to 3282  \nmove between different security domains without ever compromising the actual CDS 3283  \nsystem.   See CVE -2021 -33126  and CVE -2022 -33128  as examples of the problems 3284  \nwith Ethernet controllers106. 3285  \nNRR -8.1 A shared multi -port Ethernet  controller may be used when the interfaces to the high 3286  \nside mission network, CDS monitoring OOB network, and CDS management  OOB 3287  \nnetworks are the same security level . 3288  \nClarification:   The mission network, monitoring OOB, and management OOB 3289  \nconnections must still use separat e network interfaces  \u2013 this requirements only allows 3290  \nthe use a common Ethernet controller.  3291  \nNRR -9  [DCCDS/*]  The CDS may provide a network -based mechanism to support load 3292  \nbalancing and failover (LBF) of the CDS . If the CDS implements support for load 3293  \nbalancing and failover , the following requirements apply:  3294  \nNRR -9.1 The LB F process shall be implemented a s a single -purpose process.  3295  \nNRR -9.2 A separate instantiation of the LBF process must  exist for each network interface 3296  \n(includi ng management network interface) for which LBF information will be provided.  32", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}271{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "270", "chunk": "97  \nNRR -9.3 The LBF process shall support TCP connections , using  a non-privileged port ( e.g., > 3298  \n1023 ) for providing systems load and dataflow up/down status.  3299  \nNRR -9.4 The LBF process shall implement the security requirements for Protocol Adapters 3300  \ndescribed in the Protocol Adapter Requirements (PAR) section  of this document.  3301  \n \n105 https://en.wikipedia.org/wiki/Link_aggregation  \n106 See https://cve.mitre.org/cgi -bin/cvekey.cgi?keyword=ethernet + for even more exmaples of security problems \nwith Ethernet controllers and drivers.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 134 of 397 NRR -9.5 The LBF process shall get system  load and dataflow up/down status  via an approved 3302  \none-way IPC (see OSSR -27). This information should  be provided by the Event Manager 3303  \nin the JALSR subsystem.  3304  \nNRR -9.6 The LBF process shall not provide dataflow ID or configuration information . 3305  \nNRR -9.7 The LBF process  shall use a dedicated TCP port to provide the system load and the 3306  \nsystem load will be provided as a single 8-bit signed integer  followed by a Ca", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}272{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "271", "chunk": "rriage 3307  \nReturn (CR)  and a disconnect.  3308  \nNRR -9.7.1 Valid values for system load shall  be 0 to 127 and a -1 will be used to indicate the 3309  \nnetwork interface should be consider ed offline.  3310  \nClarification:  If the load value is -1, then the CDS should be considered offline for that 3311  \nnetwork interface and the load balancer should check the CDS periodically to 3312  \ndetermine  if the CDS is online.  How the load is calculated is proprietary to the CDS. 3313  \nThe CDS developer should provide  a docum ent that explains how to interpret the load 3314  \nvalue.  For example, a load value could be a combination of CPU load, memory 3315  \nutilization, network and disk I/O rates, number of filters that are busy, available disk 3316  \nspace,  and fullness of a processing pipeline . While it can simply be a n integer version 3317  \nof the CPU load , that is not recommended.  3318  \nNRR -9.8  To reduce the potential for a  Denial -of-Service (DoS), the LBF process should  not 3319  \nrespond to LBF queries faster than once every 1 second . 3320  \nNRR -9.9  The LBF Process may open  a series of monotonically increasing  non-privileged 3321  \n(>1023 ) TCP socket ports for each d ataflow to represent which data flows are active and 3322  \nprovide a response of \u201cUP\u201d ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}273{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "272", "chunk": "and disconnect the connection.  If the dataflow is down , then 3323  \na response of \u201cDOWN\u201d will be provided and the connection is disconnected .107 No other 3324  \ninformation about the dataflow shall be provided.   3325  \nClarification:  In this case the load balancer is monitoring a series of ports to represent a 3326  \nset of dataflows without monitoring  the real dataflow port ( e.g., the real port is 443, 3327  \nbut it is moni toring ports 10001 -10005 to represent the dataflows that are using 443). 3328  \nThis is done because many of the protocols that a CDS may be hosting may not have 3329  \na mechanism to query to indicate if it is operating or the CDS may be using mutually 3330  \nauthenticated TL S connections and the load balancer would not be configured with 3331  \nthe TLS certificates in order to protect the integrity and confidentially of the dataflow.  3332  \nThis approach can also be used when the CDS is busy \u2013 if the CDS \u201cdowns\u201d all its 3333  \nflows, the load bal ancer will not send any more traffic to the CDS until the 3334  \nmonitoring ports come back online.  3335  \nNRR -10 The CDS shall have a monitoring  interface  (also called the DCO OOB interface)  and it 3336  \n \n107 This approach has been demonstrate d to be implementable in commercially available load b", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}274{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "273", "chunk": "alancers like F5\u2019s \nBigIP appliances.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 135 of 397 shall  be treated as system high and dirty since it contains potentially malicious  data ( e.g., 3337  \nlogs, journaled data, and quarantined data) . 3338  \nNRR -11 Virtual routing and forwarding (VRF) , VLANs , and VXLANs shall not be used for 3339  \nsecurity separation  in RTB compliant sytems.  3340  \nRationale: These  technologies are not intended for security. They are primarily  for 3341  \ntraffic shaping  and performance . They have  no appreciable security.  3342  \nClarification:  For example, they cannot  be used with OWT -25 to separate the hi gh 3343  \npitcher and high catcher management systems.  They are not sufficient to separate the 3344  \ngray H2L and L2H PDC gray networks in the OWTDPs.   3345UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 136 of 397 10 General Security Requirements  3346  \nThe section covers the general secu", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}275{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "274", "chunk": "rity requirements that apply to most CDS. The s tructure  and 3347  \nassociated terms used to define the  requirements is discussed in the introduction to Section 9 3348  \nGeneral Requirements . 3349  \n10.1 Security Certification Requirements (SCR)  3350  \nSCR -1 The CDS shall be tested via a Lab -Based Security Assessment (LBSA) in an NCDSMO  3351  \nauthorized CDS testing laboratory.  3352  \nSCR-2 The CDS  developer shall categorize and select security controls for use during 3353  \ndevelopment and evaluation in accordance with Committee for National Security 3354  \nSystems Instruction (CNSSI) No. 1253, using the latest version of the CDS Ov erlay 3355  \n1253F, Attachment 3. This subset of security controls is commonly known as the \u201cCDS 3356  \nOverlay\u201d.   3357  \nSCR -2.1 The CDS shall be categorized at a minimum  baseline for Confidentiality, Integrity, and 3358  \nAvailability of High, High, Moderate  as defined in CNSSI No. 1253 . 3359  \nSCR -2.2 The CDS shall implement security controls from the CDS Overlay that map to NIST 3360  \nSP 800 -53 Rev 5 or higher.   3361  \nClarification: When a CDS Overlay security control provides sufficient detail to meet 3362  \nRTB requirements then it is not augmented further in this document. If a requirement 3363  \nin this document conflicts w", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}276{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "275", "chunk": "ith the CNSSI No. 1253 or the CDS Overlay, then this 3364  \ndocument shall be used.  3365  \nSCR -2.3 The CDS developer shall provide documentation mapping the selected security controls 3366  \nto the CDS mechanisms that were implemented to mitigate the threats that necessitated 3367  \nthe selection o f the security control(s).   3368  \nSCR -2.4 Deleted.  3369  \nSCR -3  If a Common Criteria Evaluation and Validation Scheme (CCEVS)  Protection Profile108 3370  \nevaluated component exists and is supported on the operating system of the CDS, th en 3371  \nthat component shall be used instead of a non -CCEVS validated component.  3372  \nSCR -3.1 If the component has been evaluated under a U. S. National Information Assurance 3373  \nPartnership ( NIAP ) protection profile, the U.S. profile version of that component shall  be 3374  \nused.  3375  \nSCR -3.2 If a vulnerability exists in th e NIAP approved component, then patched versions of the 3376  \n \n108 See https://www.niap -ccevs.org . For example, IPSEC based VPN software, Operating Systems, and Full Disk \nEncryption all have Protection Profiles.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, N", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}277{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "276", "chunk": "ATO, NOR, SAU, SWE, QAT  \nPage 137 of 397 NIAP -approved component must be used even if the patches have not been evaluated 3377  \nunder NIAP.  3378  \n10.2 General Architecture Requirements  (GAR)  3379  \nThis section covers some basic architectural requirements and miscellaneous requirements that 3380  \ndid not fit in other sections.  3381  \nGAR -1 The CDS developer shall  design and  implement  the CDS in accordance with  NSA\u2019s 3382  \nRAIN CDS design approach . 3383  \nClarification:  The RAIN design approach primarily applies to content filtering,  dataflow 3384  \npipelines,  domain separation, and process /container/virtual machine  isolation  and 3385  \ncontainment mechanisms. However, in the case of auditing/logging the operating 3386  \nsystem  and CDS subsystem must use independent mechanisms for auditing/logging.  3387  \nRAIN applies to both software and hardware based CDS.  Hardware CDS 3388  \nimplementing filtering must implement redundant and independent filters.  RAIN does 3389  \nnot apply to protocol adapters, n ormalization mechanism (since filters would fail or 3390  \ncorrupt non -normalized data), administrative interfaces, or remote 3391  \nmanagement/monitoring subsystems.    3392  \nGAR -1.1 CDS filters for a given data type or class of data  types109 shall  be re", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}278{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "277", "chunk": "dundant and 3393  \nindependently  implemented by different developers ( i.e., different people  or teams ). 3394  \nClarification: the CDS develop will need to provide documentation demonstrating 3395  \nindependent implementations for the filters.  For example, co mmit logs to the software 3396  \nrepository . This will also be validated by the lab during the site visit and inspection of 3397  \nthe development environment and processes.  3398  \nT&W: WRTB -00020, WRTB -00077 , TRTB -00029, TRTB -00055  3399  \nGAR -1.2 The CDS design shall ensure that filters are always invoked and cannot be bypassed . 3400  \nT&W:  WRTB -00015, CWE -424, WRTB -00031 , CAPEC -554 3401  \nGAR -1.3 [~*/HB]  The CDS shall implement an operating system -enforced DAC  policy  to 3402  \nenforce process isolation , unauthorized file access, unauthorized execution of programs, 3403  \nand prevent filter bypass .  3404  \nT&W: CWE -424, CWE -250, CWE -266, CAPEC -234, CAPEC -554 3405  \nGAR -1.4 [~*/HB, ~*/CCO TS] The CDS shall ensure the  DAC  (e.g., read, write, execute , ACLs ) 3406  \npolicy does not change using an operating system -enforced MAC policy110. 3407  \n \n109 Examples of a cl ass of data types would be images formats (e.g., GIF, BMP, PNG, JPG) or Microsoft Office\u00ae.  \n110 This should not be construed ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}279{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "278", "chunk": "to imply that MAC is just enforcing DAC. MAC is also used to enforce process \nseparation, linear flow, RBAC, exploit containment, and m any other things.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 138 of 397 T&W: WRTB -00020, CWE -471, TRTB -00029  3408  \nGAR -1.5 [*/CCOTS] The CDS may enforce DAC policy using an operating system -enforced 3409  \nMAC policy.  3410  \nGAR -2 All CDS connected  directly or indirectly111 to high threat networks  shall use  a hardware 3411  \nenforced separation  mechanism.   3412  \nT&W:  CWE -119, CWE -203, CWE -200, WRTB -00014, CAPEC -123, CAPEC -189, 3413  \nTRTB -00012  3414  \nGAR -2.1 A hardware -enforced one -way transfer mechanism may be required in other 3415  \nenvironments if the Authorizing Official (AO) determines, thr ough analysis of the attack 3416  \nrisk, that hardware -enforced domain separation  is warranted .  3417  \nRationale:   The hardware enforced one -way transfer mechanism  implements redundancy 3418  \nand independence in the domain separation mechanism along with the software -based  3419  \ndomain separation that is implemented on the pitcher and catch", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}280{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "279", "chunk": "er.  Recent 3420  \nvulnerabilities like the Linux -based Dirty COW 112 (CVE -2016 -5195) and 3421  \nIntel\u00ae /AMD\u00ae /ARM \u00ae CPU Meltdown and Spectre  (i.e., CVE -2017 -5715, CVE - 3422  \n2017 -5753, CVE -2017 -5754) , Foreshadow, Portsmash, ZombieLoad, PlunderVolt,  3423  \nBranchScope,  CVE -2019 -0090, CVE -2017 -5689, CVE -2018 -3657, and CVE 2017 - 3424  \n5712 have clearly shown that commodity operating systems and  hardware are simply 3425  \ntoo complex  to be fully trusted between unclassified and classified USG NSS.  3426  \nGAR -3 If a CDS ingests  non-dataflow  related  data (e.g., CRLs113, LDAP , LDIF , OCSP, etc.) 3427  \nfrom a  source  external to the CDS , then the CDS shall implement two independent  filter s 3428  \nin an assured pipeline between the service ingesting the data and the components within 3429  \nthe CDS that process and use that data .  3430  \nClarification: This is primarily focused on the  automated or manual  import data over the 3431  \nnetwork.  3432  \nT&W: WRTB -00025, CWE -20, WRTB -00020, CAPEC -153 3433  \nGAR -3.1 The filter s shall validate the syntax and semantics of the non -dataflow  related data.  3434  \n \n111 An indirectly connected network is defined as a network that is connected to another network (e.g., a high threat \none in this case) via ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}281{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "280", "chunk": "one or more intermediate networks and across multiple security boundaries through which bi -\ndirection al network traffic (e.g., IP packets) can flow. A company\u2019s development network might be said to be \nindirectly connected to the internet since connections to the internet must first traverse the company\u2019s corporate \nbusiness network and the company\u2019s Intern et-DMZ network. Indirect networks usually have their own DMZ that \nprotects them from the other networks. But fundamentally, the indirectly connected network still has an IP route to \nthe Internet and thus carries the same risks as a directly connected netwo rk.  \n112 https://dirtycow.ninja , https://foreshadowattack.eu , https://spectreattack.com  \n113 See CVE -2020 -1971, CVE -2015 -1789, CVE -2011 -4079 as examples of why this is important.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 139 of 397 T&W:  WRTB -00025, CWE -20, CWE -1286, CWE -228, WRTB -00035 , CAPEC -153 3435  \nGAR -3.2  If non-dataflow data being ingested can be filtered by existing filters on the CDS , then 3436  \nthey may be reused ; however , different instantiation s of the filte", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}282{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "281", "chunk": "rs must be used.  3437  \nRationale:  External data sources  used by the CDS  are susceptible to the same types of 3438  \ncontent -based  attacks as dataflow related data and thus could cause malfunctions or 3439  \ncompromises of the CDS if not sufficiently filtered before processing and use.  3440  \nT&W:  WRTB -00001, WRTB -00036 , TRT B-00023  3441  \nGAR -4 [~*/HB] The CDS shall not utilize commercial  or open source  integrated Host -based 3442  \nIntrusion Prevention Systems (HIPS)  that communicate with servers external to the CDS 3443  \nwithout approval of the NCDSMO . Approval requires  an examination of the HIPS 3444  \nsoftware to determine the risks of using the HIPS on the CDS.  3445  \nRationale:  Commercial HIPS  software pose a substa ntial security risk to the CDS due to 3446  \nuse of proprietary  uninspectable  protocols, the requirement to run with  privilege ( e.g., 3447  \nroot),  the frequent  ability to push software to the system,  and common  incompatibility 3448  \nwith operating system MAC.  3449  \nT&W:  CWE -829, CAPEC -175 3450  \nGAR -5 [~*/HB] The CDS shall implement HIPS functionalit y equivalent to existing commercial 3451  \nHIPS deployed on USG M icrosoft  Windows \u00ae networks.  The following combined sub- 3452  \nrequirements are sufficient to meet the HIPS", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}283{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "282", "chunk": " requirement.  3453  \nGAR -5.1 [~*/HB] The CDS MAC policy shall restrict which programs can operate on the CDS, 3454  \nhow those programs can communicate, and who and what can run those programs and 3455  \nwith what privileges.   3456  \nClarification: MAC polic ies on CDS exceed the core protections offered by commercial 3457  \nHIPS systems . 3458  \nT&W: CWE -653, C APEC -234 3459  \nGAR -5.2 [~*/HB] The CDS shall  implement a mechanism to remotely transfer all audit/log data 3460  \noff the CDS . See requirements in the JALSR section for details  3461  \nGAR -5.3 [~*/HB] The CDS shall implement  an application allowlist ing114 capabilit y to restrict 3462  \nwhich applications can be executed  and by whom  and will cryptographically verify  3463  \napplication s prior to execution .  3464  \nClarification:  Between RTB v1.x and v3.0 this requirement went from a shall  to a 3465  \nshould  back to a shall  due to problems with the availability of suitable allowlisting 3466  \n \n114An application allowlist (previously called application whitelisting)  is a list of applications and application \ncomponents (libraries, configuration files, etc.) that are authorized to be present or active on a host according to a \nwell-defined baseline. https://nvlpubs.nist.gov/nistpubs/specialpublications/n", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}284{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "283", "chunk": "ist .sp.800 -167.pdfUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 140 of 397 tools. This was rectified with the release of fapolicyd115.  The fapolicy - 3467  \nanalyzer116 application can be used to create, edit, analyze, and test fapolicyd 3468  \nconfigurations.  A Linux system with the Linux \u00ae Integrity Measuremen t 3469  \nArchitecture117 (IMA)  in Appraisal mode  (IMA -appraisal)118 and Extended 3470  \nVerification Module (EVM) enabled can also be u sed. IMA -appraisal must be 3471  \nconfigured to measure all operating system and CDS software binaries, libraries and 3472  \nnon-changing supporting files.  3473  \nT&W:  CWE -668, CWE -732, CWE -829, WRTB -00011, WRTB -00020, CAPEC -17, 3474  \nCAPEC -175, CAPEC -640, TRTB -00024  3475  \nGAR -5.3.1 Moved to SIR -11.6. 3476  \nGAR -5.4  [~*/HB]  The CDS shall implement a kernel -based  IP Firewall  to restrict inbound and 3477  \noutbound network connections to only the systems authorized  to connect to the CDS .  3478  \nClarification: On Linux this would be firewalld119 and nftables as the  frontend and 3479  \nnetfilter120 as the backend . nftables replaced ip", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}285{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "284", "chunk": "tables.  3480  \nT&W: CWE -1125, WRTB -00029, TRTB -00034  3481  \nGAR -5.4.1 [~*/HB] The CDS shall have the ability to log all inbound rejected connections.  3482  \nGAR -5.4.2 [~*/HB] The  CDS shall have the ability to log all inbound successful connections.  3483  \nGAR -5.4.3 [~*/HB] The CDS shall have the ability to log all outbound connections.  3484  \nGAR -5.4.4 [~*/HB] The CDS shall, by default, log all rejected and successful inbound 3485  \nconnections to the CDS  3486  \nClarification: UDP based connections from a single host to a specific port may be rolled 3487  \nup to periodic counts. However the periodicity (e.g., how much time between counts) 3488  \nand the max count values must be configurable and there must be a mechanism  in the 3489  \nCDS administrat ion interface  to disable the roll up capability.  UDP packets from a 3490  \nsingle host that are part of established session are not considered a new connections.  3491  \n \n115 See https://github.com/linux -application -whitelisting/fapolicyd  \n116 See https://github.com/ctc -oss/fapolicy -analyzer  \n117 https://www.redhat.com/en/blog/how -use-linux -kernels -integrity -measurement -architecture  and \nhttps://sourceforge.net/p/linux -ima/wiki/Home/  \n118 https://access.redhat.com/documentation/en -\nus/red_hat_enterpris", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}286{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "285", "chunk": "e_linux/8/html/managing_monitoring_and_updating_the_ kernel/enhancing -security -with-the-\nkernel -integrity -subsystem_managing -monitoring -and-updating -the-kernel   and https://sourceforge.net/p/linux -\nima/wiki/Home/#ima -appraisal  \n119 https://firewalld.org  \n120 https://netfilter.orgUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 141 of 397 GAR -5.4.5 [~*/HB] The CDS shall, b y default, log all outbound connections from the CDS.  3492  \nGAR -5.4.6 [~*/HB] If the CDS is running Linux then iptables/nftables shall be configured to log 3493  \nconnections  and use \u201cipfirewall\u201d as the log prefix.121 3494  \nClarification:  A common log prefix support s the use of common DCO of CDS analytic s. 3495  \nGAR -5.5  [~*/HB] The CDS shall  implement  monitoring of  network interface s and other 3496  \ndevice s to detect changes , insertions , and deletions .122 3497  \nT&W:  CWE -15, CWE -119, CWE -200, CWE -223, CWE -405, CWE -642, CWE -778, 3498  \nWRTB -00012, CAPEC -100, CAPEC -123, CAPEC -203, CAPEC -216, TRTB -00014, 3499  \nTRTB -00025, TRTB -00037  3500  \nGAR -5.5.1  [~*/HB]  The CDS shall log all changes to d", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}287{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "286", "chunk": "evices including insertions, removals, 3501  \nand changes in configuration.  3502  \nGAR -5.6  [~*/HB] The  CDS shall  implement file inte grity monitoring . See SIR section.  3503  \nGAR -6 [~*/HB] If the CDS is using SELinux as its MAC implementation then it shall not 3504  \ngenerate SELinux policy denials  via the Access Vector Cache (AVC)  during normal 3505  \noperation unless there is  an anomaly.  The SELinux policy shall  be properly tuned to 3506  \nremove spurious denials.  3507  \nRationale: The AVC log must be able to be used as part of the analysis of any 3508  \noperational or security problems with the CD S. Spuriou s information in the log 3509  \nreduce s the value of the log.  3510  \nT&W:  WRTB -00013 , TRTB -00027  3511  \nGAR -7 The CDS shall be assigned or internally  generate a UUID that shall never change for the 3512  \nlife of the CDS.  3513  \nClarification:  The life of the CDS includes patching, updates,  and reinstallations of the 3514  \nCDS. A replacement of the hardware component including the motherboard should 3515  \nnot result in a change of the UUID.  The UUID could be assigned during provisioning 3516  \n(e.g., as part of a remote installation process) or during manufacture by vendor. It can 3517  \nalso be automatically generated during installation. The ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}288{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "287", "chunk": "CDS UUID is per device not 3518  \nper site or per dataflow. Dataflow  UUID s would be different. This UUID will be used 3519  \nto uniquely identif y the device in logs, in CDS Configuration and Compliance 3520  \nReports (C 3R), Guard Remote Management Protocol (GRMP), or anywhere a unique 3521  \nID is need ed to unique ly identify a CDS.   3522  \nGAR -7.1 CDS operating on virtual mac hines shall have a UUID for each virtual instance of the 3523  \n \n121 https://wiki.nftables.org/wiki -nftables/index.php/Logging_traffic  \n122 For Linux consider leveraging procfs, https://docs.kernel.org/filesystems/proc.htmlUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 142 of 397 CDS.  3524  \nGAR -7.2 If a CDS is operating on a hypervisor and the virtual machine  is cloned to instantiate a 3525  \nnew CDS  instance  then the UUID of the cloned instance must be re-generated . 3526  \nGAR -8  The CDS developer shall document in the low-level  design document which libraries 3527  \nare used by which CDS application processes . 3528  \nGAR -9 The CDS developer shall not implement any software licensing mechanism (including 3529  \nv", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}289{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "288", "chunk": "ia 3rd party  products and libraries) that require s the Fully Qualified Domain Name 3530  \n(FQDN) or Internet Protocol (IP) Address be provided in order to generate a license key 3531  \nrequest.  3532  \nRationale:  The FQDN  and IP Addresses  for servers on USG classified network are 3533  \nconsidered classifi ed by multiple Government  organizations.  3534  \nClarification:  If the CDS developer provides a mechanism to generate the license key on 3535  \nthe classified network then use of the F QDN or IP Address may be allowed but their 3536  \nuse is still strongly discouraged.  If a third -party  software package does require a 3537  \nFQDN and the software must be used because of its unique capabilities, then a  CDS  3538  \ndeveloper could potentially use a UTS Namespace  with a fake FQDN  for that 3539  \nprocess.  3540  \nT&W:  CWE -200, TRTB -00042  3541  \nGAR -9.1 Use of the Ethernet Media Access Control Address combined with a hostname (minus 3542  \nthe domain name  portion ) may be used  for license key  generation requests.  3543  \nGAR -9.2 CDS hostnames should not  contain coverterms, organi zation al names, CDS product 3544  \nnames, or other identifying information to include the network or customer . 3545  \nClarification: The CDS hostname s are configurable . This is an ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}290{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "289", "chunk": "end -user requirement.  3546  \nRationale:  This reduces the risk of accident al data spills of classified network or 3547  \noperational mission  information when a license key is required for a CDS.  3548  \nT&W:  CWE -200, TRTB -00042  3549  \nGAR -10 CDS developers  may use license keys to control the installation  and use  of specific 3550  \nsubsystem s and components  of a CDS.  3551  \nClarification:  The primary purpose of this requirement and its dependencies is to support 3552  \nthe inclusion of commercial third -party licensed components  in the data flow pipeline 3553  \nor enable unique features in the CDS that are only suitable for specific operational 3554  \nand threat environments.  3555  \nGAR -10.1 If the license key of a component of a subsystem is invalid or expi red then the 3556  \ncomponent  and subsystem  shall not be installed.  3557  \nGAR -10.2 If the license key for a component e xpires and that component is no  longer functional 3558  \nand any interdepe ndent functionality or subsystem is disabl ed.  3559UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 143 of 397 Clarification : For exampl", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}291{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "290", "chunk": "e, if the license key for a PDF filter  expires and the filter  is 3560  \ndisabled then the entire PDF pipeline must be disabled. In some cases, if the 3561  \nsubsystem is disabled the entire may need to transition to a maintenance mode.  3562  \nGAR -10.2.1  The CDS shall audit all license key expirations and the actions that the CDS 3563  \nperformed due to that expiration.  3564  \nGAR -10.3 Individual foundational components of a CDS cannot  be individually licensed.  3565  \nRationale:  Foundational components  are those supporting functions that enable the CDS 3566  \nto operate or are required for safe and secure operation of the device. Example 3567  \ninclude  the filte r orchestration engine, the JAL subsystem, the  event 3568  \nmanagement/policy enforcement subsystem, the  integrity monitoring subsystem, etc. 3569  \nare all critical to the secure operational of the CDS. If any one of those components 3570  \nwere individually licensed and expired then the CDS would need to shut down  or 3571  \nCDS might enter an unsafe and insecure state, thus reason for not individually  3572  \nlicensing them.  3573  \nGAR -10.4 If licenses are used, then the licensed component must send audit messages to the 3574  \nCALD every ten days starting at 90 days prior to expiration and every day 10 ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}292{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "291", "chunk": "days prior 3575  \nto expiration.  3576  \nGAR -10.5 If licenses are used  and the licensed component has expired but has enter ed a grace 3577  \nperiod prior to dis ablement then the component must send audit messages to the CALD 3578  \nevery day until the grace period expires.  3579  \nGAR -10.6 The system must notify via a visual indicator that requires acknowledgement any user 3580  \nof the CDS who  is logging into the CDS if the licenses are with 90 days of expiring or 3581  \nhave expired.  3582  \nGAR -10.6.1  Each acknowledgement of the license key expiration shall be audited.  3583  \n 3584  \n10.3 Command and Control (C2) and M etadata  Messaging  Requirements  3585  \n(C2R)  3586  \nThis section covers the requiremen ts for internal Command and Control  (C2) and Metadat a 3587  \nmessaging within the CDS.  CDS use C2 messaging to control internal processes ( e.g., restart, 3588  \nreload config uration , shutdown, send configurations, etc.). CDS use metadata messaging to 3589  \nprovide the different parts of the filtering subsystem with the inform ation necessary to track and 3590  \nprocess content being filtered. Metadata frequently includes date/time content received, customer 3591  \nID, JobID (usually a UUID), content filename, policyID to use in filtering the content, object ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}293{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "292", "chunk": "text  3592  \n(e.g., parent object or artif act object) , mime type, status information, hashes, and other field s 3593  \nnecessary to process the content.  3594  \nC2R-1 [~*/CCOTS] CDS Command and Control (C2)  and dataflow  metadata communications 3595UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 144 of 397 originated from within  the CDS shall  always be syntactically and semantically validated 3596  \nby each process prior to be ing used by the process . 3597  \nT&W:  WRTB -00025, CWE -20, CWE -1286, CWE -228, CAPEC -153 3598  \nC2R-2 [~*/CCOTS] C2 and dataflow metadata originating from protocol adapters shall be 3599  \nfiltered by an inline dedicated filter process, independent of and prior to being used by 3600  \nanother process or components in the CDS.  3601  \nT&W:  CWE -434, CWE -20, CWE -707, WRTB -00030,  CAPEC -113, CAPEC -153, 3602  \nCAPEC -234, TRTB -00029  3603  \nC2R-3 [~*/CCOTS] C2 and dataflow metadata communications shall be implemented in a fixed 3604  \nformat data type .  It is strongly recommended that the data type  chosen for  metadata 3605  \nshould  be capable  of being validated  at a d", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}294{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "293", "chunk": "ata rate of at least 2500  messages/seco nd. 3606  \nT&W: CWE -20, CWE -228, CWE -410, CAPEC -125, CAPEC -153 3607  \nC2R-4  [~*/CCOTS] The data type of the metadata may be Key-Value  lists.  3608  \nC2R -4.1 [~*/CCOTS] K eys shall be allowlist ed and the length s shall  be constrained . 3609  \nT&W: CWE -20, CAPEC -153 3610  \nC2R -4.2 [~*/CCOTS] V alues shall  be validated with lengths, regular expression s, enumerations, 3611  \nprecise typing, and/or ranges . 3612  \nT&W: CWE -20, CAPEC -153 3613  \nC2R-5  [~*/CCOTS] The data type of the metadata may be XML .  3614  \nC2R -5.1 [~*/CCOTS] T he XML shall be  validated using a n XML Schema.  3615  \nT&W: CWE -112, CAPEC -153, CAPEC -230 3616  \nC2R-6 [~*/CCOTS] JavaScript Object Notation (JSON) should not be used as a CDS C2 and 3617  \nmetadata messaging data type  due to lack of a formal schema definition language123 and 3618  \ninteroperable JSON schema validators124.  3619  \nT&W: CWE -20, CWE -436, CAPEC -153 3620  \nC2R -6.1 [~*/CCOTS] J SON may be used if a formal schema definition language is approved by 3621  \nan international standards body and there is demonstrated in teroperable and specification  3622  \ncompliant vali dators available \u2013 basically the equivalent to the XML community today.  3623  \nC2R -6.2 [~*/CCOTS] Custom JSON fi", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}295{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "294", "chunk": "lters  written for specific JSON files shall not be used . 3624  \n \n123 Work is slowly progressing toward completion of an IETF approved JSON Schema Definition Language. See \nhttp://json -schema.org/specificati on.html  for more information.  \n124 https://labs.bishopfox.com/tech -blog/an -exploration -of-json-interoperability -vulnerabilities  and \nhttp://seriot.ch/parsing_json.phpUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 145 of 397 T&W:  CWE -20, CAPEC -153 3625  \nC2R-7  [~*/CCOTS] The dataflow metadata should  be transferred internally within the CDS 3626  \nseparate ly from the content  being filtered.  Separately can be via different IPCs or 3627  \ndifferent messages (if using the same IPC as content transfer) . 3628  \nT&W: CWE -668, CWE -20, CAPEC -153, CAPEC -212 3629  \nC2R -7.1 moved to C2R -10  3630  \nC2R-8 [~*/CCOTS] C2 and dataflow metadata shall be transferred via one -way IPC 3631  \nmechanisms  within the CDS.  3632  \nClarification: A one -way IPC is not required between a filter controller  (for a single data 3633  \ntype)  and its child processes doing the actual filterin g. This i s allowe", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}296{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "295", "chunk": "d because the 3634  \nprocesses are performing a single core function (e.g., filtering a JPEG) and are within 3635  \nthe same securit y context.  The child processes are allowed to send the data forward to 3636  \nthe next stage of pipeline.  3637  \nT&W: WRTB -00034, CWE -424, CAPEC -554, TRTB -00021, TRTB -00004  3638  \nC2R -9 [~*/CCOTS]  The use of Serialized Objects/Data Structures like Java\u00ae  Serialized 3639  \nObjects, Google\u00ae Protocol Buffers, or similar mechanism s shall not be used for dataflow 3640  \ncontent or dataflow metadata transfer  unless the contents can be independently valida ted 3641  \nagainst a ruleset o r schema.  3642  \nRationale: Serialized Objects/Data Structures have a long history of security problems 3643  \ndue to poor implementations and their tendency to be directly loaded into memor y 3644  \n(instead of being parsed and validated against a ruleset/schema) based on an agreed to 3645  \nunderstanding of the expected data structure. If the actual structure of the data is 3646  \ndifferent, this can lead to exploitation of the system. Metadata must be capable o f 3647  \nbeing parsed and validated quickly and safely. For most serialized object systems,  the 3648  \nonly official interface specification is an Application Programming Interface and the 3649  \nint", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}297{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "296", "chunk": "ernal serialized object format is not standardized or formalized therefore att empts 3650  \nto filter the serialized object is unreliable over time because the format could change 3651  \nwithout notice (including via a security patch).  3652  \nT&W: CWE -20, CWE -502, CWE -241, CAPEC -153, CAPEC -586 3653  \nC2R -9.1 [~*/CCOTS]  The serialized object format shall  be stable, have a formal specification 3654  \nthat can be validated against a ruleset or schema, and the serialize d object implementation 3655  \nmust validate the object via a ruleset/sc hema prior to using the object.  3656  \nT&W: CWE -20, CWE -502, CWE -241, CAPEC -153, CAPEC -586 3657  \nC2R -10 [~*/CCOTS] PA and Filter C2 messaging shall not use the same communications 3658  \nchannel as the dataflow metadata or dataflow content. PA and Filter C2 messaging 3659  \nincludes (but is not limit ed to): sending application restart, reload (for policy), and 3660  \nshutdown messages; sending configuration files (e.g., filter policy); and health and status 3661UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 146 of 397 communications (not related to a speci", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}298{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "297", "chunk": "fic dataflow which should go through the JAL 3662  \nsubsystem).  3663  \nT&W:   CWE-668, CWE -20, CAPEC -153, CAPEC -212 3664  \nC2R -11 [~*/CCOTS , [~*/HB ] The use of blockchain manifests , digitally signed metadata or 3665  \nfilter reports shall not be used  to avoid implementing RAIN compliant filtering  in the 3666  \nCDS.  3667  \nClarif ication: However, blockchain manifests  or similar techniques  that are properly 3668  \nvalidated by each stage of the pipeline including the Domain Router could potentially 3669  \nincrease the cost and complexity to an adversary  in attempting to  successfully 3670  \ncompro mise the filter  pipeline  on the CDS . 3671  \nT&W:  WRTB -00015, CWE -424, WRTB -00031, CAPEC -554 3672  \n10.4 Operating System Security  Requirements  (OSSR)  3673  \nMost of OSSR does not apply to a hardware based CDS, however, if there software components 3674  \nin the hardware CDS (e.g., softcores running CDS components, the CDS management server) 3675  \nthen OSSR would apply to those software components.  3676  \nOSSR -1 [~*/HB] The CDS shall not run CDS GUIs, dataflow , CJD, or CALD  processes as root  3677  \nor similar ly unconstrained operating system  users .  3678  \nT&W:  CWE -250, CAPEC -234 3679  \nOSSR -1.1 [~*/HB] Protocol adapters may start as root  (if they ar", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}299{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "298", "chunk": "e using privileged ports) ;125 3680  \nhowever , they shall shed  their root ownership prior to a ccepting and processing data.  3681  \nClarification: This requirement is only applicable  if CAP_NET_BIND_SERVICE  3682  \ncannot be used.  3683  \nT&W:  CWE -272, CWE -434, CAPEC -234 3684  \nOSSR -2 [~*/HB] SETUID126 programs shall only be  used for system administration, startup, 3685  \nshutdown , and maintenance activities.  3686  \nT&W: CWE -250, CAPEC -234 3687  \nOSSR -2.1 [~*/HB] CDS System administration GUIs shall not be SETUID  (e.g., they cannot be 3688  \nSETUID root) . They must run as the user that  is executing the program.  3689  \n \n125 On UNIX\u00ae/Linux\u00ae based operating systems privileged ports are those below port number 1023 a nd root is \nrequired to bind to them.  \n126 SETUID is a term used in UNIX\u00ae/Linux\u00ae systems that means the program\u2019s permissions are set such that when \nthe program is run it will execute as a specific user regardless of who runs the program. This is commonly \nimplemented for programs that need to run as root like the system administration tool sudo .UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU,", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}300{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "299", "chunk": " SWE, QAT  \nPage 147 of 397 T&W:  CWE -88, CWE -223, CWE -284, CWE -250, CWE -863, CAPEC -234, CAPEC -88, 3690  \nTRTB -00014  3691  \nOSSR -2.2 [~*/HB] SETUID  programs  shall be single scope  and purpose applicat ions (e.g., 3692  \ncreation/modification/deletion of users or changing IP Filter configuration but not both).  3693  \nT&W:  CWE -653, CAPEC -234 3694  \nOSSR -2.3 [~*/HB] SETUID  programs shall only be implemented in programming languages 3695  \nthat, when compiled, result in native code running on the operating system.  3696  \nT&W: WRTB -00002, CWE -94, CWE -96, CWE -470, CWE -914, CWE -915, CWE -627, 3697  \nCAPEC -234 3698  \nOSSR -2.4 [~*/HB] SETUID programs shall not be implemented in any language that allows 3699  \ndynamic compilation  or is run through an interpreter  (e.g., shell scripts , Python, Perl, 3700  \nRuby, Java\u00ae  [if run in a JDK] , JavaScript ). 3701  \nRationale: Programming languages and language virtual machines that su pport dynamic 3702  \ncompilation or dynamic code execution ( e.g., like JavaScript\u2019s eval function) 3703  \nsubstantially decrease the complexity of an attacker to get unintended code to execute 3704  \nand MAC enforcement systems ( e.g., SELinux) offer little in the way o f protec tion 3705  \nagainst it. SECCOMP on Linux\u00ae can be used to r", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}301{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "300", "chunk": "estric t function call access.  3706  \nT&W:  WRTB -00002, CWE -94, CWE -96, CWE -470, CWE -914, CWE -915, CWE -627, 3707  \nCAPEC -234 3708  \nOSSR -2.5 [~*/HB] CDS Developer created SETUID root  programs operating on Linux shall  3709  \nbe replaced with binaries that are assigned the specific  Linux \u00ae Capabilities127 needed  to 3710  \nperform the required privileged functions.  This does not apply to operating system 3711  \nvendor provided programs . 3712  \nRationale: Linux\u00ae Capabilities were created to curtail the need for SETUID root  3713  \nprogram and thus reduce the overall attack surface of systems.  3714  \nT&W: WRTB -00003  , CAPEC -234 3715  \nOSSR -3 [~*/HB] The CDS shall not permit adding users to operating system groups (e.g., wheel 3716  \non Linux \u00ae) that provide a similar level of capability as the root user.  3717  \nT&W:  CWE -266, CAPEC -234 3718  \nOSSR -4 [~*/HB] The CDS shall run all CDS processes as unique users  in order to enable DAC 3719  \nseparation between processes .   3720  \nClarification:  For example, in a three domain CDS with an HTTP server and two XML 3721  \n \n127 https://blog.container -solutions.com/linux -capabilities -why-they-exist -and-how-they-work  and https://linux -\naudit.com/linux -capabilities -101UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL T", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}302{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "301", "chunk": "O USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 148 of 397 filters, a naming convention like the following could be used for the unique users 3722  \nhttpdd1, httpdd2, httpdd3, xmlfltr1d1, xmlfltr1d2, xmlfltr1d3, 3723  \nxmlfltr2d1, xmlfltr2d2  and xmlfltr2d3 . In an Access CDS  (client)  this 3724  \nrequirement is met by running the Access CDS processes as the user logged into the 3725  \ndevice. Th ese processes include the  X Server, Vir tual Machine Manager, Audio 3726  \nSubsystem, etc.  This applies to all CDS processes not just pipeline processes; 3727  \nhowever, processes that communicate externally (in any way) or process external data 3728  \nare the highest risk and the priority  3729  \nRationale:  A CDS implement ing robust DAC and MAC permissions prevents a 3730  \ncompromised processed (like a PA) from being to read the binaries and configuration 3731  \nof other processes on the CDS.  3732  \nT&W:  CWE -266, CAPEC -234 3733  \nOSSR -4.1 [~*/HB] CDS processes within the same application ( e.g., httpd child processes) or 3734  \nmultiple instances of the same application ( e.g., a Microsoft Office\u00ae  filter)  in the same 3735  \nsecurity domain  and", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}303{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "302", "chunk": " in the same flow direction  may run as the same unique user  as the 3736  \nparent pr ocess.  3737  \nOSSR -4.2 [~*/HB] Each MLS level or MCS category  within the CDS shall use  its own set of 3738  \nunique CDS process users . 3739  \nT&W: WRTB -00039, TRTB -00005, TRTB -00006  3740  \nOSSR -4.3 [~*/HB] CDS processes and associated users shall not be able to write to their 3741  \nbinaries or libraries . 3742  \nT&W:  WRTB -00037 , CAPEC -642 3743  \nOSSR -4.4 [~*/HB] CDS processes and associated users shall not be able  to write to their 3744  \nconfiguration files . 3745  \nT&W:  WRTB -00038  , CAPEC -180, CAPEC -562, CAPEC -75 3746  \nOSSR -4.5 [~*/HB] CDS pipeline components  and their associated users shall not be able to read 3747  \nor write to other CDS pipeline /non-pipeline components  binaries, packaged  libraries, 3748  \nconfiguration files (includes rulesets  and schemas) , or directories .  3749  \nClarification:  If a process\u2019s binaries and non -operating system provided libraries are 3750  \ninstalled in process specific direct ory (e.g., /opt/mycds/xmlfilter1/bin, 3751  \n/opt/mycds/xmlfitler 1/lib, /opt/mycds/xmlfilter 1/config ) 3752  \nthen the applying the DAC and MAC permissions is less complex  in order to  ensure 3753  \nthe necessary isolation intended  then installing ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}304{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "303", "chunk": "the files into a common set of 3754  \ndirectories with multiple filters  and P as. 3755  \nThis does not apply to different instantiations of the same component  in the same 3756  \ndomain/category/MLS label in the same pipeline  instance . For example, if a CDS 3757  \ndeveloper decided to run multiple instances of the Domain1Filter1 process instead of 3758UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 149 of 397 implementing threading then all instances of Domain1Filter1 would have the same 3759  \nuser ID and are consider ed the same process  for the purpose s of this requirement.  3760  \nT&W:  WRTB -00074 , CAPEC -180 3761  \nOSSR -4.5.1  [~*/HB] CDS pipeline process es and associated users may be  allowed to  read and 3762  \ndelete files from another pipeline process\u2019 outbound directory or write files to another 3763  \npipeline process \u2019 inbound d irectory so long as a linear non -bypassable flow is enforced.  3764  \nOSSR -4.6 [~*/HB] CDS pipeli ne processes and associated users shall not share configuration 3765  \nfiles (includes rulesets, schemas) .  3766  \nClarification:  If two filters need the same con", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}305{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "304", "chunk": "figuration file (e.g. , two XML parsers 3767  \nusing the same schemas) then two c opies of the configuration file  must exist.  3768  \nRationale:  This is an implementation of the Principle  of Least Knowledge.  This 3769  \nrequirement is intended to reduce the potential information exfiltration risk from the 3770  \nCDS if a process is compromised.  3771  \nT&W:  WRTB -00039 , TRTB -00005, TRTB -00006  3772  \nOSSR -4.7 [~*/HB]  A CDS process\u2019 files shall not be owned by  the user that is executing the 3773  \nprocess .  3774  \nClarification:  The user should have the appropriate group read/write/execute 3775  \npermissions as allowed above.  Using the OS SR-4 example  above,  the binaries, 3776  \nlibraries and configuration files used by the xmlfltr1d1  process must be owned by 3777  \na different user but the xmlfltr1d1  user would have  group  read and execute 3778  \npermissions on binaries and read permissions on the libraries and  configuration files.  3779  \nT&W:  CWE -708, WRTB -00037, WRTB -00038 , CAPEC -180, CAPEC -562, CAPEC - 3780  \n642, CAPEC -75 3781  \nOSSR -4.8 [~*/HB] CDS programs (e.g., on disk) must not be owned by operating system 3782  \nprivileged users (e.g., root) unless they are required to be SETUID.  3783  \nOSSR -4.9 The names of users, groups, directories for", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}306{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "305", "chunk": " CDS components shall not use the name 3784  \nof the actual product name and version being used. 3785  \nClarification:  For example, xmlval1d1  for user or group  name  or xmlvalidator1  3786  \nfor an application directory would be ok. But no t xercesjd1 for a user or group 3787  \nname or xercesj_v2_0_filter  for an application directory.  3788  \nRationale: Eliminating the use of actual product names for users, groups, and directories 3789  \nincreases the complexity for an adversary to discover  the products being used on the 3790  \nCDS if they managed to get a limited pre sence on the device (perhaps by 3791  \ncompromising a protocol adapter).  If an adversary knows which specific products and 3792  \nversions being used it decreases the costs and complexity in developing exploits 3793  \nagainst a system.  3794UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 150 of 397 OSSR -5 [~*/HB] The CDS operating system s and applications  shall  be locked down using, at  a 3795  \nminimum, the applicable DISA  Security Technical Implementation Guide (STIG)128, 3796  \nNIST National Checklist Program129 or Center for Inte", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}307{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "306", "chunk": "rnet Security (CIS) lockdown 3797  \nguidance . This only applies if a STIG for the OS and applications exists .  3798  \nClarification: The DISA STIG takes precedence over NIST and CIS guidance. If there is 3799  \ndisagreement between the m the DISA STIG should be used or contact the NCDSMO.  3800  \nOSSR -5.1 [~*/HB] The CDS operating system audit shall be configured in accordance with the 3801  \nDISA STIG.  3802  \nOSSR -6 [~*/HB] The CDS operating system s shall only have applications and libraries installed 3803  \nthat are needed to operate  and protect  the CDS .  3804  \nT&W:  WRTB -00005  , CAPEC -175, TRTB -00007  3805  \nOSSR -7 [~*/HB] The CDS operating systems must  be evaluated under Common Criteria/NIAP 3806  \nProtection Profile for Ge neral Purpose Operating Systems Version 4.1 (or higher ) or a 3807  \nprocess specified  in CNSSP -11 \u201cNational Policy Governing the Acquisition of 3808  \nInformation Assurance (IA) and IA-Enabled Information Technology Products \u201d Section 3809  \nIV.7. 3810  \nClarification: If the operating system is currently in NIAP evaluation it can be used.  3811  \nOSSR -8 [~*/HB] The CDS shall use wrapper programs to protect unintended and unsafe use of  3812  \nprivileged operating system applications (e.g., /usr/bin/passwd , 3813  \n/usr/sbin/ useradd ) ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}308{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "307", "chunk": "which could lead to system corruption or privilege escalation.  3814  \nThe wrapper  program  must limit use of the operating system application to only the 3815  \nfunctions required.  3816  \nT&W:  CWE -20, CWE -78, CAPEC -113, CAPEC -153, CAPEC -88, CAPEC -9 3817  \nOSSR -8.1 [~*/HB] Wrapper progr ams shall be written in C, C++,  or a type -safe language 3818  \nprovided the software is natively compiled and not operating within a language virtual 3819  \nmachine.  3820  \nRationale:  Wrappers are the primary interface between CDS applications and existing 3821  \nOS privileged functions. Their primary function is to make sure only the minimal 3822  \namount of functionality is allowed and that the input is fully validated before calling 3823  \nthe OS function to prevent malicious ac tivity (e.g., shell execution). The use of 3824  \nscripting languages increases the likelihood of dynamic code execution. The use of 3825  \nlanguage virtual machine (LVM) based languages (e.g., Java\u00ae, C#) increases the 3826  \ncomplexity of MAC policy (for some operating system s) due to the additional 3827  \n \n128 https://public.cyber.mil /stigs/downloads  \n129 https://csrc.nist.gov/projects/national -checklist -program  and https://nvd.nist.gov/ncp/repositoryUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO US", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}309{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "308", "chunk": "A, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 151 of 397 SYSCALL and permissions required for the LVM to operate.  3828  \nT&W:  WRTB -00002, CWE -94, CWE -96, CWE -470, CWE -914, CWE -915, CWE -627, 3829  \nCAPEC -234 3830  \nOSSR -8.2 [~*/HB] The CDS developer  shall constrain the wrapper program  to only the 3831  \nnecessary functions . 3832  \nT&W:  CWE -749, CAPEC -212 3833  \nOSSR -8.3 [~*/HB] Wrapper programs shall conduct bounds checking  and input validation  on 3834  \nthe arguments passed to the wrapped programs.  3835  \nTesting:  Testers should evaluate all wrapper programs to verify they properly validate all 3836  \ncommand line arguments and their content to prevent command line injection attacks 3837  \nlike the following from working: \u201c/usr/sbin/usermod \u2013u 1000 -g 1001 -h 3838  \n/home/bob bob ; /usr/bin/rm -f \u201c 3839  \nT&W:  CWE -20, CAPEC -113, CAPEC -153, CAPEC -88, CAPEC -9 3840  \nOSSR -8.4 [~*/HB] Wrapper programs shall implement constraint enforcement ( e.g., preventing 3841  \ncreation of accounts with UID of 0  (zero) , adding users to group wheel).  3842  \nT&W:  CWE -20, CAPEC -113, CAPEC -153, CAPEC -88, CAPEC -9 3843  \nOSSR -8.5  [~*/H", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}310{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "309", "chunk": "B] Wrapper programs shall log to CALD the actions performed by whom and 3844  \nunder which role and the command lin e arguments provided.  3845  \nT&W:  CWE -778, TRTB -00037  3846  \nOSSR -9 [~*/HB] The CDS shall implement least privilege throughout the entire CDS 3847  \narchitecture to en sure each process is granted the most restrictive set of privileges or 3848  \naccesses needed for its required functionality.  3849  \nOSSR -9.1  [~*/HB] The least privilege design shall be enforced by a n operating system security 3850  \nenforcing mechanism s including (but not limited to) : DAC/ MAC Policy, SE CCOMP, and 3851  \nLinux Capabilities . 3852  \nT&W: CWE -653, CAPEC -234 3853  \nOSSR -10 [~*/HB] The CDS shall only use 64 -bit (or higher) general purpose CPUs ( e.g., 3854  \nIntel\u00ae , AMD\u00ae , ARM \u00ae).  3855  \nOSSR -10.1 [~*/HB] The 64 -bit requirement does not apply to special purpose auxiliary/support 3856  \nprocessors ( e.g., FPGA, GPUs, cryptographic co -processors , management CPUs ) that 3857  \nmay be used by a CDS.  3858  \nOSSR -10.2 Management CPUs (e.g. , an ARM \u00ae SOC included in a FPGA  package) may be 32 - 3859  \nbit. However, CDS using 32-bit management CPUs shall not operate with their 3860  \nmanagement CPUs persistently connected to a managemen t networ k due to the increased 3", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}311{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "310", "chunk": "861  \nattack risks. This restriction does not apply to CDS with 64-bit management CPUs.  This 3862  \nrequirement applies to soft core CPUs running inside the FPGA.  3863UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 152 of 397 T&W: CWE -1252, WRTB -00006, WRTB -00033, CAPEC -180, TRTB -00008, TRTB - 3864  \n00035  3865  \nOSSR -10.3 Management CPU (whether hard or sof t core CPU ) may run an  operating system  or 3866  \nmay run a single application . 3867  \nOSSR -10.3.1 If the Management CPU runs an operating system , it must be a commerci ally 3868  \nsupported operating system and follow the relevant security requirements  in this 3869  \ndocument.  3870  \nT&W: CWE -1329, WRTB -00022, CAPEC -69, CAPEC -234 3871  \nOSSR -11 [~*/HB] CDS software shall be compiled for 64-bit and executed on a 64 -bit operating 3872  \nsystem.  3873  \nRationale: The effectiveness of advanced OS attack mitigations like Address Space 3874  \nLayout Randomization (ASLR)  and position independent code are substantially 3875  \nreduced with 32 -bit code and processors due to the reduced physical and virtual 3876  \naddress space.  3877  \nO", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}312{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "311", "chunk": "SSR -12 [~*/HB] CDS software and operating system application software shall be compiled to 3878  \nbe position independent and implement Address Space Layout Randomization (ASLR) 3879  \ntechniques to redu ce the effectiveness of attacks that require knowledge of the layout of 3880  \nmemory to locate and execute code with the desired effects . 3881  \nClarification: checksec130 can be used  to check binaries for RELRO and many other 3882  \nsecurity related compiler  settings. See OSSR -41, OSSR -42, OSSR -13, and OSSR -14 3883  \nT&W:  CWE -120, CWE -121, CWE -122, CWE -123, CWE -787, WRTB -00006, WRTB - 3884  \n00033, CAPEC -14, CAPEC -92, CAPEC -100, TRTB -00008, TRTB -00035  3885  \nOSSR -13 [~*/HB] The CDS shall only use CPUs with non -executable memory support ( e.g., 3886  \nExecute Disable Bit (EBD ) on Intel\u00ae  CPUs and NX on AMD\u00ae  CPUs), shall enable that 3887  \nsupport  on user -space programs , and shall ensure and verify that CDS applications131 are 3888  \nleveraging it.  3889  \nT&W:  CWE -119, CWE -120, CWE -121, CWE -122, CWE -123, CWE -787, CWE -1252, 3890  \nWRTB -00028 , CAPEC -100, CAPEC -123, CAPEC -14, CAPEC -180, CAPEC -92 3891  \nOSSR -14 [~*/HB] The CDS software shall be compiled with REL RO (relocation read -only) 3892  \nsupport and compiler -based  stack protectio", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}313{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "312", "chunk": "n techniq ues ( e.g., GCC\u2019s -fstack -protector - 3893  \nall).132 3894  \n \n130 https://g ithub.com/slimm609/checksec.sh  and https://opensource.com/article/21/6/linux -checksec   \n131 Use of non -executable memory may prevent the use of programming languages that use just -in-time (JIT) \ncompilation techniques. CDS processes that use those languages are exempt from this requirement.  \n132 https://outflux.net/slides/2020/lpc/gcc -and-clang -security -feature -parity.pdfUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 153 of 397 T&W: CWE -122, CWE -121, CWE -119, WRTB -00009, CAPEC -100, CAPEC -123, 3895  \nCAPEC -14, CAPEC -92, TRTB -00009  3896  \nOSSR -15 [~*/HB] The CDS software shall  use compilers that support Control Flow Integrity133 3897  \n(CFI) checks and enabl e those checks for CDS applications.134 3898  \nClarification: The use of CPUs with hardware support for CFI is strongly encouraged 3899  \nover just relying on a software implementation.  3900  \nRationale:  CFI techniques have been shown to dramatically redu ce the success of  Code 3901  \nReuse Attacks (CRA ) like  Return -Oriented Programming (ROP", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}314{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "313", "chunk": ") and Jump -Oriented 3902  \nProgramming  (JOP) . 3903  \nT&W: CWE -843, CWE -680, CWE -121, CAPEC -46, CAPEC -92, TRTB -00010  3904  \nOSSR -15.1  [~*/HB] The CDS operating system should use compilers that support Control Flow 3905  \nIntegrity135 (CFI) checks and enable those checks for the operating system .136 3906  \nT&W: CWE -843, CWE -680, CWE -121, CAPEC -46, CAPEC -92, TRTB -00011  3907  \nOSSR -16 [~*/HB]  For CDS that have network connections, the CDS shall  have the configurable 3908  \nability  to respond to ICMP Ping  requests  on all network interfaces . 3909  \nT&W:  CWE -200, WRTB -00004 , CAPEC -285, TRTB -00038  3910  \nOSSR -16.1 [~*/HB] The CDS may have  the ability to initiate an outbound ping, on any 3911  \ninterface, from the CDS administration GUI.  3912  \nRationale:  Previous CDS security guidance was to disable ICMP Ping. This has had 3913  \nseveral unfortunate side effect s. It has caused network operations to disable CDS 3914  \nnetwork switch ports and release  CDS IP addresses for reuse because the device 3915  \ncould not be pinged. Additionally, it is extremely abnormal for modern network 3916  \ndevices not to respond to a ping which has the effect of making the CDS look 3917  \n \n133 https://www.microsoft.com/en -us/research/publication/control -flow-integri", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}315{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "314", "chunk": "ty -principles -implementations -and-\napplications  and https://nebelwelt.net/blog/20160913 -ControlFlowIntegr ity.html  and \nhttps://www.blackhat.com/docs/eu -16/materials/eu -16-Sullivan -Towards -A-Policy -Agnostic -Control -Flow -\nIntegrity -Implementation.pdf , https://outflux.net/slides/2020/lca/cfi.pdf  \n134 Currently implemented in the clang and MS Visual C++ compilers but GCC v6+ has -mmitigate -rop which \nshould make ROP attacks harder. See https://gcc.gnu.org/ml/gcc -patches/2015 -11/msg01773.html  and \nhttps://clang.llvm.org/docs/ControlFlowIntegrity.html , https://www.redhat.com/en/blog/fighting -exploits -control -\nflow-integrity -cfi-clang  \n135 https://www.microsoft.com/en -us/research/publication/control -flow-integrity -principles -implementations -and-\napplications  and https://nebelwelt.net/blog/20160913 -ControlFlowIntegrity.html  and \nhttps://www.blackhat.com/docs/eu -16/materials/eu -16-Sullivan -Towards -A-Policy -Agnostic -Control -Flow -\nIntegrity -Implementation.pdf  \n136 Currently implemented in the clang and MS Visual C++ compilers but GCC v6+ has -mmitigate -rop which \nshould make ROP attacks harder. See https://gcc.gnu.org/ml/gcc -patches/2015 -11/msg01773.htmlUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}316{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "315", "chunk": ", SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 154 of 397 abnormal on the network  and thus a t arget for further investigation by an adversary.  3918  \nOutbound pings are sometimes required for network switches to detect the Media 3919  \nAccess Control  addresses of devices connected to it.  3920  \nT&W:  CWE -655, TRTB -00038, TRTB -00033  3921  \nOSSR -17 [~*/HB] A CDS shall  not identify itself on the network as a CDS ( e.g., via logon 3922  \nbanners)  this includes stating the product\u2019s name.  3923  \nT&W : CWE -200, CAPEC -541 3924  \nOSSR -18 [~*/HB] The CDS shall only expose  externally (to the CDS) , via Protocol Adapters 3925  \n(Pas), those network  services which are necessary to support CDS functionality . For 3926  \nexample, if the CDS does not support HTTP for a dataflow (or remote management) then 3927  \nan HTTP server shall  not be running and the IP Firewall shall  not allow connections to 3928  \nthe ports used by the HTTP server ( e.g., TCP 80/443) . Pas are also used on the DCO and 3929  \nManagement network interfaces to support the required functionality for those functions.  3930  \nT&W:  WRTB -00006  , TRTB -00035  3931  \nOSSR -18.1 [~*/HB] Except for the inbound and outbound pr", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}317{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "316", "chunk": "otocol adapters and processes 3932  \nrelated to remote management and monitoring , CDS processes shall not have any  direct  3933  \noutside network ac cess. All networking access must be internal to the host (e.g., loopback 3934  \nthrough the operating system kernel).  3935  \nT&W: WRTB -00025  , TRTB -00034  3936  \nOSSR -19 [~*/HB] The CDS shall ignore  all connection requests to  ports and protocols not 3937  \nsupport ed by the  CDS . 3938  \nT&W: WRTB -00029, CAPEC -300, TRTB -00034  3939  \nOSSR -20 [~*/HB] The CDS should  implement the ability to set and adjust the CDS date and 3940  \ntime via the Network Time Protocol (NTP) . NTP, if used to set the CDS date/time, is 3941  \nconsidered non -dataflow  related data and is exempt  from the filtering requirement (see 3942  \nGAR -3) if NTP is not sent cross domain.  3943  \nT&W:  WRTB -00032 , TRTB -00015  3944  \nOSSR -20.1 [~*/HB] In a single box CDS, the CDS shall restrict NTP to  the management or 3945  \nsystem high network interface s. 3946  \nT&W:  WRTB -00016, WRTB -00001,  TRTB -00002,  TRTB -00032  3947  \nOSSR -20.2 [*/CCOTS, */THA] If a CDS is implementing a one -way transfer mechanism, the 3948  \nlow side server of the one -way transfer shall use  the low-side management interface or 3949  \nthe low network interface for NTP.", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}318{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "317", "chunk": "  3950  \nT&W:  WRTB -00014 , TRTB -00012  3951  \nOSSR -20.3 [*/CCOTS, */THA] If a CDS is implementing a one -way transfer mechanism, the 3952  \nhigh side server of the one -way transfer shall use the  high side management interface or 3953UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 155 of 397 the high network interface for NTP.  3954  \nT&W:  WRTB -00014 , TRTB -00012  3955  \nOSSR -20.4 [~*/HB] CDS should implement IETF RFC  8915 : Network Time Security (NTS) for 3956  \nthe Network Time Protocol137. 3957  \nOSSR -21 [~*/HB , ~*/CCOTS ] The CDS shall implement a mechanism to execute NIST SP 3958  \n800-126 Rev 2: Security Content Automation Protocol (SCAP) version 1.2 or higher 3959  \nscans on a CDS  for IAVA, Patching, and STIG compliance checks.   3960  \nOSSR -21.1  [~*/HB , ~*/CCOTS ] The CDS shall implement a mechanism to transfer SCAP scan 3961  \nresults off the CDS via the management interface . For TCDS, the system high interface 3962  \nmay be used.  3963  \nOSSR -21.2 [~*/HB , ~*/CCOTS ] The CDS shall implement a mechanism to automate the 3964  \nregular SCAP scans of the CDS no  less than once a day. ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}319{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "318", "chunk": "3965  \nOSSR -21.3 Deleted.  3966  \nOSSR -22 [~*/HB] CDS operating on Linux\u00ae  shall  use an evaluated Linux\u00ae  Security Module 3967  \n(LSM) based MAC system.  Currently this is the SELinux  or General Dynamics\u2019 3968  \nPitBull\u00ae  Trusted Operating System .  3969  \nRationale:  Other LSMs  for MAC may potentially be used but they have not be en 3970  \nevaluated  and formal evaluation would be required \u2013 contact the NCDSMO to discuss 3971  \noptions.  3972  \nOSSR -22.1 [~*/HB] The CDS shall not use AppArmor \u00ae138 as the sole mechanism for  MAC 3973  \nenforcement.  3974  \nRationale:  The use of path-based  MAC provides less security  than inode -based MAC  3975  \ndue to the ability to manipulate paths ( e.g., mounting a filesystem over another 3976  \nfilesystem, symbolic links, et c.). Additionally, AppArmor \u00ae does not have the 3977  \nconcept of users. It is based on applying privileges  to programs which means it 3978  \ncann ot implement RBAC . 3979  \nT&W:   WRTB -00019, CAPEC -234 3980  \nOSSR -23 [~*/HB] CDS operating on Linux\u00ae  shall use SECCOMP (secure computing mode) to 3981  \nrestrict the System Calls (i.e. , SYSCALLs) used by all protocol adapters, RMAN/RMON 3982  \nsubsystems, filters, filter orchestration, CJD, and  CALD processes and should be used for 3983  \n \n137 See https://dat", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}320{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "319", "chunk": "atracker.ietf.org/doc/html/rfc8915  and https://access.redhat.com/documentation/en -\nus/red_hat_enterprise_linux/8/html/configuring_basic_system_settings/assembly_overview -of-network -time-\nsecurity -in-chrony_configuring -basic -system -settings  \n138 See https://en.wikipedia.org/wiki/AppArmorUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 156 of 397 all other  processes. 139 3984  \nClarification: The intent is to use SECCOMP to remove access to SYSCALLs  after the 3985  \napplication has establishe d its communications interfaces but prior to the start of 3986  \nprocessing data  or connections . For example, if a protocol adapter that needs to bind 3987  \nto ports 80  and 443, create two message queue s, and create a temporary directory  then 3988  \nthose actions would be per formed and the process would use SECCOMP to remove 3989  \nthose privileges  (and others that are not needed)  since they are no longer needed  3990  \nduring operation of the process.  3991  \nT&W:  WRTB -00007, CWE -434, CAPEC -234 3992  \nOSSR -23.1 [~*/HB ] Only the SYSCALLs  necessary for operation of the process shall be 3993  \nallo", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}321{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "320", "chunk": "wed . 3994  \nT&W:  WRTB -00007 , CAPEC -234 3995  \nOSSR -23.2 [~*/HB] Processes using SECCOMP must invoke SECCOMP before processin g 3996  \ndata from external connections or processing external content . 3997  \nT&W:  CWE -272, CAPEC -234 3998  \nOSSR -23.3 Deleted.   Duplicate of OSSR -27.1 3999  \nOSSR -23.4 [~*/HB] The CDS shall audit any processes that are terminated due to an attempt to 4000  \nuse a SYSCALL  for which they are not authorized.  4001  \nT&W:  CWE -778, TRTB -00037  4002  \nOSSR -23.5 [~*/HB] Linux \u00ae140 based CDS that have systemd141 shall use systemd  to apply a 4003  \nbase SECCOMP policy that restricts each process\u2019 system calls to only those necessary to 4004  \nstart and run.  4005  \nT&W:  WRTB -00007 , CAPEC -234 4006  \nOSSR -24 [~*/HB] The CDS developer should implement , via the operating system  provider, the  4007  \nuse of the Software ID (SWID) Tag Specification (ISO/IEC 19770 -2142 & NIST IR 8060) 4008  \nto record the software and its associated metadata tha t has been installed on the CDS.  If 4009  \nthe OS and third -party  provider does not implement SWID then the CDS developer shall 4010  \ncreate SWID tags.  4011  \nRationale:  This is an implementation of the Software Bill of Materials (SBOM) 4012  \n \n139 https://outflux.net/slides/2020/lpc/seccomp -an", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}322{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "321", "chunk": "d-friends.pdf  \n140 Support for SECCOMP  was introduced only in systemd  version 239 . So this is supported in RHEL 8 not \nRHEL7 and below.  \n141 https://www.freedesktop.org/wiki/Software/systemd  \n142 https://www.iso.org/standard/65666.html  and https://nvlpubs.nist.gov/nistpubs/ir/2016/NIST.IR.8060.pdfUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 157 of 397 requirement described in  the Executive Order on Improving the Nation\u2019s 4013  \nCybersecurity143 (12 May 2021).  4014  \nOSSR -24.1 SWID tags are required for ALL software installed on the CDS.  4015  \nOSSR -24.2 SWID tags are required (for the individual packages) to be updated for all updates to 4016  \nthe CDS including Operating System Patch Clusters.  4017  \nOSSR -24.3 A zip file containing the CDS SWID files must be provide d electronically to the 4018  \nNCDSMO for ALL updates to the CDS within 30 days of release  of the update.  4019  \nRationale:  These SWID files will be used by the NCDSMO and other USG cyber 4020  \ndefense organizations to assess the security of risk of deployed CDS based on new 4021  \nCVE s and IAVA s that have been released.  ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}323{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "322", "chunk": "4022  \nOSSR -25 [~*/HB] The CDS developer shall not use a custom kernel  build  of a commodity 4023  \noperating system ( e.g., RHEL\u00ae , PitBull\u00ae ) for a CDS.  However, if the commercially 4024  \nsupported operating system is only provided in source ( e.g., Wind River \u00ae Linux \u00ae) then 4025  \ncomp iling the kernel is allowed but modifying  the kernel source code is not allowed.  4026  \nRationale: The use of custom kernels substantially increases support costs and 4027  \ncomplexity as it would require the CDS developer to maintain a custom kernel for the 4028  \nlifespan of  the CDS. Additionally, it would invalidate the OS vendor testing of the 4029  \nkernel patches as part of the Operating System Patch Cluster (OSPC). Essentially, the 4030  \ncost and complexity of maintaining a custom kernel does not outweigh the potential  4031  \nsecurity benef its. If a CDS developer  has a firm requirement for a custom kernel build  4032  \nthis should be discussed with the NCDSMO  before pr oceeding . 4033  \nT&W:  WRTB -00022, CWE -1329 , CAPEC -69 4034  \nOSSR -25.1  [~*/HB] The CDS developer shall  remove via non -compilation methods any 4035  \nunnecessary kernel modules and device drivers (e.g., rmmod  on Linux \u00ae144).  4036  \nClarification:  The preferred method is to prevent the unnecessary ker", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}324{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "323", "chunk": "nel modules and 4037  \ndevices divers from being installed  on the system, otherwise remove the m post 4038  \ninstallation.  4039  \nT&W:  WRTB -00008  , TRTB -00017  4040  \nOSSR -25.2  [~*/HB] The CDS developer shall disable, for operating systems that support it, the 4041  \nability to load additional kernel modules after the system boots.  4042  \nClarification:  For Linux\u00ae based systems, kernel module loading145 can be disabled after 4043  \n \n143 https://www.whitehouse.gov/briefing -room/presidential -actions/2021/05/12/executive -order -on-improvi ng-the-\nnations -cybersecurity/  \n144 https://www.tecmint.com/load -and-unload -kernel -modules -in-linux  \n145 https://linux -audit.com/increase -kernel -integrity -with-disabled -linux -kernel -modules -loadingUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 158 of 397 the system has booted using the  sysctl  to set the kernel parameter 4044  \nkernel.modules_disabled  value to  1.  4045  \nT&W: WRTB -00023 , CAPEC -552 4046  \nOSSR -25.3  [~*/HB] The CDS developer should use kernel module denylist ing146, if supported 4047  \nby the operating system, to prevent una", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}325{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "324", "chunk": "uthorized modules from being loaded into the 4048  \nkernel.  4049  \nT&W: WRTB -00018  , CAPEC -552, TRTB -00018  4050  \nOSSR -26 [~*/HB] The CDS developer should  ensure that CDS processes  disable the ability  to 4051  \nbe traced ( e.g., ptrace, strace, and t russ)147.  4052  \nRationale:  Allowing strace/ptrace increases the internal a ttack surface of the CDS. 4053  \nTracing provides a mechanism for the inspection and manipulation of the internal 4054  \nstate of a process .  4055  \nT&W:  WRTB -00021, CAPEC -529, CAPEC -640 4056  \nOSSR -27 [~*/HB, ~*/CCOTS] The CDS operating on UNIX\u00ae /Linux\u00ae  based or  derived 4057  \nplatforms must use one of the following IPC mechanisms when  a one-way data transfer is 4058  \nrequired  to ensure unidirectional data flow : 4059  \na) Signals  4060  \nb) UNIX\u00ae Domain Sockets  4061  \nc) Named Pipes  4062  \nd) System V Shared Memory with another approved IPC  for signaling  4063  \ne) System V Me ssage Queues  4064  \nf) System V Semaphores   4065  \ng) POSIX\u00ae  Shared Memory with another approved IPC for signaling  4066  \nh) POSIX\u00ae  Message Queues  4067  \ni) POSIX\u00ae  Semaphores \u2013 Deleted  4068  \nj) UDP/IP  (not recommended , see OSSR -27.2) 4069  \nk) File Transfer  4070  \nClarification : There are inherent back -channel (s) in most IPC mechanisms. Back -", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}326{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "325", "chunk": " 4071  \nchannel s exist even for properly access controlled IPC mechanisms because of the 4072  \nfunctionality of the  IPC APIs , while not intended for transmitting data , can be used to 4073  \ncommunicate from reader  to writer . For example, the bl ocking state of the channel or 4074  \n \n146 https://linux -audit.com/kernel -hardening -disable -and-blacklist -linux -modules  \n147 https://www.kernel.org/doc/Documentation/security/Yama.txt  and \nhttps://media.defense.gov/2019/Jul/16/2002158062/ -1/-1/0/CSI -LIMITING -PTRACE -ON-PRODUCTION -LINUX -\nSYSTEMS.PDF , https://access.redhat.com/documentation/en -\nus/red_hat_enterprise_li nux/7/html/selinux_users_and_administrators_guide/sect -security -enhanced_linux -\nworking_with_selinux -disable_ptrace  and https://www.kernel.org/doc/html/v4.15/admin -guide/LSM/Yama.htmlUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 159 of 397 the existence of the IPC object itself can be used to signal from reader to writer. 4075  \nWhen properly mitigated, these back -channel s tend to be of significantly lower 4076  \nbandwidth than the associated forward channel provided by th", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}327{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "326", "chunk": "e API. In a CDS, most 4077  \ncommunications (especially for a filter pipeline) should use one -way IPCs. POSIX 4078  \nsemaphores are no longer allowed to be used. Additional analysis and testing have  4079  \nshown they cannot  implement a one -way mechanism safely.  4080  \nFor the following  sub-requirements, the term \u2018reader\u2019 refers  to the process that is 4081  \nreading from the IPC, the term \u2018writer\u2019 refers to the process writing to the IPC, and 4082  \nthe term \u2018creator\u2019 refers to the process that created the IPC.  4083  \nOSSR -27.1 [~*/HB, ~*/CCOTS] When POSIX\u00ae  Message Queues are used, SECCOMP must 4084  \nbe used to block the mq_notify (3) functionality from being used148. 4085  \nRationale:  This prevents  a back -channel  use of the mq_notify  function.  4086  \nT&W: WRTB -00017, TRTB -00016  4087  \nOSSR -27.2 [~*/HB, ~*/CCOTS] When UDP/IP is used, the sending and receiving process es 4088  \nmust be blocked with SECCOMP  and MAC such that : 4089  \n1) The sending process is prevented from receiving data  from receiving pro cess and  4090  \n2) The receiving process is prevented from sending data  to the sending process.  4091  \nClarification:  The use of UDP/IP sockets is strongly discouraged and only should be 4092  \nused if no other option is possible. The CDS vendor will ne", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}328{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "327", "chunk": "ed to provide evidence 4093  \nas to why no other options are possible.  4094  \nT&W:  WRTB -00014  , TRTB -00020  4095  \nOSSR -27.2.1 [~*/HB, ~*/CCOTS] When UDP/IP sockets are used for IPC within the same host, 4096  \nthe socket shall only be bound to a loopback device within a Linux network n amespace  4097  \nand the processes that use the sockets shall only be run within s aid Linux network 4098  \nnamespace.  4099  \nClarification:  Virtual Ethernet\u2019s (veth) in bridge -mode can be used.  A single bridged 4100  \nveth would be created per pair of processes and assigned to two namespaces. Process 4101  \n1 would be in network space different from Process 2 bu t veth would bridge both.  4102  \nRationale: This prevents a compromised process with access to networking syscalls from 4103  \nbeing able to exfiltrate data off the CDS if compromise d and prevents the process 4104  \nfrom establishing a connection between two or more domains  and thus bypassing the 4105  \nfiltering pipeline.  4106  \n \n148 Testing in January 2019 conducted by Quark Security has shown that there is a substantial back -channel  for \nPOSIX\u00ae  Message Queues if the mq_notify function  is allowed to be used. Access to and use of this function can be \nblocked via SECCOMP.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}329{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "328", "chunk": ", ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 160 of 397 OSSR -27.3 [~*/HB, ~*/CCOTS] A single shared memory segment (POSIX and Sys tem V) shall 4107  \nnot be shared by multiple stages in a pipeline.  4108  \nRationale:  If a shared memory  segment is shared by multiple pipeline stages it can 4109  \nalways be bypassed at the end because  all writing process es have write access to the 4110  \nsegment.  4111  \nOSSR -27.4 [~*/HB, ~*/CCOTS] For File Transfer, System V queues,  POSIX queues,  named 4112  \npipes, System V shared memory, POSIX shared memory , and Unix domain sockets  IPCs, 4113  \na creator process  shall be used to  create the IPC  resource , set its DAC /MAC  permissions, 4114  \nand set any configuration parameters (e.g., IOCTLs) . 4115  \nClar ification:  For Unix domain sockets  only, the creator process is only creating the 4116  \ndirectory  not the socket. This is to prevent the pipeline processes from being able to 4117  \nchange DAC on the directory.  If SE Linux is being used correctly, the IPC resource 4118  \nshou ld transition to the correct context from the creator. Otherwise,  the IPC creation 4119  \nprocess need to set the correct MA", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}330{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "329", "chunk": "C context on the IPC resource.  4120  \nRationale:  This is done to support uni -directionality when setting up DAC and MAC 4121  \nsecurity.  Some IPC s cannot safely implement uni -directional ity if the reader or writer 4122  \nhave the ability to create or modify the IPC mechanism.   4123  \nOSSR -27.5 [~*/HB, ~*/CCOTS] Named Pipes and stream -oriented sockets shall be ope ned in 4124  \nBlocking mode only.  4125  \nRationale:  Opening a pipe  or and stream -oriented sockets  in non -blocking mode leaves a 4126  \nvulnerability for a partial -write back -channel . Non-blocking writes immediately 4127  \nreturn the number of bytes successfully written. A reader can manipulate this value by 4128  \nallowing the buffer to completely fill and then read a specific number of bytes. By 4129  \ndoing this, a reader and writer can collaborate to transfer data against the flow of an 4130  \naffected one -way IPC.  4131  \nOSSR -27.6 [~*/HB, ~*/CCOTS] When using Named Pipes  and stream -oriented sockets , 4132  \nSECCOMP shall be used to deny the fcntl(2) from being called with the F_SETFL  4133  \nparameter.  4134  \nRationale:  This can be used to switch the pipe or and stream -oriented sockets to non - 4135  \nblocking, which introduces a potential partial -write back -channel  (see OSSR -27.5) . 41", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}331{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "330", "chunk": "36  \nOSSR -27.7 [~*/HB, ~*/CCOTS] When using Named Pipes, SECCOMP shall be used to deny 4137  \nthe fcntl(2) from being called with the F_SETPIPE_SZ  parameter.  4138  \nRationale:  This can be used to increase the size of the pipe creating a larger back - 4139  \nchannel  bandwidth.  4140  \nOSSR -27.8 [~*/HB, ~*/CCOTS] When using Named Pipes , SECCOMP sha ll be used to deny 4141  \nthe ioctl(2) from being called with the FIONREAD  parameter.  4142  \nRationale: FIONREAD  can be used by the writer side to learn how many unread bytes 4143UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 161 of 397 are in the pipe, which allows a higher bandwidth back-channel  to be created over the 4144  \nnamed pipe.  4145  \nOSSR -27.9 [~*/HB, ~*/CCOTS]  Different signal handlers a pplied to a process shall not provide 4146  \nfunctionality of differing privilege.   4147  \nRationale:  MAC and DAC do not provide signal number -level granularity. Granting 4148  \npermission for a process to send signals to another process grants permission to 4149  \nexecute all signal  handers  4150  \nOSSR -27.10 [~*/HB, ~*/CCOTS] When Signals are used ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}332{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "331", "chunk": "for IPC , MAC shall be used to control 4151  \nwhich processes can send to which processes.  4152  \nRationale:  Signals are only allowed to be sent between processes with the same user ID, 4153  \nwhich cannot be the case for CDS processes per OSSR -4. This means the process 4154  \nmust be grante d CAP_KILL, which allows it to send signals to any process. MAC is 4155  \nrequired to ensure that signals are only sent between intended processes.  4156  \nOSSR -27.11 [~*/HB, ~*/CCOTS] Signals shall not be used from reader to writ er if those 4157  \nprocesses are also using UNIX Domain Sockets, Name d Pipes, System V Message 4158  \nQueues, or POSIX Message Queues to communicate one -way from writer to reader . 4159  \nOSSR -27.12 [~*/HB, ~*/CCOTS] When Sys tem V message queues are used , SECCOMP  shall  4160  \nbe used to  deny msgctl(2)  functionality from being used by the reader or writer . 4161  \nRationale: msgctl(2)  makes it possible to change permissions on the queue, 4162  \npotentially allowing a bypass or the creation of a back-chann el. 4163  \nOSSR -27.13 [~*/HB, ~*/CCOTS] When POSIX message q ueues are used , SECCOMP  shall be 4164  \nused to deny mq_getattr(2 ). 4165  \nRationale:  mq_getattr( 3) can be used to see how many messages are in the queue, 4166  \nwhich can be used to cr", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}333{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "332", "chunk": "eate a back -channel . Mq_setattr( 3) can be used to set 4167  \nnon-blocking I/O mode, which makes back -channel  implementation easier.  Both of 4168  \nthese functions are implemented using mq_getsetattr(2) . 4169  \nOSSR -27.14 [~*/HB, ~*/CCOTS] When using File Transfer  for an IPC, if the file sharing 4170  \nmechanism uses rename(2) , renameat(2) , or renameat2(2)  to move f iles from 4171  \nwriter to reader, the use of mmap(2)  on those files by the writer shall be prohibited by 4172  \nMAC policy and denied by a SECCOMP filter.  4173  \nRationale:  There are no access check s after mmap(2)  has opened the file for writing, 4174  \ntherefore it can  continue to write to and modify the file if its MAC context has been 4175  \nchanged , potentially creating a bypass.  4176  \nOSSR -27.15 [~*/HB, ~*/CCOTS]  Unix -domain socket files s hall be stored inside of a directory 4177  \nunique to each Unix -domain socket.  4178  \n Rationale : If multiple Unix -domain sockets share the same directory to store their socket 4179UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 162 of 397 files then it would possible for a comp", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}334{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "333", "chunk": "romised process to create a back -channel.   4180  \nOSSR -27.15.1 [~*/HB, ~*/CCOTS] Unix domain sockets without a socket file (i.e., unnamed or 4181  \nabstract sockets) shall not be used . 4182  \nOSSR -27.16 [~*/HB, ~*/CCOTS] A process that writes to the Unix -domain socket shall be 4183  \nprevented from listing the contents of the directory in which its socket file is stored.  4184  \nRationale:  If a writer  process can list the contents of the directory, the process creating 4185  \nthe socket can create more socke t files to potentially create a back -channel . 4186  \nOSSR -27.17 [~*/HB, ~*/CCOTS] The creator  process creates the  directory that holds a  Unix - 4187  \ndomain socket file shall create  a default ACL149 on the directory where the socket file is 4188  \nstored .  4189  \nRationale:  A write -only default ACL prevents any sockets or other files created in the 4190  \ndirectory by the reading process from being able to be read by writing processes. 4191  \nWithout this defaul t ACL, the reader process could set the mode of the file to allow 4192  \nthe writers to be able to read.  An example default ACL for a directory used to hold a 4193  \nUnix -domain socket is provided below. It allows any processes in the group 4194  \nwriter_group  to write to sock ets created by the ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}335{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "334", "chunk": "user reader_user . 4195  \n 4196  \ndefault:user:: --- 4197  \ndefault:user:reader_user:r -- 4198  \ndefault:group:: --- 4199  \ndefault:group:writer_group: -w- 4200  \ndefault:mask::rw - 4201  \ndefault:other:: --- 4202  \n 4203  \nOSSR -27.18 [~*/HB, ~*/CCOTS] When POSIX message queues are used , the MAC policy shall 4204  \nrestrict the writer process from having read access to the queue files on the mqueuefs 4205  \nvirtual filesystem.  4206  \n 4207  \nRationale:  The queue files on this virtual filesystem (default location /dev/mqueue ) 4208  \ncontain queue attributes that can be manipulated by the reader process (e.g., QSIZE 4209  \nshows the number of bytes of data in the queue ). Restricting read access by the writer 4210  \nprocess prevents a back -channel  using the data contained within this file  (see 4211  \nmq_overview(7) ). Prohibiting read access via DAC policy is ineffective because 4212  \nthe message queue is owned by the writer and is therefore trivially circumvented.  4213  \nOSSR -27.19 [~*/HB, ~*/CCOTS] When Signals are us ed to communicate in a pipeline then 4214  \n \n149 https://man7.org/linux/man -pages/man5 /acl.5.html#OBJECT_CREATION_AND_DEFAULT_ACLsUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}336{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "335", "chunk": "//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 163 of 397 SECCOMP shall be used to deny calls to rt_sigqueueinfo(2)  and 4215  \nrt_tgsigqueueinfo(2) . 4216  \nRationale:  Signals can send an integer value along with the signal. Preventing this 4217  \nreduces the bandwidth of backchannels using signals.  4218  \nOSSR -28 [~*/HB , TCDS /*] The CDS may permanently lock out CDS  users  (privileged and 4219  \nnon-privileged)  if they exc eed the configured number of failed password attempts . 4220  \nOSSR -29 [~*/HB] The CDS shall , at a minimum, temporarily  lock out CDS users (privileged 4221  \nand non -privileged) if they exceed the configured number of failed password attempts.  4222  \nT&W:  CWE -307, CWE -645, CAPEC -16, CAPEC -2, CAPEC -49, CAPEC -565, CAPEC - 4223  \n600 4224  \nOSSR -29.1 The minimal lockout period shall be  at least  15 minutes.  4225  \nOSSR -29.2 The CDS may implement a sliding window where the CDS increases the amount of 4226  \ntime the user must  wait between password entry retries.  4227  \nOSSR -30 [~*/HB] All CDS accounts (privileged and non -privileged) must change their 4228  \npasswords on firs t login when passwords are reset, accounts are created, or an account  is 4229  \nunlocked.  4230  \nT&W: CWE -35", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}337{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "336", "chunk": "9, CWE -522, CAPEC -560 4231  \nOSSR -31 [~*/HB]  The CDS shall not allow the system to boot or operate with MAC 4232  \nenforcement disabled . 4233  \nClarification: The CDS cannot boot with MAC disabled and then later transition to a 4234  \nMAC enforced state .  4235  \nT&W:  WRTB -00024 , CAPEC -122 4236  \nOSSR -31.1 [~*/HB]  The CDS shall verify that MAC enforcement is enabled and i s in an 4237  \nenforcing mode at least every 30 seconds.  4238  \nClarification:  On a Linux\u00ae  CDS leveraging  SELinux  for MAC enforcement, this should 4239  \nbe done by checking the kernel\u2019s SE Linux  status via  the getenforce  command not 4240  \nby solely checking the /etc/sysconfig/selinux configuration.  4241  \nT&W: WRTB -00024  , CAPEC -122 4242  \nOSSR -31.2 [~*/HB]  The CDS shall audit any changes to MAC enforcement and shutdown if 4243  \nMAC is not enabled and in an enforcing mode.  4244  \nT&W:  WRTB -00026  , TRTB -00037  4245  \nOSSR -32 [~*/HB]  The CDS must operate on a commercially supported operating system. The 4246  \nuse of free operating systems (closed or open source) that lack a commercial support 4247  \nprovider  are no l onger allowed.  4248UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE O", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}338{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "337", "chunk": "NLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 164 of 397 Rationale:  The NCDSMO has simply had too many problem s with CDS developer s 4249  \nclaiming they can provide the necessary security patching support for custom or free 4250  \noperating systems  and not doing it . This is not a safe or sustainable path for the USG.  4251  \nClarification:  A commercially supported operating system is defined as an operating 4252  \nsystem that can be commercial ly acquired  by purchasing the product from a  FVEY 4253  \ncompany  and support contract s for softw are update s, security updates, technical 4254  \nsupport, and new hardware support is available  for purchase. The operating system 4255  \ncan be provided in binary or source form.   4256  \nT&W:  CWE -1329,  WRTB -00022, CAPEC -69, CAPEC -234 4257  \nOSSR -32.1 [~*/HB]  The operating system must have at least 3 years of mainline commercial 4258  \nsupport available for a CDS to enter a Full LBSA.  4259  \nOSSR -32.2  [~*/HB]  The operating system must have at least 1 year of mainline commercial 4260  \nsupport available for a CDS to enter a Delta LBSA.  4261  \nOSSR -32.3 [~*/HB] The CDS developer must maintain a support contract with the operating 4262  \nsystem vendor for the life of the CDS.   4263  \nOSSR", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}339{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "338", "chunk": " -32.3.1 [~*/HB] The support contract shall  provide  security patches  for the CDS . 4264  \nT&W: CWE -1329, WRTB -00022, CAPEC -234, CAPEC -69 4265  \nOSSR -32.3.2 [~*/HB] The support contract should provide non -security related software 4266  \nupdates and support for new hardwar e for the CDS  software . 4267  \nOSSR -32.4 [~*/HB]  The CDS developer should only use operating system s that have a minimal 4268  \nsupport period of 10 years.  4269  \nClarification:  The CDS can enter testing with less than 10 years of support remaining 4270  \n(see above) , but the operating system must be on 10+ year support cycle. Each major 4271  \nrelease of the operating system must be supported for at least ten years ( e.g., RHEL\u00ae  4272  \n6, RHEL\u00ae  7 and RHEL\u00ae  8 are each supported for ten years. If a CDS entered Full 4273  \nLBSA in Spring 2020 on RHEL\u00ae  7.9, it would be allowed to go into testing since 4274  \nRHEL\u00ae  7 mainline support ends in June 2024. However , if a CDS was submitted for 4275  \nFull LBSA in Spring 2020 on RHEL\u00ae  6.10 it would be rejected because mainline 4276  \nsupport for RHEL\u00ae  6 ends 30 November 2020).  4277  \nOSSR -32.5 [~*/HB] An operating system managed by a Government  program  office  setup 4278  \nsolely to manage the configuration, packaging, and delivery of an operat", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}340{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "339", "chunk": "ing system for 4279  \nuse in multiple other Government  programs ( e.g., weapon systems/sensors) may be used . 4280  \nHowever, the core o perating system shall be a  commercially supported  operating system 4281  \nand the Government  program office shall maintain  patch and update synchronization with 4282  \nthe commercial operating system.  4283  \nOSSR -32.5.1 A bespoke operating system not based on and thus not maintained in 4284  \nsynchronization with a commercially supported operating system shall  not be used . 4285UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 165 of 397 T&W: CWE -1329, WRTB -00022, CAPEC -234, CAPEC -69 4286  \nOSSR -32.6 The CDS shall only use Long -Term Support (LTS) versions of the operating 4287  \nsystem150. 4288  \nT&W:  CWE -1329, WRTB -00022, CAPEC -234, CAPEC -69 4289  \nOSSR -33 [~*/HB]  The CDS developer shall implement the guidance on developing and testing 4290  \nweb applications published by the Open Web Application Security Project (OWASP)151 4291  \nfor any web applications that  will operate  on the CDS. This applies to internally facing 4292  \nsystem administration appli", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}341{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "340", "chunk": "cations or externally facing interfaces (e.g. , XML /JSON 4293  \nbased web services, web based RHR system, web based remote console access).  4294  \nOSSR -34 [~*/HB]  The CDS must have IP Forwarding disabled in the kernel.  4295  \nT&W:  WRTB -00027 , TRTB -00030  4296  \nOSSR -35 [~*/HB] Linux -based CDS shall use Linux Capabilities152 to minimize the number  of 4297  \nprivileges given to processes that traditionally need to run as root . 4298  \nT&W:  CWE -250, CAPEC -234 4299  \nOSSR -35.1 [~*/HB] Linux Protocol Adapters that need to bind to privileged ports shall not run 4300  \nas root (UID=0) but instead be given the CAP_NET_BIND_SERVICE  capability . 4301  \nT&W:  CWE -250, CAPEC -234 4302  \nOSSR -35.2 [~*/HB] A process that  is assigned specific capabilities to perform privileged 4303  \noperations shall drop those capabilities after performing the privileged operations.  4304  \nClarification:  Capabilities are not required to be dropped for short lived processes (like 4305  \nwrappers , see OSSR -8) are executed by other programs (e.g., system administration 4306  \ntools). Short lived processes are not daemons.  4307  \nT&W:  CWE -272, CWE -273, CAPEC -234 4308  \nOSSR -36 [~*/HB, ~*/CCOTS] Linux -based CDS shall  use Linux Namespaces to isolate 4309  \nfunctions  or subsystems wit", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}342{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "341", "chunk": "hin the CDS.153 4310  \nClarification:  The CDS should make use of Linux Namespaces only where it makes 4311  \ngood functional and security sense for a given system design. Creating unnecessary 4312  \nnamespace only adds unnecessary complexity to a system making  it more difficult to 4313  \n \n150 For example, Red Hat is using even point revisions for their Extended support releases. See \nhttps://access.redhat.com/support/policy/updates/errata#Maintenance_Support_2_Phase  \n151 https://www.owasp.org  \n152 https:/ /man7.org/linux/man -pages/man7/capabilities.7.html  and https://www.vultr.com/docs/working -with-linux -\ncapabilities  \n153 https://www.toptal.com/linux/separation -anxiety -isolating -your-system -with-linux -namespacesUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 166 of 397 develop, debug and evaluate.  4314  \nT&W:   CWE -653, CAPEC -234, TRTB -00001  4315  \nOSSR -36.1 [~*/HB, ~*/CCOTS] The CDS shall  use network namespaces154 to isolate each 4316  \nnetwork  interface so that only the processes required to communicate on a given interface 4317  \nare within the same network namespace.  4318  \nRatio", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}343{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "342", "chunk": "nale:  This isolates physical communication interfaces and ensures  that a protocol 4319  \nadapter can only access a specific dedicated physical interface.  4320  \nClarificat ion: Dedicated remote management and monitoring interfaces are  also 4321  \nincluded in this requirement . As a reminder each network namespace has its own 4322  \nunique set of firewall rules that will need to be configured.  4323  \nT&W:  CWE -653, WRTB -00025 , TRTB -00002, TRTB -00034  4324  \nOSSR -36.2 [~*/HB, ~*/CCOTS] The CDS shall  place CDS process es which do not require 4325  \nnetwork connectivity into a network namespace without any physical network interface 4326  \nor external connectivity.  4327  \nRationale:  This helps reduce inadvertent network access by processes which should not 4328  \nhave the ability to directly communic ate over the network . 4329  \nT&W:  CWE -653, WRTB -00025 , TRTB -00002, TRTB -00034  4330  \nOSSR -36.3 [~*/HB, ~*/CCOTS]  SECCOMP shall be used to terminate access to the clone() , 4331  \nunshare() , setns()  SYSCALLs  after a process has configured its namespaces  to 4332  \nprevent changes to the namespace assignment . 4333  \nT&W:  CWE -272, TRTB -00003  4334  \nOSSR -36.4 [~*/HB, ~*/CCOTS] All network namespaces with a physical network interface or 4335  \nexternal connect", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}344{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "343", "chunk": "ivity shall have a firewall  configured and enabled.  4336  \nT&W:  WRTB -00029, WRTB -00025 , TRTB -00034  4337  \nOSSR -36.5 [~*/HB, ~*/CCOTS] Linux based CDS that have  systemd  shall use systemd  to 4338  \nmanage the creation of L inux namespaces and launching of services within them.  4339  \nOSSR -36.6 [~*/HB, ~*/CCOTS] If a CDS process creates a namespace or re -associates itself to 4340  \nanother existing namespace the capabilities and privileges needed for the namespace 4341  \nmanipulation shall be dropped prior to processing data from external connections or 4342  \nproces sing external content  4343  \nRationale:  Most Linux namespace types require the CAP_SYS_ADMIN capability and 4344  \nthere are numerous potential security issues with running processes with 4345  \nCAP_SYS_ADMIN. SECCOMP and/or capset() /cap_set_proc()  could be used 4346  \n \n154 https://blogs.igalia.com/dpino/2016/04/10/netw ork-namespacesUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 167 of 397 to accomplish this. This may need to be done on a per -thread basis depending on 4347  \nwhen threads are created relative to dropping of pe", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}345{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "344", "chunk": "rmissions . 4348  \nT&W: CWE -272, CWE -273, CWE -434, CAPEC -234 4349  \nOSSR -37 [~*/HB, ~*/CCOTS] Linux -based CDS should use control groups (CGROUPS) to 4350  \nmanage and restrict resources (e.g., CPU time, system memory) available to each CDS 4351  \nsubsystem.  4352  \nClarification:  Care ful consideration  should  be used so system applications are not so 4353  \ntightly couple d to control  groups resource limits that minor code changes would 4354  \nrequire a significant re -configuration  of the control groups . Control groups must NOT 4355  \nbe tailored in such a way that they attempt to  make Linux behave like a real-time / 4356  \ndeterministic operating system.  4357  \nT&W:  CWE -400, CWE -410, CWE -770, CAPEC -125, CAPEC -130 4358  \nOSSR -37.1 [~*/HB, ~*/CCOTS] Linux -based CDS that have  systemd  shall use systemd , 4359  \nwhere possible, to manage the control groups -based  resource limits.  4360  \nRationale:  Undesired behavior can occur if multiple utilities are used to manage a single 4361  \ncontrol group hierarchy . 4362  \nOSSR -38  [~*/HB] Linux -based  CDS processes shall have the No New Privileges155 4363  \n(no_new_privs ) kernel flag enabled so that the process and their children cannot 4364  \nemploy privilege escalation mechanisms like SETUID and to gain any a", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}346{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "345", "chunk": "dditional 4365  \nprivileges.  4366  \nT&W:  CWE -250, CAPEC -234 4367  \nOSSR -39 [~*/HB ] The CDS shall have the ability to log t he source and destination IP address es, 4368  \nsource and destination  Media Access Control  addresses156, protocol, and port number for 4369  \nall successful and unsuccessful inbound and outbound connectio ns. 4370  \nClarification:  If repeated unsuccessful inbound connections are occurring from the same 4371  \nhost within very short period of times (e.g., milliseconds  to 1-2 seconds ) then they 4372  \ncan be combined into  a single log entry with a count and duration of time the count 4373  \ncover s. No mo re than 100 connections can be in a single entry.  4374  \nT&W: CWE -223, CWE -778, TRTB -00037, TRTB -00043  4375  \nOSSR -40 [~*/HB] The CDS may implement the ability to set and adjust the CDS date and time 4376  \nvia the IEEE 1588 -2019 Precision Time Protocol (PTP ). PTP, if used to set the CDS 4377  \n \n155 https://www.kernel.org/doc/html/latest/userspace -api/no_new_privs.html  and https://manpages.courier -\nmta.org/htmlman1/setpriv.1.html  \n156 If the source or destination is not on the same network as the CDS, then record the MAC of the device to which \nthe CDS is communicating (usually a router).UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO U", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}347{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "346", "chunk": "SA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 168 of 397 date/time, is considered non -dataflow related data and is exempt from the filtering 4378  \nrequirement (see GAR -3) if PTP is not sent cross domain.  4379  \nT&W:  WRTB -00032 , TRTB -00015  4380  \nOSSR -40.1 [~*/HB] In a single box CDS, the CDS shall restrict PTP to the management or 4381  \nsystem high network interfaces.  4382  \nT&W:  WRTB -00016, WRTB -00001, TRTB -00002, TRTB -00032  4383  \nOSSR -40.2 [*/CCOTS, */THA] If a CDS is implementing a one -way transfer mechanism, the 4384  \nlow side server of the one -way transfer shall use the low -side management interface or 4385  \nthe low network interface for PTP. 4386  \nT&W:  WRTB -00014 , TRTB -00012  4387  \nOSSR -40.3 [*/CCOTS, */THA] If a CDS is implementing a one -way transfer mechanism, the 4388  \nhigh side server of the one -way transfer shall use the high side management interface or 4389  \nthe high network interface for PTP. 4390  \nT&W:  WRTB -00014, TRTB -00012  4391  \nOSSR -41 [~*/HB] The CDS software shall not use RPATH157 or RUNPATH . 4392  \nClarification: RPATH and RUNPATH can be manipulated by an  attacker to alter the 4393  \nli", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}348{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "347", "chunk": "braries that are used when an application starts  and thus run untrusted code.  RPATH  4394  \nT&W:  CWE -427, CAPEC -38 4395  \nOSSR-42 [~*/HB] The CDS software shall be compiled with the -D_FORTIFY_SOURCE=1158 4396  \noption if using the GNU Compiler Collection.  4397  \nT&W:  CWE -120, CAPEC -100 4398  \nOSSR -43 [~*/HB] D -Bus may be used for communications from the EM/PE subsystem to 4399  \nsystemd  for process control . 4400  \nOSSR -44 [~*/HB] D -Bus shall not be used in the dataflow pipeline or the JAL subsystem . 4401  \nOSSR -45 [~*/HB] For Linux based system using dracut the following kernel command line 4402  \narguments must be set:  4403  \nrd.shell = 0  4404  \nrd.failure = halt  4405  \n \n157 https://amir.rachum.com/blog/2016/09/17/shared -libraries  ,  \nhttps://security.stackexchange.com/questions/161799/why -does-checksec -sh-highlight -rpath -and-runpath -as-\nsecurity -issues  , https://www.contextis .com/us/blog/linux -privilege -escalation -via-dynamically -linked -shared -\nobject -library  \n158 https://access.redhat.com/blogs/766093/posts/1976213UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 169 ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}349{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "348", "chunk": "of 397 rd.emergency=halt  4406  \n 4407  \n 4408  \n10.5 System Administration Subsystem  Requirements  (SASR)  4409  \nSASR -1 [~*/CCOTS] The CDS shall not use web-based administration tools  for remote system 4410  \nadministration . A web -based administration tool is defined as any CDS administration or 4411  \nconfiguration application that is hosted on a web server residing on a CDS and that can 4412  \nbe locally or remotely access ed via the HTTP S or related protocol ( e.g., via a web 4413  \nbrowser) . 4414  \nRationale: Web -based applications run as a user (e.g., Apache, www) that is not the 4415  \nsame as the user using the tool. This prevents operating system  backed  role-based 4416  \naccess control  and operating system auditing from working properly to control and 4417  \naudit the actions of the users.  4418  \nT&W:  CWE -77, CWE -223, CWE -250, CWE -300, CWE -311, CWE -552, CWE -668, 4419  \nCWE -1125,  WRTB -00025, CAPEC -94, CAPEC -234, CAPEC -383, CAPEC -555, 4420  \nCAPEC -659, TRTB -00014, TRTB -00037  4421  \nSASR -2 [~*/CCOTS] The CDS may use web-based administration tools for local system 4422  \nadministration if the web server and backend processes are running as the locally logged 4423  \nin user and operate with the same privileges and roles as the locally logged i", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}350{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "349", "chunk": "n user.  4424  \nT&W:  CWE -223, CWE -268, CWE -284, C WE-552, CWE -250, CAPEC -234, TRTB - 4425  \n00037, TRTB -00014  4426  \nSASR -2.1 [~*/CCOTS] If a web -based administration capability is implemented, it shall be 4427  \nrestricted to only bind to the loopback address (127.0.0.1).  4428  \nSASR -2.2 [~*/CCOTS] If a web -based administration capability is implemented, MAC policy 4429  \nshall be configured to restrict binding to physical NICs.  4430  \nSASR -2.3 [~*/CCOTS] If a web -based admin istration capability is implemented on Linux, it 4431  \nshall be placed in a network namespace to restrict its ability to connect to physical NICs.  4432  \nSASR -3 [~*/CCOTS] The CDS shall ensure that the system administration tools provide robust 4433  \nbinding, at the operating system level, between the user and the actions performed.  This 4434  \nmeans the actions performed by the tool must be performed by the user logged in and 4435  \nleveraging their permissions and roles and that  the operating system audit should show 4436  \nthe user running the tools.  4437  \nT&W:  CWE -250, CWE -223, TRTB -00014, CAPEC -234 4438  \nSASR -3.1 System administration tools shall  not be operating as another user (e.g., www or 4439  \nhttpd) on behalf of the actual user logged in \u2013 the exception to this is", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}351{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "350", "chunk": " SETUID tools that 4440UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 170 of 397 must run as a specific user but the wrapper program that calls th em is running as the 4441  \nactual logged in user and audit will show which user initiated the application.  4442  \nSASR -4 [~*/HB] The CDS shall use  one or more of the following  method s for system 4443  \nadministration and configuration: Graphical User Interface  (GUI) , Text -based User 4444  \nInterface (TUI) (e.g., menu drive n \u2013 not a command line interface ), or a dongle.  4445  \nRationale:  The purpose of this requirement is to enforce input validation and the 4446  \nexecution of preselected commands  and functions.  For example, use of Linux\u00ae shells  4447  \nscripts  (e.g., bash) historically have diffi culty enforcing robust input validation or the 4448  \nability to precise ly control the commands and their arguments that are allowed.  4449  \nClarification:  The dongle would only contain the configuration or software (including 4450  \npatches) to be installed . See SASR -5. 4451  \nT&W: CWE -284, CWE -732, CWE -77, CAPEC -122, CAPEC -248, CAPEC -40 4452 ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}352{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "351", "chunk": " \nSASR -4.1 [~*/HB] The CDS should not expose  direct  command line -based applications  to any 4453  \nhuman user of the system  including system administrato rs.  4454  \nSASR -4.2 [~*/HB] A ll parameters supplied by the user that will be used as input in the  4455  \ninvocation of a  command line application  shall  be individually and collectively validated  4456  \nto ensure there are no  unsafe and inappropriate actions . 4457  \nRationale:  Many Linux \u00ae/UNIX\u00ae  command line  applications have capabilities that 4458  \nwhen run with privilege ( e.g., root) are unsafe, do not implement RBAC, or would 4459  \nallow the user to do something they are not authorized to do. For example, the 4460  \nLinux\u00ae usermod  command can be used  to change the group membership of a user. 4461  \nIf groups are used as part of the RBAC implementation of the guard, then if the CDS 4462  \nallowed a user to run usermod  unconstrained then the user could potentially ad d 4463  \nthemselves or others to groups (e.g., a role) they are not entitled to be in. Therefore, 4464  \nthe GUI/TUI needs to wrap the command line application and tightly control and 4465  \nvalidate the input to them to ensure the command lines are used safely and securely.  4466  \nT&W:  CWE -20, CAPEC -153 4467  \nSASR -4.3 [TCDS/*] Tactical", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}353{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "352", "chunk": " CDS embedded into weapon systems or sensor s may inclu de the 4468  \nCDS configuration into the CDS software image in lieu of a GUI, TUI, or dongle. This 4469  \napproach is only allowed in situations where the configuration of the CDS is identical for 4470  \nall unique usage instances of the CDS used with in a specific weapon system.  4471  \nClarification: For example, if weapon system  ABC has two instances of myCDS: unique 4472  \nusage instance A is between vehicle CANbus and a tactical secret network and unique 4473  \nusage instance B is between a secret sensor and an unclassified weapon. Then all 4474  \ninstantiations of myCDS instance A must be configur ed the same and all 4475  \ninstantiations of myCDS instance B must be configured the same  4476  \nSASR -4.4  [~*/HB] The CDS should not allow system administrators or CDS users access to a n 4477UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 171 of 397 operating system  shell  (e.g., bash) . 4478  \nSASR -5  [~*/HB] An electronic dongle159 or optical removable media may be used for storing 4479  \nand load ing CDS configuration and/or software . 4480  \nS", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}354{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "353", "chunk": "ASR -5.1[~*/HB] CDS configuration informat ion (e.g., networking, system configuration, filter 4481  \npolicy, etc.) shall be placed in a  separate archive (e.g., zip or tar) from the software.  4482  \nRationale:  Separation of the configuration files from the software allows the 4483  \nconfiguration to change per site /installation without impacting the version ing of the 4484  \nsystem.  If they are comingled,  then the software and configuration cannot  be 4485  \nindependently version ed, so if a site wants to use the same software but a different 4486  \nconfiguration then the system may have to  undergo additional  testing to verify the 4487  \nsoftware has not changed from what was tested in the lab.  4488  \nSASR -5.2  [~*/HB]  Each archive file must have  a digitally signed manifest containing , at 4489  \nminimum, the version of the manifest, the versions of the CDS for which the 4490  \nconfiguration and software are  valid, the list of files  in the archive, and their hashes .  4491  \nT&W:  CWE -345, CWE -354, CAPEC -148 4492  \nSASR -5.2.1 The archive files may be encrypted . 4493  \nSASR -5.3 [~*/HB]  If the manifest does not validate due to invalid or unauthorized signat ure, 4494  \nintegrity failure, or the number, filenames, and hashes of the content in the archive  file 4", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}355{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "354", "chunk": "495  \ndoes not match the manifest then the entire dongle/removable media must be rejected.  4496  \nT&W: CWE -345, CAPEC -439 4497  \nSASR -5.4 [~*/HB]  If any files are  found on the dongle /removable media , that are not in the 4498  \narchive\u2019s  manifest , the dongle/removable media must be rejected  by the CDS.  4499  \nT&W:  CWE -349, CAPEC -523 4500  \nSASR -5.5 [~*/HB]  Any actions performed on a dongle/removable media or its conten ts and the 4501  \nresults of those actions must be audited.  4502  \nT&W:  CWE -778, TRTB -00037  4503  \nSASR -5.6 [~*/HB] T he digital signatu re and integrity of the contents shall be verified prior to 4504  \ninstalling or using any contents from the dongle/removable media . 4505  \nT&W:  CWE -345, CAPEC -439 4506  \nSASR -5.6.1 [~*/HB] The digital certifi cate used to validate the content from the 4507  \ndongle/removable media must be loaded on the CDS during the initial provisioning of the 4508  \nsystem.  4509  \n \n159 A dongle is a digital electronic device capable of storing digital data. The most common type of dongle is a USB \nthumb drive but other types of connections (e.g., RS -232) and devices could be used.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}356{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "355", "chunk": " USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 172 of 397 T&W: CWE -345, CAPEC -439 4510  \nSASR -5.6.2 [~*/HB] The digi tal certificate  can be updated via content on the dongle/removable 4511  \nmedia but only after the contents have been validated.  4512  \nT&W: CWE -349, CAPEC -523 4513  \nSASR -5.7 Deleted and replaced 5. 7 with 5. 1 4514  \nSASR -5.8 [~*/HB] A dongle/removable media\u2019s contents should be encrypted with  the CDS\u2019 4515  \npublic key and use a NIAP -approved data-at-rest implementation.  4516  \nT&W:  CWE -311, CAPEC -117 4517  \nSASR -5.8.1 [~*/HB]  The encryption key used to encrypt dongle  contents may be the same key 4518  \nwithin a single organization for Enterprise or Tactical CDS deployments but shall not be 4519  \nreused with other organizations or different use cases within the same organization . 4520  \nT&W:  WRTB -00010  , TRTB -00019  4521  \nSASR -5.9 [~*/HB] If a dongle  is USB -based , then it should  not use Type A, B, C, Mini, or 4522  \nMicro  USB connectors . 4523  \nT&W:  CWE -1263 , CAPEC -441, CAPEC -457 4524  \nSASR -5.10 [~*/HB] Thunderbolt -based dongles  and devices  may only be used if tested to be 4525  \nsafe prior to use and they are not shared between computers160.   4526  \nClarification: If a com puter u", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}357{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "356", "chunk": "ses a Thunderbolt device  (e.g., hard drive, GPU ) then only 4527  \nthat computer may use that device and it can not be transferred to or used by other 4528  \ncomputers (including CDS of the same or different types).  4529  \nT&W:  CWE -345, CWE -353, CWE -288, CWE -1188, CWE -862, CAPEC -665 4530  \nSASR -5.11 [~*/HB] If a dongle is used, t he CDS should  use a non -standard connector.161 MIL- 4531  \nSTD  connectors are allowed.  4532  \nT&W: CWE -1263, CAPEC -441, CAPEC -457 4533  \nSASR -5.12 [~*/HB] If a dongle/removable media is used to load a configuration on a CDS, a 4534  \nCMS shall be used to generate, validate , manage,  and digitally sign/encrypt the 4535  \nconfiguration prior to load ing onto the dongle/removable media.  4536  \nT&W: CWE-1240, CWE -15, CWE -311, CWE -345, CWE -778, CWE -829, CAPEC -117, 4537  \nCAPEC -148, CAPEC -165, CAPEC -176, CAPEC -203, CAPEC -234, CAPEC -439, 4538  \nCAPEC -523, CAPEC -97, TRTB -00037  4539  \n \n160 See Thunderclap vulnerability:  http://thunderclap.io  and https://en.wikipedia.org/wiki/Thunderspy  \n161 This is to prevent the accidental insertion of commodity USB and Thunderbolt devices, which could pose an \nattack risk against the CDS.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}358{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "357", "chunk": "QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 173 of 397 SASR -6 [~*/HB]  Single user mode should not be used on a CDS . However , if single  user mode 4540  \nis used, the constraints on its use are the following:  4541  \nSASR -6.1 [~*/HB] Shall  only be used for critic al system maintenance functions including Disk 4542  \nMaintenance, Disk Full, and Kernel Patching . 4543  \nT&W : CWE -1263, CWE -284, CAPEC -122 4544  \nSASR -6.2 [~*/HB] Shall require two passwords (boot loader and root) to enter single user mode . 4545  \nT&W:  CWE -287, CAPEC -115 4546  \nSASR -6.3 [~*/HB] Shall not allow u ser account maintenance and dataflow  maintenance .  4547  \nT&W:  CWE -1263, CWE -284, CAPEC -122 4548  \nSASR -6.4 [~*/HB] Shall audit a ll actions  performed in single user mode . 4549  \nT&W:  CWE -778, TRTB -00037  4550  \nSASR -6.5 [~*/HB] For Linux \u00ae based systems, SELinux shall be in enforcing mode  while the 4551  \nsystem is  in single user mode.  4552  \nT&W: WRTB -00024, CAPEC -122 4553  \nSASR -6.6 [~*/HB] Network int erfaces shall be disabled while in single user mode  and only 4554  \nenabled to perform specific tasks that need network  access  and disabled upon completion 4555  \nof the task. 4556  \nT&W:  CWE -272", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}359{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "358", "chunk": ", WRTB -00043 , CAPEC -234, CAPEC -554, TRTB -00002, TRTB - 4557  \n00034  4558  \nSASR -7 [~*/HB, ~*/CCOTS , ^TCDS ] The CDS shall have a maintenance mode162 and ensure 4559  \nthat all dataflow s and associated network interfaces are disabled while in maintenance 4560  \nmode . The remote management interface may be enabled when the system is in 4561  \nmaintenance mode.  4562  \nClarification: This requirement and its sub -requirements do not apply to CDS 4563  \nManagement Systems  since they do not have a maintenance mode.  4564  \nT&W:  CWE -693, CAPEC -554 4565  \nSASR -7.1  [~*/HB] Maintenance mode is not the same as single user mode and single user 4566  \nmode shall not be used as a general purpose maintenance mode due to critical system 4567  \nsecurity services and functionality (like RBAC and integrity checking) that might not be 4568  \n \n162 Maintenance mode is a specialized mode of operation of the CDS where dataflows are disabled. It is used for \nsoftware i nstallation, hardware/software patching, network changes, and addition/deletion/modification of security \ndomains, etc. Essentially when changes are made to CDS that could result in the dataflow no longer being valid, the \nsystem needs to be a less secure st ate to perform action (e.g., perhaps with a different MAC policy", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}360{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "359", "chunk": " in effect), or the \nstate of the system has changed such that a reboot is required to get the system into a known good state.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 174 of 397 activ e while the system is in single user mode.  4569  \nT&W:  CWE -693, CAPEC -554 4570  \nSASR -7.1.1 [~*/HB, ~*/CCOTS] The CDS, if in maintenance mode, shall have the ability to 4571  \ntemporarily suspend i ntegrity monitoring and application  allow listing  during system 4572  \nsoftware patching.  4573  \nSASR -7.2 [~*/HB, ~*/CCOTS] The CDS shall ensure that system audit and logging services are 4574  \noperating when the CDS is in maintenance m ode. 4575  \nT&W:  CWE -778, TRTB -00037  4576  \nSASR -7.2.1 [~*/HB, ~*/CCOTS] If a CDS is transitioning from an operational mode to 4577  \nmaintenance mode due to an inability to audit (see JALSR -36 and JALSR -37) then 4578  \nSASR -7.2 does not apply however, the CDS shall restrict functionality of maintenance 4579  \nmode to those functions necessary to resolve auditing problems.  4580  \nT&W:  CWE -223, CWE -250, CWE -778, CAPEC -122, TRTB -00037  4581  \nSASR -7.3 [~*/HB, ~*/CCOTS] T", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}361{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "360", "chunk": "he CDS shall ensure that system DA C and MAC policy 4582  \nenforcement is still in effect while in maintenance mode . However,  a different MAC 4583  \npolicy may be used while in maintenance mode if necessary to implement the 4584  \nadministrative actions req uired.  4585  \nT&W:  WRTB -00024, CWE -424, CWE -250, CWE -266, CWE -653, CAPEC -122, 4586  \nCAPEC -234, CAPEC -554 4587  \nSASR -7.4 [~*/HB, ~*/CCOTS] The CDS shall ensure that system RBAC policy enforcement is 4588  \nstill in effect while in maintenance mode.  4589  \nT&W:  CWE -862, CAPEC -122, CAPEC -560 4590  \nSASR -7.5  [~*/HB , ~*/CCOTS ] The following systems administration functions , if implemented 4591  \nin the CDS, must be performed while in maintenance mod e: 4592  \nT&W:  CWE -693, CAPEC -554 4593  \nSASR -7.5.1 [~*/HB, ~*/CCOTS] Network and Security Domain Configuration  4594  \nClarification:  This includes Adding/Deleting a NIC (if CDS support hot swappable 4595  \nNICs ); Enabling a NIC (e.g. , plumbing up the interface) ; enabling the NIC in the 4596  \nfirewall ; and changing netmask, default gateway/router, or IP Address. These changes 4597  \nare related to adding a  new domain to a CDS which cannot be done while in 4598  \nproduction/operational  mode since it potentially involves  cabling changes to the 4599  ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}362{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "361", "chunk": "\ndevice. See SASR -7.6.7 \u2013 7.6.9 for exceptions.  4600  \nT&W:  CWE -693, CAPEC -554 4601  \nSASR -7.5.2 [~*/HB, ~*/CCOTS] System patching  4602  \nT&W:  CWE -693, CAPEC -554 4603UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 175 of 397 SASR -7.5.3 [~*/HB, ~*/CCOTS] System tuning163  4604  \nT&W:  CWE -693, CAPEC -554 4605  \nSASR -7.5.4 [~*/HB, ~*/CCOTS] Full system recover y to an operational state from backup  4606  \nmedia  4607  \nT&W:  CWE -693, CAPEC -554 4608  \nSASR -7.5.5 [~*/HB, ~*/CCOTS] Installation of software including filters  if Modular  Pipeline  4609  \nComponent Requirements compliant filters and protocol adapters are NOT being used.  4610  \nT&W:  CWE -693, CAPEC -554 4611  \nSASR -7.5.6 [~*/HB, ~*/CCOTS] Fault analysis due to CDS hardware or software component 4612  \nfailure  to include  hardware replacement activities.  4613  \nT&W:  CWE -693, CAPEC -554 4614  \nSASR -7.5.7 [~*/HB, ~*/CCOTS] Manual Disk/Storage maintenance operations  4615  \nT&W:  CWE -693, CAPEC -554 4616  \nSASR -7.6  [~*/CCOTS] The following CDS system administration functions , if implemented in 4617  \nthe CDS, may be performed", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}363{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "362", "chunk": " in maintenance mode and/or during operation of the CDS:  4618  \nSASR -7.6.1  [~*/HB, ~*/CCOTS] Enable, Disable, Addition, Retirement164, Deletion and 4619  \nModification of Dataflow  Filter  Policy  4620  \nClarification:  This requirement must comply with SASR -7.8. 4621  \nSASR -7.6.2 [~*/HB, ~*/CCOTS] Enable, Disable, Addition, Modification, or Retiring165 of 4622  \nadministrative users  4623  \nSASR -7.6.3 [~*/HB, ~*/CCOTS] Enable, Disable, Addition, Modification , or Retiring  of non - 4624  \nadministrative users  4625  \nSASR -7.6.4 [~*/HB, ~*/CCOTS] System backup  4626  \nSASR -7.6.5  [~*/HB] Addition, modificati on, or deletion of SCAP  content , Antivirus  4627  \ndefinition s, and hardware assessment  definition/analytics (see SIR-3 requir ements).  4628  \n \n163 System tuning is the process of changing system operational par ameters that have little to no impact on security \nbut do impact the performance of the systems. Examples include: number of filter instances per data type, number of \nthreads per filter, filter timeouts, Ethernet frame size, and maximum number of concurrent  connections per PA per \ndomain.  \n164 A retired policy is one that is intended to be permanently disabled but left on the CDS to support viewing of audit \nrecords and filter reports. A retired polic", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}364{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "363", "chunk": "y may be reverted in accordance with SASR -11. Retired policies may be \ndeleted once their associa ted audit and filter reports are archived and deleted.  \n165 If a user no longer needs access to the CDS then the account should be \u201cretired\u201d. Retiring an account includes \nlocking the password and disabling login and shell access. A retired account cannot be b rought out of retirement.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 176 of 397 SASR -7.6.6 [~*/HB, ~*/CCOTS] Installation of Modular  Pipeline  Component Requirements 4629  \ncompliant filters and protocol adapters  4630  \nSASR -7.6.7 [~*/HB, ~*/CCOTS] Disabling a NIC for security or CDS stability /performance  4631  \nreasons . 4632  \nSASR -7.6.8 [~*/HB, ~*/CCOTS] Changing the IP Address o f a NIC but only if it is being 4633  \nchanged within the SAME subnet as the previous IP. The CDS software must verify that 4634  \nthe IP address is in the subnet prior to allowing it to be changed.  4635  \nSASR -7.6.9 [~*/HB, ~*/CCOTS] Updating the IP Firewalls to support enabling and disabling of 4636  \ndata flo ws. 4637  \nSASR -7.7 [~*/HB] Other functions may be", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}365{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "364", "chunk": " added to maintenance mode or operations mode , as 4638  \nneeded , provided they do not violate requirements or prohibitions contained/referenced 4639  \nelsewhere in this document . 4640  \nSASR -7.8 [~*/HB, ~*/CCOTS] Changes to dataflow  filter policy on a CDS shall not be applied 4641  \nto the system unless one of the following approaches has been implemented :  4642  \nRationale:  The goal of this requirement is t o ensure that content  is processed wholly 4643  \nunder the applicable policy. Content must never be processed against multiple  current  4644  \npolicies or partially processed and released.  4645  \nSASR -7.8.1 Deleted . 4646  \nSASR -7.8.2 [~*/HB, ~*/CCOTS] All content processing is stopped and all unfiltered or partially 4647  \nfiltered content is resubmitted to the filtering system,  is resubmitted to the filtering 4648  \nsystem after the new/ changed dataflow  filter policy is made active .  4649  \nT&W:  CWE -367, CWE -662, CAPEC -29 4650  \nSASR -7.8.3 [~*/HB, ~*/CCOTS] All content processing processes  are cleared, all content 4651  \ncurrently being processed is deleted , and the changed dataflow  filter policy is made 4652  \nactive.  4653  \nT&W:  CWE -367, C WE-662, CAPEC -29 4654  \nSASR -7.8.4 [~*/HB, ~*/CCOTS] All content being processed at the time the change o", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}366{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "365", "chunk": "ccurred 4655  \nwill complete  filtering against the policy originally assigned to them and new content 4656  \narriving at the CDS shall  use the new dataflow filter policy.  The new dataflow policy can 4657  \nthen be immediately activated.  This applies even if the original policy is deleted or 4658  \nretired, existing files will complete filtering against their preexisting  assigned policy.  4659  \nT&W:  CWE -367, CWE -662, CAPEC -29 4660  \nSASR -7.9 Operating system users ( e.g., administrator , non-administrator , CDS 4661  \nprocesses/services ) shall never be deleted.  4662  \nRationale:  Deleting us ers causes an inconsistency in the audit log . There is the potential 4663  \nfor userid reuse that could give a user access to content of the previous user , 4664UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 177 of 397 potentially caus ing inconsistencies on the system related to ACLs  with that userid, 4665  \nand in MLS syste ms (e.g., file and database)  it causes the loss of context of who 4666  \nowned the files.  4667  \nT&W:  CWE -223, CWE -286, CWE -668, CAPEC -233, TRTB -00037  4668  \nSASR -8 [~*/HB, ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}367{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "366", "chunk": "~*/CCOTS] The CDS may be rebooted to make filter policy change s effective 4669  \nso long as one of the methods  described in SASR -7.8 to resolve potential content filtering 4670  \ninconsistencies when the  policy is implemented.  4671  \nT&W:  CWE -367, CWE -662, CAPEC -29 4672  \nSASR -9 [~*/HB, ~*/CCOTS,  ~TCDS/* ] The CDS shall provide a mechanism to get the list of 4673  \nrunning processes (e.g., the equivalent of ps -ef) on the CDS.  4674  \nT&W:  CWE -223, CAPEC -161 4675  \nSASR -10 [~*/HB, ~*/CCOTS, ~TCDS /*] The CDS shall provide a mechanism to get the list of 4676  \nconnecti ons, network statistics, and what processes are bound to what TCP/UDP ports 4677  \nand physical interfaces  (e.g.,  the equivalent of netstat -a, netstat -i, and 4678  \nnetstat -s) on the CDS.   4679  \nClarification:  SASR -9 and SASR -10 are intended to support troubleshooting activities 4680  \non an operational CDS and to support CDS Incident Response activities.  4681  \nT&W:  CWE -223, CAPEC -161 4682  \nSASR -11  [~*/HB, ~*/CCOTS] System  and dataflow  configuration changes on  the CDS should  4683  \nbe tracked in a change control system  on the CDS.  4684  \nClarification: This requirement does not apply to software and patch installation s and 4685  \nchanges to non-administrator user and administr", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}368{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "367", "chunk": "ator  accounts on  the system, or other 4686  \nchanges that cannot  be safely reverted  (e.g., would cause an audit inconsistency) and 4687  \ntherefore these changes do not have to be tracked in the change control system.  4688  \nRationale: Most CDS have  limite d or no  ability  to track changes  (except via audit)  to the 4689  \nsystem via mechanism s that would allow them to be reverse d if it was determined the 4690  \nchange caused a problem.  This requirement and its dependent requirements were put 4691  \nin place to allow a CDS operator to safely undo changes to CDS witho ut having to 4692  \nreload and rerun the SBSA the CDS.  4693  \nSASR -11.1 The CDS should  have the ability to revert to a previous configuration . 4694  \nClarification: This does not apply to software and patch installations , users and 4695  \nadministrators of the system, or other changes that cannot  be safely reverted.  4696  \nSASR -11.2 The CDS should  support restoration of at least the last two system and dataflow 4697  \nconfiguration changes.  4698  \nSASR -11.3 If a system or dataflow change reversion depends on another change to also be 4699  \nundone  to maintain a valid operational state, it shall notify  and require  the administrator 4700UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}369{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "368", "chunk": ", FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 178 of 397 to select both to be reverted.  4701  \nSASR -11.4 The CDS administration tool shall  provide a mechanism to view  and compare  the 4702  \ncontents (e.g., the changes) of the change control system and select a previous 4703  \nconfiguration .  4704  \nSASR -11.4.1 The CDS must be in a maintenance mode (e.g., dataflows stopped) prior to 4705  \nallowing a system (non -dataflow) configuration to be changed.  4706  \nT&W: CWE -693, CAPEC -554, TRTB -00036  4707  \nSASR -11.4.2 If the reversion involves  changes that would normally require a reboot, then a 4708  \nreboot shall  be performed  and the system shall  boot back  into maintenance mode so that 4709  \nthe changes be ve rified  to be in effect.  4710  \nSASR -11.5 A CDS developer may put limits on  how far back in  the number of revision s the 4711  \nsystem will allow an administrator  to revert.  4712  \nSASR -11.6 A CDS developer may allow a revision to be undone and thus return the CDS to its 4713  \nprevious state prior to the revision occurring.  4714  \nSASR -11.7 The audit records shall not be reverted.  4715  \nT&W: CWE -223, TRTB -00037  4716  \nSASR -11.8 ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}370{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "369", "chunk": "A revision of dataflow policy shall result in new dataflow ID s being generated . 4717  \nT&W: CWE -223, TRTB -00037  4718  \nSASR -11.9 A revision results in the creation of a new configuration state  (and thus new commits 4719  \nto the configuration management system)  for the CDS. The previous state s are still stored 4720  \nin the configuration management sy stem  and are not deleted due to the state revision.  4721  \nClarification : If the last two CDS dataflow states are ABC and DEF  and the current state 4722  \nis GHI. If ABC is restored then the configuration  management system would show 4723  \nthat ABC, DEF, GHI, and ABC (but wi th a new ID) would be present in the 4724  \nconfiguration management system.  4725  \nT&W: CWE -223, TRTB -00037  4726  \nSASR -11.10 Revisions can only be restored for system and dataflow changes that occurred after 4727  \nthe last software and patches are applied . 4728  \nT&W: CWE -367, WRTB -00079, CAPEC -29 4729  \nSASR -11.11 The CDS administration tool shall display the changes between the current sys tem 4730  \nand the selected previous state prior to allowing the change to occur.  4731  \nT&W:  CWE -306, CAPEC -115 4732  \nSASR -11.12 If a software or patch installation would change the system in such a way that 4733  \nrestoring a previous stat", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}371{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "370", "chunk": "e is unsafe then software/patch installer shall notify the 4734  \nadministrator prior to software/patch installation and if the installation is allowed to 4735UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 179 of 397 proceed the previous states are either deleted or marked in such a way they cannot be 4736  \nreverted .  4737  \nT&W:  CWE -367, WRTB -00079 , CAPEC -29 4738  \nSASR -11.13  Role -based access control and Two -knowledgeable Person Control shall be 4739  \nimplemented  to approve reverting the configuration state of the CDS . See  RBACR -7.16, 4740  \nRBACR -3.1.11, RBACR -3.3.2 . 4741  \nT&W: WRTB -00071, CWE -285, CWE -349, CAPEC -1, CAPEC -176, CAPEC -75 4742  \nSASR -12 The CDS administration tools shall  provide a way to v iew any rul eset/schemas/filter 4743  \nconfigurations including those imported from removable media or via a  remote 4744  \nmanagement solution (e.g., GRMP).  4745  \nSASR -13 The CDS developer shall provide a mechanism to generate new disk encryption keys, 4746  \nupdate the TPM (if applicable) and re -encrypt the disk(s).  4747  \nRationale: This requirement is intended for  sit", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}372{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "371", "chunk": "uation s where the disk encryption key has 4748  \nbeen lost or otherwise compromised.   4749  \nSASR-14 The CDS developer shall provide a mechanism to initiate  a wipe of all CDS 4750  \ninformation from the disks  and delete and overwrite all disk encryption keys (e.g. , stored 4751  \nin a TPM).  4752  \nRationale: This requirement, while not sufficient to declassify the CDS, would be used 4753  \nprior to decommissioning the CDS or reloading the CDS with new software.  It could 4754  \nalso be used in cases where loss of the CDS might be imminent.  4755  \nSASR -14.1 The CDS shall require TKPC prior to wiping the system unless the wi ping is 4756  \ntriggered by a tamper event or zeroization action  (see TPR section) . 4757  \nSASR -15 [~*/HB, ~*/CCOTS] Any changes to the dataflow policy while the CDS is in an 4758  \noperational state (e.g., dataflows  are active) must implement one of the met hods 4759  \ndescribed in SASR -7.8 to resolve potential content filtering inconsistencies with policy.  4760  \nSASR -16 [~*/HB, ~*/CCOTS] The CDS shall lock the audit configuration from being changed 4761  \nwhile the system is in an operational state166. 4762  \nSASR -16.1 [~*/HB, ~*/CCOTS] The CDS shall allow the audit configuration to be update d 4763  \nwhile in maintenance mode.  4764  \n10.6 De", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}373{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "372", "chunk": "velopment Processes  & Mechanisms  Requiremen ts (DPMR)  4765  \nDPMR -1 The CDS developer shall use a version control system for configuration control of 4766  \nchanges to the software  and hardware ( e.g., VHDL , code, components, board design) . 4767  \n \n166 https://www.digitalocean.com/community/tutorials/how -to-write -custom -system -audit -rules -on-centos -7UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 180 of 397 T&W:  CWE -489, WRTB -00063, WRTB -00064, WRTB -00065 , TRTB -00048, CAPEC - 4768  \n121, TRTB -00051  4769  \nDPMR -1.1 CDS developer commits to the version control system shall be digital ly signed by the 4770  \ndeveloper.  4771  \nT&W:  CWE -287, CAPEC -438, CAPEC -268 4772  \nDPMR -2 The CDS developer shall use a software system to manage CDS requirements and 4773  \nderived requirement s and map them to  code,  test cases , and test procedures . 4774  \nT&W:  WRTB -00066, WRTB -00067, CAPEC -233, CAPEC -554 4775  \nDPMR -3 The CDS developer shall  implement and use the Microsoft \u00ae Security Development 4776  \nLifecycle (SDL)167 or similar security engineering process to ensure quality secure c", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}374{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "373", "chunk": "ode 4777  \nis developed . The security engineering process shall  implement the following processes 4778  \n(derived from the Microsoft SDL):  4779  \n\u2022 Provide security training for software development and testing staff  (e.g., secure 4780  \ncoding practices, how to use and develop for SELinux, developing  and using  4781  \nattack -trees/threat modeling, adversarial emulation/penetration testing,  operating 4782  \nsystem security best practices , web application security best practices, etc. ) 4783  \n\u2022 Define security requirements  4784  \n\u2022 Define metric  and compliance reporting  4785  \n\u2022 Perform threat m odeling  4786  \n\u2022 Establish design requirements  4787  \n\u2022 Use USG approved cryptographic standards  4788  \n\u2022 Manage the security risk of using third -party components  4789  \n\u2022 Use approved tools  4790  \n\u2022 Perform static analysis security testing  4791  \n\u2022 Perform dynamic analysis security testing  4792  \n\u2022 Perform penetratio n testing  4793  \n\u2022 Establish an incident response process  4794  \nClarification:  Some DevSecOps processes may meet this requirement but many 4795  \nDevSecOps \u201csecurity practices\u201d are more focused on coding mistakes  that lead to  4796  \nsoftware  vulnerabilities than overall  security desig n and threat modeling . 4797  \n \n167 https://www.microsoft.com/e", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}375{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "374", "chunk": "n -us/securityengineering/sdl  and https://www.microsoft.com/en -\nus/securityengineering/osaUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 181 of 397 DPMR -3.1 The developer shall maintain and provide documentation describing the security 4798  \ndevelopment lifecycle process  that was implemented . 4799  \nDPMR -4 [~*/HB , ~*/CCOTS ] Compiled p rograming languages that have built -in 4800  \nstack/heap /memory  protections ( e.g., Java\u00ae , C#, Swift \u00ae, Ada, Rust\u2122, Go, Python ) shall 4801  \nbe used to implement  all CDS  components including dataflow  processes  and protocol 4802  \nadapters  rather than languages  that do  not (C, Fortran, C ++, etc. )168. 4803  \nClarification:  Existing protocol adapters , filters , and CDS components  do not have be 4804  \nrewritte n. However, if changes are made to them other than to fix security or 4805  \nfunctional issues  (with no new functionality) then the components  must be rewritten 4806  \nin a safe programming language.  Changes made to comply with RTB operating 4807  \nsystem interaction requirements (e.g., support for SECCOMP) does not require a 4808  \nrewrite of t", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}376{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "375", "chunk": "he component but adding new capabilities  (e.g., new d ata types/formats)  4809  \nwould generally require a reimplementation.  Existing CDS may continue to use 4810  \nexisting C/C++ (or similar unsafe language) based components , however new 4811  \ncomponents must use memory -safe languages. Third party (open source or closed 4812  \nsource) libraries implemented in non -memory safe languages may continue to be 4813  \nused, but their use is strongly discouraged. This requirement does not apply to kernel 4814  \nmodules  and device drivers . Langauges like Python can be used if they are compiled 4815  \nto executable  form (e.g, a Linux ELF binary) and the compiler/interpreter is not 4816  \ninstalled on the system.  4817  \nRationale: Modern memory -safe languages have proven reliab ility, performance and 4818  \nsafety over unsafe languages like C. The security benefits now outweigh  the 4819  \ndisadvantages.  4820  \nT&W:  CWE -119, CWE -121, CWE -122, CWE -190, CWE -772, CAPEC -123, CAPEC - 4821  \n129, CAPEC -130, CAPEC -131, CAPEC -92 4822  \nDPMR -5 [~*/HB] The CDS shall  not have programming language compilers ( e.g., GCC, JDK , 4823  \nLLVM ) installed on the system.  4824  \nT&W:  WRTB -00068, CAPEC -549 4825  \nDPMR -6 [~*/HB] L anguage runtime environments ( e.g., JRE) may be inst", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}377{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "376", "chunk": "alled  on the CDS . 4826  \nDPMR -7 [~*/HB] The CDS shall not use i nterpreted169 programming languages ( e.g., Perl, 4827  \nPython, JavaScript , and R uby) to implement a protocol adapter  or filter in any  dataflow  4828  \n \n168 https:/ /www.zdnet.com/article/microsoft -70-percent -of-all-security -bugs -are-memory -safety -issues , \nhttps://blog.kernelcare.com/vulnerability/a -guide -to-memory -vulnerabilities -in-the-linux -kernel , \nhttps://blog.kernelcare.com/vulnerability/identify -mitigate -prevent -buffer -overflow -attacks -on-your-systems  \n169 For the purposes of this document, if a programming language is compiled via a separate compiler then generates \nbyte code and the byte code is executed in a run time environment on the CDS then the programming lang uage is \nnot considered interpreted.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 182 of 397 when the filter does not leverage the unique attributes of the interpreted language  as they 4829  \nrelate to that dataflow  (e.g., using JavaScript  for XML schema validation is not allowed ).  4830  \nRationale:  The use of interpreted languages , espe", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}378{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "377", "chunk": "cially those that support dynamic 4831  \ncompilation , substantially increase the risk of system compromis e due to remote code 4832  \ninjection. For example , the PHP and JavaScript eval()  command allows arbitrary 4833  \ncode to be executed and is frequently misused by malicious actors . Additionally, the 4834  \ninstallation of interpreters and compilers on a CDS give adversaries mo re flexibility 4835  \nin how to implement an attack against a system.  4836  \nClarification:  For the purposes of this document, Java\u00ae and .Net based languages using 4837  \ntheir language runtimes are not considered interpreted.  Compiled languages do not 4838  \nhave the inherent abilit y to execute dynamically compiled code (e.g., the use of 4839  \nexec()  and popen()  is a different issue and is covered in GDFR -45) . If a 4840  \nnormally interpreted or dynamically compiled language is compiled into a native 4841  \noperating system binary  (e.g., a Linux\u00ae ELF binary) , then that is allowed  if the 4842  \nlanguage is a memory -safe language.  An interpreted language  (e.g., Python ), can be 4843  \nused for CDS configuration, administration, and installation programs provided the 4844  \napplication is compiled into exe cutable form , the language does implement an 4845  \neval()  equivalent capabilit", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}379{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "378", "chunk": "y,  and the interpreter/compiler is not installed on the 4846  \nsystem.  4847  \nT&W:  CWE -94, CWE -96, CWE -470, CWE -627, CWE -914, CWE -915, CAPEC -35, 4848  \nCAPEC -77, CAPEC -242 4849  \nDPMR -8 [~*/HB]  Some interpreted programming languages  (e.g., Lua, XSLT ) may be used to 4850  \nimplement  a filter if the purpose and actual use of that language  is to leverage  the 4851  \ninterpreted nature of the programming language to filter the data.  4852  \nClarification: The p rimary use case  is in fixed for mat data parsers that need \u201cTur ing 4853  \nComplete \u201d (or close to it) languages to sufficient ly parse and filter the data  (e.g., 4854  \nadvanced sanitization rules, co -constraint s, etc.) . 4855  \nDPMR -8.1  [~*/HB] When using an interpreted programming language to implement a filter , all 4856  \nuser-accessible access to system  level function calls  (e.g., popen(), system(), 4857  \nexec(), fork(), kill(), signal()  types of calls) shall be removed from the 4858  \nprogramming language \u2019s170 interpreter or language virtual machine  in such a way that the 4859  \nprogramming language cannot  execute those functions  or they can blocked from use 4860  \nusing SECCOMP. System level function s for the purpose of dataflow IPC within the 4861  \nCDS are allowed.  4862  \nRationale: ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}380{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "379", "chunk": " The intent behind this requirement is to restrict the ability of filter to interact 4863  \nwith the operating system and allow an attacker to move laterally through the CDS, 4864  \n \n170 This may require a custom build of the interpreted language to remove this functionality.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 183 of 397 compromise other  CDS processes, or exfiltration CDS process information off the 4865  \nCDS. These restrictions are essentially no different than those placed on other filters 4866  \nthat are not running in an interpreter.  The use of third -party libraries to avoid this 4867  \nrestriction is no t allowed.  4868  \nT&W:  CWE -1125, CWE -272, WRTB -00069, CAPEC -234 4869  \nDPMR -8.2  [~*/HB] Network I/O system calls shall be removed from the programming 4870  \nlanguage\u2019s  interpreter or language virtual machine  or restricted via SECCOMP.  4871  \nRationale:  See DPMR -8.1 rationale.  4872  \nT&W:  CWE -1125, CWE -272, WRTB -00025, WRTB -00069, CAPEC -234, TRTB - 4873  \n00034  4874  \nDPMR -9 [~*/HB] The CDS may use interpreted programming languages  for any local 4875  \nGraphical Us", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}381{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "380", "chunk": "er Interface (GUI) if properly protected/isolated with DAC and MAC.  4876  \nDPMR -10 [~*/HB] CDS developers shall provide operating system and CDS software 4877  \napplication patches for their CDS in a timely \u2013 at a minimum, quarterly \u2013 manner  to 4878  \ncomply with U.S. Cyber Command (CYBERCOM)  Information Assurance Vulnerability 4879  \nAlert s (IAVA s) and operating system/application vendor Common Vulnerabilities and 4880  \nExposures (CVEs) . 4881  \nClarification:  If there are no applicable CVEs or other vulnerabilities the n a quarterly 4882  \nupdate is not necessary  (at that point in time).  4883  \nT&W:  WRTB -00022  , CAPEC -233, CAPEC -310 4884  \nDPMR -11 All personnel (e.g., program managers, testers, developers, system administrators, 4885  \nnetwork administrators) with access to the CDS technology  shall hold an active USG  4886  \nsecurity clearance  of Secret or higher .  Developers of broadly171 available commercial 4887  \nopen source or clo sed source components are n ot required to have a clearance . 4888  \nT&W:  WRTB -00060 , CAPEC -443, TRTB -00053  4889  \nDPMR -12 CDS design, development , documentation generation /editing , and developer testing  4890  \nshall be conducted on physically  or cryptographically isolated  unclassified or 4891  \nappropriately class", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}382{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "381", "chunk": "ified  networks that are not connected to the Non -Classified Internet 4892  \nProtocol Router Network ( NIPRNet ) or the Internet.   This applies to both hardware and 4893  \nsoftware based CDS.  4894  \nRationale: This requirement is intended to prevent theft and/or modification of CDS 4895  \nsoftware and designs. The 2020 SUNBURST172 attack is a stellar example why this 4896  \n \n171 The component is broadly available world -wide, and its export is not restricted under ITAR.  \n172 See https://www.fireeye.com/blog /threat -research/2020/12/evasive -attacker -leverages -solarwinds -supply -chain -UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 184 of 397 requirement exists and the damage that can be caused i f the development env ironment 4897  \nis not properly isolated.  4898  \nT&W:  CWE -527, CWE -829, WRTB -00058, CAPEC -445, CAPEC -447, CAPEC -511, 4899  \nCAPEC -537, CAPEC -670, CAPEC -672, CAPEC -678, TRTB -00053  4900  \nDPMR -12.1 [CCOTS] The integration, customization,  and development of any custom code,  as 4901  \nwell as the documenting of a CCOTS solution , shall be performed on a physically or 4902 ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}383{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "382", "chunk": " \ncryptographically isolated  unclassified or appropriately classified network.   4903  \nT&W:  CWE -527, CWE -829, WRTB -00058, CAPEC -447, CAPEC -445, CAP EC-511, 4904  \nCAPEC -537, CAPEC -670, CAPEC -672, CAPEC -678, TRTB -00053  4905  \nDPMR -12.2 Software, documents, and data shall only be transferred into the development 4906  \nenvironment via a n NCDSMO evaluated one-way transfer device.  4907  \nT&W:  WRTB -00059, WRTB -00061, CAPEC -439, CAPEC -447, CAPEC -670, CAPEC - 4908  \n445, CAPEC -511, CAPEC -537, CAPEC -672, CAPEC -678, TRTB -00053  4909  \nDPMR -12.3 Only write -once optical removable media ( e.g., DVD, Blu -Ray, CD) shall be used 4910  \nto remove data, documents , or software from the development and testing environment s. 4911  \nT&W:  WRTB -00059  , CAPEC -670, CAPEC -447, CAPEC -445, CAPEC -511, CAPEC - 4912  \n537, CAPEC -672, CAPEC -678, TRTB -00053  4913  \nDPMR -12.4 USB, Thu nderbolt, or Firewire (e.g., IEEE -1394) connected  media ( e.g., hard drive, 4914  \nflash/solid state based) shall not be used to transfer  data into or out of the development 4915  \nand testing environment s. 4916  \nT&W:  CWE -345, WRTB -00059 , CAPEC -445, CAPEC -447, CAPEC -511, CAPEC -537, 4917  \nCAPEC -665, CAPEC -670, CAPEC -672, CAPEC -678, TRTB -00053  4918  \nDPMR -12.5 The connec", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}384{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "383", "chunk": "tion of multiple  development  and testing  environment  locations  shall be 4919  \nimplemented using an NSA -approved Type -1 Network Encryptor , an NSA -approved 4920  \nCryptographic High Value Product (CHVP)173, or an NSA -approved Commercial 4921  \nSolutions for Classified174 (CSfC ) solution.  4922  \nT&W:  CWE -311, CAPEC -157 4923  \nDPMR -12.6 Remote access to the development and testing environment s shall be implemented 4924  \nusing an NSA -approved Type -1 Network Encryptor , an NSA -approved Cryptographic 4925  \nHigh Value Product, or an NSA -approved CSfC  solution.  4926  \n \ncompromises -with-sunburst -backdoor.html  and https://blog.reversinglabs.com/blog/sunburst -the-next-level -of-\nstealth  \n173 See CNSSI 4031 Cryptographic High Value Products (CHVP) . \nhttps: //www.cnss.gov/CNSS/issuances/Instructions.cfm   \n174 https://www.nsa.gov/Resources/Commercial -Solutions -for-Classified -Program/UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 185 of 397 T&W:  CWE -311, CAPEC -157 4927  \nDPMR -12.7 CSfC -based cryptographic  solutions must implement  the current , approved Mobile 4928  \nAccess Capabi", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}385{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "384", "chunk": "lity Package (MACP) or Multi -Site Connectivity Capability Packag e. 4929  \nT&W:  CWE -200, CWE -669, CWE -1240, WRTB -00055, TRTB -00040, TRTB -00042, 4930  \nTRTB -00050  4931  \nDPMR -12.7.1  If the MACP is used, the endpoint must be running a n USG approved V irtual 4932  \nMachine based Access CDS  or two physically separate independent VPN endpoint s 4933  \ninline with a stateless workstation.  4934  \nT&W:  CWE -200, CWE -669, CWE -1240, WRTB -00055, TRTB -00040, TRTB -00042, 4935  \nTRTB -00050  4936  \nDPMR -12.8 No developer  remote access systems , including user endpoints ( e.g., workstation s, 4937  \nlaptop s), shall store CDS source code  or other design -, development -, integration -, or 4938  \ndeployment -related artifacts . 4939  \nT&W:  CWE -668, CWE -693, CAPEC -447, TRTB -00053, CAPEC -670, CAPEC -445, 4940  \nCAPEC -511, CAPEC -537, CA PEC-672, CAPEC -678 4941  \nDPMR -12.9 Remote access to the development environment from user endpoint s that are not 4942  \nlocated on its physical local area network  (LAN) , shall be via approved cryptographic 4943  \nmeans  and shall use a Virtual  Desktop Infrastructure (VDI) ( e.g., VNC, RDP, P coIP, 4944  \nICA) . 4945  \nT&W:  CWE -668, CWE -693, CAPEC -447, TRTB -00053, CAPEC -670, CAPEC -445, 4946  \nCAPEC -511, CAPEC -537, CAPEC", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}386{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "385", "chunk": " -672, CAPEC -678 4947  \nDPMR -12.10 Hardware board/chip  design schematics and supporting technical artifacts may be 4948  \ntransferred  from the development environment, via optical media, so they can be 4949  \ntransferred to appropriate companies/organizations for manufacture of the components.  4950  \nDPMR -12.11 Testing of hardware component s independently and thus not integrated together 4951  \nmay be implemented  outside of the development environment ( e.g., at manufacturer).  4952  \nDPMR -12.12 Testing of integrated systems components including factory test build s shall  be 4953  \ntested in physically isolated environment .  4954  \nT&W:  WRTB -00058  , CAPEC -670, CAPEC -445, CAPEC -511, CAPEC -537, CAPEC - 4955  \n672, CAPEC -678, CAPEC -447, TRTB -00053  4956  \nDPMR -12.13 Developers  shall  verify the provenance of all  software packages  from Internet 4957  \nsites.  4958UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 186 of 397 Rationale: This is intended to reduce  package  typosqua tting175 and dependency 4959  \nconfusion attacks176.  Vetting the provenance of software from Internet sites tha", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}387{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "386", "chunk": "t 4960  \nallow the  public to post software packages  is particularly important due to the 4961  \nincrease in package typosqua tting attacks.   4962  \nT&W : CWE -427, CAPEC -446 4963  \nDPMR -12.14  All content entering  and exiting  the development environment shall be logged.   4964  \nT&W:  CWE -778, CWE -223, TRTB -00037  4965  \nDPMR -12.15 The isolated development environment shall not allow the importation of software 4966  \npackages for software developed inside  the isolated development environment.  4967  \nClarification:  This requirement is intended to prevent the  ingest ion of malicious source  4968  \ncode  from environments external to the development environment that could result in 4969  \noverwriting/replacing CDS source code with malicious code.  For example, one 4970  \npotential adversary attack against a CDS would be for an adversary compromise a 4971  \nInternet respository and place a package in the repository that replaces an internally 4972  \ndeveloped module with a malicious module . Depending on how the package retrieval 4973  \nsystem  works it could pull in this package , move it up the development environment, 4974  \nand overwrite an existing component . This is basically a more elaborate variant of the 4975  \ndependency confusion attacks.  This requirement", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}388{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "387", "chunk": " also applies to customers de veloping 4976  \ntheir own Customer Developed  Modular Pipeline Components.  4977  \nRationale: Same as DPMR -12.13   4978  \nT&W : CWE -427, CAPEC -446, MITRE ATT&CK  T1195.002  4979  \nDPMR -13  Deleted.   4980  \nDPMR -14 [~*/HB]  The CDS should use the versions of programming languages that are 4981  \nofficially supported by the operating system vendor.  4982  \nRationale:  Programming language versions that are not supported by the operating 4983  \nsystem vendor increases the risk of incompatibilities w ith the operating system and 4984  \nreduces the likelihood and availability of security patches.  4985  \nT&W:  CWE -1329, CWE -684, WRTB -00062, CAPEC -310, CAPEC -69 4986  \nDPMR -15 CDS developers shall provide firmware (e.g., UEFI\u00ae , FPGA logic , RAID Controller 4987  \nfirmware, NIC firmware , microcode ) patches to the ir CDS customers that comply with 4988  \n \n175 https://www.darkreading.com/vulnerabilities -threats/beware -the-package -typosquatting -supply -chain -attack , \nhttps://snyk.io/blog/t yposquatting -attacks , https://bytesafe.dev/posts/understanding -typosquatting -methods/  \n176 See https://medium.com/@alex.birsan/dependency -confusion -4a5d60fec610  , \nhttps://redhuntlabs.com/blog/dependency -confusion -attack -what -why-and-how.html", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}389{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "388", "chunk": "  , https://snyk.io/blog/detect -\nprevent -dependency -confusion -attacks -npm-supply -chain -security/UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 187 of 397 U.S. Cyber Command (CYBERCOM) Information Assurance Vulnerability Alerts 4989  \n(IAVAs) and hardware  vendor Common Vulnerabilities and Exposures (CVEs).  4990  \nT&W:  WRTB -00022  , CAPEC -233, CAPEC -310 4991  \nDPMR -16 CDS developers shall provide to the NCDSMO unique email distribution lists for 4992  \nqueries related to the CDS Procurement, CDS Engineering, a nd CDS Incident Response.  4993  \nDPMR -17 Each CDS developer created document shall have a document ID, a version, date of 4994  \nlast change/release , a change/revision history,  and appropriate security markings. See the 4995  \nNCDSMO document Security Assessment of Cross Domain Solutions (CDS): Process 4996  \nand Requirements  for suggested security markings for the documents.  4997  \nDPMR -18 [~*/HB] The CDS shall not use interpreted177 programming l anguages (e.g., Perl, 4998  \nPython, JavaScript , and R uby) to implement protocol adapters or any security enforcing 4999  \nfunctions /", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}390{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "389", "chunk": "applications  (including the JAL subsystem)  in the CDS (except as stated 5000  \nabove).  5001  \nT&W:  CWE -94, CAPEC -35, CAPEC -242 5002  \nDPMR -19 [~*/HB]  The CDS developer should use different compilers for different 5003  \nimplementations of filters and protocol adapte rs. 5004  \nT&W:  WRTB -00077, WRTB -00020 , TRTB -00055, TRTB -00029  5005  \nDPMR -20 [~*/HB]  The CDS developer shall  minimize the compiler optimizations that are use d 5006  \nto reduce the possibility of optimization induced security flaws.  5007  \nRationale:  Recent research has shown that compiler optimizations can negatively impact 5008  \nthe security of software.178 Compiler diversity can also reduce the impact of compiler 5009  \nflaws.  5010  \nT&W:  CWE -14, CWE -733, CAPEC -92, CAPEC -100, CAPEC -540 5011  \nDPMR -21 [~*/HB] CDS developers shall ensure that all internal 3rd party  software components 5012  \nused by the CDS are  a currently supported version  by the developer of the 3rd party  5013  \nsoftware components . 5014  \nClarification : Rules for operating systems are described separately in this document.   5015  \nDPMR -22 [~*/HB] If a 3rd party  component used in a CDS bec omes  unsu pported by the 3rd 5016  \n \n177 For the purposes of this document, if a programming language is compiled via a", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}391{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "390", "chunk": " se parate compiler than generates \nbyte code and the byte code is executed in a run time environment on the CDS then the programming language is \nnot considered interpreted.  \n178 Some examples: https://arc.aiaa.org/doi/10.2514/1.I010699 , https://www.microsoft.com/ en-\nus/research/blog/getting -compilers -right -secure -software , https://www.redhat.com/en/blog/security -flaws -caused -\ncompiler -optimizations , https://nebelwelt.net/files/15LangSec.pdfUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 188 of 397 party prior to the CDS becoming sunset, then the component shall be upgraded to a 5017  \nsupported version , or replaced with an equivalent supported component from a different 5018  \nthird party.  5019  \nClarification: Rules for operating systems are described separately in this document. 5020  \nImplementation of the Modular  Pipeline  Component  Requirements ( MPCR) in this 5021  \ndocument reduces some of the complexity in implementing this requirement.  5022  \n10.7 System Installation  and Hardware Configura tion Requirements  5023  \n(SIHCR)  5024  \nThis section covers  the requirements for instal", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}392{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "391", "chunk": "ling and configuring a CD S. One of the major 5025  \nfocus areas of RTB is that the installation and configuration process for a CDS is clear, 5026  \nrepeatable, verifiable, and can be consistently implemented across multiple instances of a CDS a t 5027  \na site. 5028  \nSIHCR -1 [~*/HB] The CDS  installation system  shall use a  parameterized  and deterministic  5029  \nsemi -automated installation process .  5030  \nClarification:  Parameters include (but not limited to) setting the hostname, selecting the 5031  \ninterfaces, entering network settings, and selecting softw are packages (e.g., protocol 5032  \nadapters, filter ing packages ). Semi -automated is defined as entering the configuration 5033  \nparameters and the rest of installation of the software is automated  (i.e., hands -off). 5034  \nRationale:  The intent  is to eliminate the historical  problems with manual command -line 5035  \ntype of installations that involved dozens or hundreds of manual steps . Additionally, 5036  \nwith the use of \u201canswer files\u201d  to support  automated installations enables scalable 5037  \nefficient testing  of the CDS.  5038  \nT&W:  WRTB -00056  , TRTB -00050, TRTB -00052  5039  \nSIHCR -1.1 [~*/HB]  CDS may use \u201canswer files\u201d to support automated installation and 5040  \nprovisioning of CDS.  50", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}393{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "392", "chunk": "41  \nClarification:  The GAR -7 UUID requirement can be provided by the \u201canswer file\u201d.  5042  \nSIHCR -2 [~*/HB] The CDS installation system shall have the ability to query the administrator  5043  \nfor the configuration information and complete the software installation via  automated 5044  \nmeans . 5045  \nT&W:  CWE -637, CWE -1288, WRTB -00056 , TRTB -00050  5046  \nSIHCR -3 [~*/HB]  The CDS  installation system  shall use one or more of the following 5047  \ninstallation mechanisms:  5048  \nSIHCR -3.1 [~*/HB] Removable media -based  installer that is built using an automated build 5049  \nprocess  and implements SIR-1 secure boot requirements.  5050  \nClarification:  An installer , in this context , is a piece of software that steps a user through 5051UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 189 of 397 the individual steps  of installing and , optionally, configuring the system.  This is 5052  \nsimilar to the graphical installers used to install a modern operating system like 5053  \nLinux\u00ae.   Removable media can include CDR OM/DVD -ROM, USB Flash Drive, or 5054  \nexternal hard disk. The CDS hardware is", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}394{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "393", "chunk": " booted off the removable media to start the 5055  \ninstallation process.  5056  \nT&W:  CWE -353, CWE -354, CWE -693, CWE -829, WRTB -00050, CAPEC -439, 5057  \nCAPEC -552, CAPEC -523 5058  \nSIHCR -3.2 [~*/HB] Disk-based copy mechanism s (e.g., Linux\u00ae  dd command) may be used for 5059  \nCDS installation ( e.g., copying a complete d isk image to the server\u2019s disk) .  5060  \nClarification:  This is primarily intended for weapon systems or similar operational 5061  \nenvironments where every install of the CDS is 100% identical.  5062  \nSIHCR -3.2.1 [~*/HB] The CDS developer must provide detailed documentation  for all the steps 5063  \nused in the disk imag e creation process and be able to demonstrate how the disk images 5064  \nare built.  5065  \nSIHCR -3.2.2 [~*/HB] Images shall be built in compliance with the rest of requirements in the 5066  \nSIHCR section.   5067  \nSIHCR -3.2.3 [~*/HB]  CDS images must be signed and SIR -1 requirements still apply.  5068  \nT&W:  CWE -353, CWE -354, WRTB -00050 , CAPEC -439, CAPEC -523 5069  \nSIHCR -3.3 [~*/HB] Network based installation using the  Preboot eXecution Environment 5070  \n(PXE)179 or UEFI HTTP Boot180 to remote ly install the CDS software shall  be configured 5071  \nfor secure boot (see SIR-1) to prevent unauthorized software  from be", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}395{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "394", "chunk": "ing installed on the 5072  \nCDS hardware . Images shall be built in compliance with the rest of requirements in the 5073  \nSIHCR section.  5074  \nT&W:  CWE -284, WRTB -00050, CAPEC -1, CAPEC -439, CAPEC -552 5075  \nSIHCR -3.3.1 [~*/HB] Software -based  CDS shall use a dedicated system high management 5076  \nnetwork for the remote install capability.  5077  \nT&W:  WRTB -00025, WRTB -00051 , CAPEC -22, CAPEC -439 5078  \nSIHCR -3.3.2 [~*/HB] The CDS may use the system high dataflow network for the remote 5079  \ninstall capability in situations where a dedicated system high management network is not 5080  \noperationally possible.  5081  \nT&W:  WRTB -00025, WRTB -00051 , CAPEC -22, CAPEC -439 5082  \nSIHCR -3.3.3 [~*/HB] In PDC  based CDS the systems shall use a dedicated management 5083  \n \n179 https://en.wikipedia.org/wiki/Preboot_Execution_Environment  \n180 https://www .uefi.org/sites/default/files/resources/FINAL%20Pres4%20UEFI%20HTTP%20Boot.pdfUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 190 of 397 network for remote installation that is operated at the highest level an individual 5084  \ncomponent is opera", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}396{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "395", "chunk": "ting. For example, a NIPRnet connected pitcher could be remotely 5085  \ninstalled  from  a Controlled Uncla ssified CDS  management network , while its SIPRnet 5086  \nconnected catcher could be remotely installed from  a Secret CDS management network.  5087  \nT&W:  WRTB -00014, WRTB -00025, WRTB -00051 , CAPEC -22, CAPEC -439, TRTB - 5088  \n00012  5089  \nSIHCR -3.3.4 [~*/HB] The CDS shall be configured with the certificate of the UEFI HTTP Boot 5090  \nserver (e.g., the CMS).  5091  \nClarification: Some UEFI implementations may not support this.  5092  \nSIHCR -3.3.5 [~*/HB] The CDS shall be configured to use HTTPS for UEFI HTTP  Boot . 5093  \nClarification: Some UEFI implementations may not support this.  5094  \nSIHCR -4 Merged into SIHCR -3.1 5095  \nSIHCR -5 [~*/HB] The CDS installation system  shall  use the operating system\u2019s  package 5096  \nmanagement system ( e.g., rpm, pkg) for sof tware installation  of all components . This 5097  \nincludes compliance with the operating syste m package management system\u2019s  software 5098  \npackaging guidelines  including validation signed packages . This also applies to the 5099  \ncreation of CDS disk images  (e.g., SIHCR -3.2). 5100  \nT&W:  CWE -829, CWE -345, CWE -354, CWE -295, CAPEC -148, CAPEC -439, CAPEC - 5101  \n558, CAPEC -475 5102  ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}397{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "396", "chunk": "\nSIHCR -5.1 [~*/HB] For CDS operating on  Red Hat\u00ae  Enterprise Linux\u00ae , the CDS shall comply 5103  \nwith the Red Hat\u00ae  Package Manager (RPM)  Packaging Guidelines.181 5104  \nSIHCR -5.1.1 The use of \u201cFeature RPMs182\u201d should be used as way to handle the dependencies 5105  \nof multiple software RPMs that are part a single subsystem.  5106  \nClarification: For example, a feature RPM could be used to handle the dependencies of 5107  \nan XML pipeline that contained separate RPM packages for each component of an 5108  \nXML pipeline: 2 XML validation filters, 2 dirty word filters, an XSLT filter, and a 5109  \nSchematron filter. This would allow the individual versioning of individual 5110  \ncomponent RPMs wi thout impacting the versioning of other components.  5111  \nSIHCR -5.1.2 If \u201cFeature RPM\u201d subsystem\u2019s components are updated then the \u201cFeature RPM\u201d 5112  \nversion (and thus RPM) shall be updated.  5113  \n \n181 https://access.redhat.com/documentation/en -\nus/red_hat_enterprise_linux/8/html/packaging_and_distributing_software/index.  \n182 This is also called Module  Streams . Feature  RPM or Module  Streams are a grouping of RPMs that belong to \ntogether. For example, an application might include separate RPMS for the binaries, libraries, configuration files, \nand documentation.UNCLASS", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}398{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "397", "chunk": "IFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 191 of 397 SIHCR -5.2 [~*/HB] The CDS developer shall not alter operating  system vendor packages nor 5114  \nre-sign unmodified pack ages. 5115  \nRationale:  The USG community is explicitly trusting  the operating system vendor\u2019s  5116  \ntesting of their software  packages. If the CDS developer modifies the operating 5117  \nsystem packages the burden is now on the CDS developer to test the packages and 5118  \nprovide that evidence.  However, the CDS developer is still required to validate that 5119  \ntheir softw are still works as intended with the update d operating system vendor 5120  \npatches.  5121  \nT&W: CWE -348, WRTB -00057, TRTB -00051, CAPEC -69 5122  \nSIHCR -5.2.1 If the operating system package must be modified (e .g., to remove functionality), 5123  \nthen the package is now considered a CDS developer package and the other requirements 5124  \nin the document related to CDS developer packages shall apply.  5125  \nSIHCR -5.3 [~*/HB] The CDS developer shall sign their software packages and ensure the 5126  \noperating system validate s the signature and integri", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}399{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "398", "chunk": "ty of the package during installation.  5127  \nT&W:  CWE -345, CWE -354, CAPEC -148 5128  \nSIHCR -5.4 Deleted . Duplicates S IHCR -3.2 5129  \nSIHCR -5.5 [~*/HB]  The installation of software package s shall not overwrite existing 5130  \nconfiguration files and settings  of prior installed versions of the package . 5131  \nT&W:  WRTB -00075, CAPEC -180 5132  \nSIHCR -6 [~*/HB] The CDS installation system shall not install the entire CDS  software  as a 5133  \nsingle package  (e.g., a single RPM) . 5134  \n Rationale: Monolithic  software install s have historically resulted in infrequent software 5135  \npatching due to the complexity of building and installing a new monolithic software 5136  \nimage . Monolithic images add unnecessary complexity to the system.  5137  \nSIHCR -7 [~*/HB] The CDS installatio n and patching system  shall install i ndividual components  5138  \nvia separate packages . 5139  \n Clarification: A component is a unique piece of software performing a single function 5140  \n(e.g., a protocol adapter, filter, domain router). A subsystem is a grouping of components  5141  \nthat are installed together and depend on each other to operate . For example, an HTTP 5142  \nprotocol adapter, an XML schema validation filter, and an XML stylesheet 5143  \ntransformation  filter ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}400{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "399", "chunk": "are all components. An XML Pipeline is a subsystem that could 5144  \nconsist of two HTTP protocol adapters, two XML schema validation filters, and two 5145  \nXML stylesheet transformation filters.  5146  \nSIHCR -7.1 Deleted . Duplicates SIHCR -3.2  5147  \nSIHCR -7.2 [~*/HB] The CDS installation  and patching  system  shall install each filter via its 5148  \nown separate package . 5149UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 192 of 397 SIHCR -7.3 [~*/HB] The CDS  installation and patching system  shall install each protocol  5150  \nadapter via its own separate package .  5151  \nSIHCR -7.4 [~*/HB] CDS that leverage operating systems that support modular MAC pol icy 5152  \n(e.g., SELinux -based)  shall install  subsystem -specific  modular MAC policy for each 5153  \nsubsys tem. Examples of subsystems include: integrity monitoring, audit, remote 5154  \nmanagement, and system administration graphic user interfaces.  5155  \nSIHCR -7.5 [~*/HB] The CDS shall  ensure  that a dataflow\u2019s dependencies (e.g., filters, protocol 5156  \nadapters , supporting libraries ) are installed  prior to allowing the dataflow t", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}401{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "400", "chunk": "o be 5157  \nconfigured and enabled .  5158  \nClarification:  This requirement is intended to ensure that a dataflow cannot be activated 5159  \non a CDS unless all  the required filters and their dependencies are installed. For 5160  \nexample, a CDS implementing a n XML dataflow with a transformation capability 5161  \nwould require the following to be installed prior to allowing the XML dataflow to be 5162  \nactivated: two XML filters tha t implement schema validation, an XSLT filter to 5163  \ntransform the XML, and either a second XSLT filter  or another filter that could verify 5164  \nthe a ctions of the first XSLT filter . This is related to the ability selectively install 5165  \nfeatures (e.g., different filte rs) on a CDS  based on what a customer purc hased.   5166  \nT&W:  WRTB -00052 , CAPEC -554 5167  \nSIHCR -8 [~*/HB] CDS developer s shall comply with the NSA/NCDSMO \u201c Versioning and 5168  \nPatching Requirements  for Cross Domain Solutions (CDS)\u201d  (NCDSMO Doc ID : 5169  \nNCDSMO -R-00002 -003_00) for operating system patching and CDS versioning, 5170  \npatching and testing.  5171  \nT&W:  CWE -353, CWE -347, CWE -345, CAPEC -186 5172  \nSIHCR -8.1 [~*/HB] A CDS developer may choose to install patches and software updates for a 5173  \nCDS through a reinstall of the CDS. If thi", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}402{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "401", "chunk": "s is done, then the following apply:  5174  \nSIHCR -8.1.1 SIHCR -3 shall apply  for the creation of the install image at the developer\u2019s site.  5175  \nSIHCR -8.1.2 Excluding basic network configuration information related to the management 5176  \ninterface , the CDS configuration must be restored via (semi -)automated repeatable means 5177  \ntypically via a download from a CDS management server or  a restore  of a configuration 5178  \nbackup  from external media.  5179  \nSIHCR -8.1.3 Excluding basic network configuration information related to the management 5180  \ninterface, if the CDS configuration information must be reentered by hand after the 5181  \nreinstall then the reinstall process shall not be used to patch the CDS.  5182  \nSIHCR -9 [~*/HB, ~* /CCOTS]  CDS that implement the backup and restore functions  shall use 5183  \ndigitally sign ed backups . 5184  \nT&W:  CWE -345, CWE -502, CWE -642, CAPEC -165, CAPEC -176, CAPEC -586 5185  \nSIHCR -10 [~*/HB, ~*/CCOTS] CDS that implement the backup and restore  functions  shall 5186UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 193 of 397 verify the integri", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}403{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "402", "chunk": "ty of the back up prior to restoration.  5187  \nT&W:  CWE -345, CWE -502, CWE -642, CAPEC -165, CAPEC -176 5188  \nSIHCR -11 [~*/HB] The CDS shall use a password policy compliant with  the IA-5 security 5189  \ncontrol and the specified control enhancements in CNSSI 1253, Appendix F, Attachment 5190  \n3 (1 February 2023 ) to protect access to the operating system bootloader ( e.g., grub) 5191  \nconfi guration and alternate boot option s.  5192  \nT&W:  CWE -287, CWE -521, CAPEC -49 5193  \nSIHCR -12 [~*/HB] The CDS  should  use RAID levels ( e.g., RAID 1,5 ,6 , 10) that ensure 5194  \nprotection against disk failure and data loss for all CDS functions , including the operating 5195  \nsystem, CDS software , CDS configuration, and logs.  CDS that claim to be Enterprise 5196  \nCDS and lack redundant storage may be prohibited from being used by Enterprise Cross 5197  \nDomain Service Providers in the future.  5198  \nSIHCR -13 [~*/HB] The CDS should  monitor storage  media and RAID failure and error status 5199  \nand report any imminent failures or actual failures via the JAL subsystem.  5200  \nT&W : WRTB -00053, TRTB -00033, TRTB -00038  5201  \nSIHCR -14 [~*/HB] CDS developers shall  implement the NCDSMO specification Cross Domain 5202  \nSolution (CDS) Configuration & Compliance Report (C3", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}404{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "403", "chunk": "R) Specification183, v1.2 or 5203  \nhigher,  and provide a mechanism to transfer the C3R information off the CDS using USB 5204  \nmedia , DVD -R/CD-R or via the CDS management network to support Command Cyber 5205  \nReadiness Inspection (CCRI) , the Site Based Security Assessment (SBSA) processes , and 5206  \nbackup/recovery of the system .   5207  \nT&W:  CWE -223, WRTB -00022, WRTB -00042, WRTB -00055, TRTB -00040  5208  \nSIHCR -14.1 Enterprise class CDS shall have the ability to transfer (e.g., GRMP, HTTPS POST) 5209  \nthe C3R via the CDS\u2019s management network interface.  5210  \nSIHCR -15 [~*/HB] CDS that use h ardware that has been qualified by the operating system 5211  \nvendor\u2019s certification test suite  and use of that hardware  does not requi re additional  5212  \nsoftware  (e.g., kernel drivers) to be installed  may be used even if it was not part of the 5213  \noriginal LBSA h ardware test suite. This requ irement is subject to all other hardware 5214  \nlockdown ( e.g., secure  boot, UEFI\u00ae  lockdown) and measurement (e.g., SIR-3) 5215  \nrequirements in this document.  5216  \nT&W: WRTB -00054, TRTB -00049  5217  \nSIHCR -16 [~*/HB] CDS operated in an Enterprise environment or Tactical CDS being 5218  \nprovisioned at a factory/depot may use Dynamic Host Configuration Protocol", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}405{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "404", "chunk": " (DHCP)184 5219  \n \n183 This document is located on the NCDSMO Intelink -U site.  \n184 https:// tools.ietf.org/html/rfc2131UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 194 of 397 to acquire its management interface IP, netmask, de fault router, and Guard Remote 5220  \nManagement Protocol (GRMP)  Remote Controller configuration.  5221  \nT&W: CWE -15, CAPEC -176 5222  \nSIHCR -17 [TCDS]  CDS installed via dongles or disk cloning may get their core network 5223  \nconfiguration (IP/Ethernet Port mapping, netmask, default routers/gateways, and PKI 5224  \ncertificate s) via a digitally  signed XML based configuration file without having to 5225  \nimplement RBAC.  5226  \nClarification:  This requirement is specifically intended for Tactical CDS that are used in 5227  \nweapon systems and sensors where the software and dataflow configuration are  5228  \nidentical but the networking and related configuration details (e.g. , PKI Certificates) 5229  \nare different for each instance.  5230  \nT&W:  CWE -347, CAPEC -176, CAPEC -194 5231  \nSIHCR -17.1 [TCDS]  The digital certificate used to sign the XML configuration file", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}406{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "405", "chunk": " must be 5232  \nconfigured in the CDS software that is loaded on to the CDS during provision ing (usually 5233  \na factory or depot) . 5234  \nT&W: CWE -15, CWE -347, CAPEC -151, CAPEC -176, CAPEC -194 5235  \nSIHCR -17.2  [TCDS]  The CDS must validate  the XML configuration file against its schema , 5236  \nverify its integrity , and verify it is signed by an authorized  entity (e.g., a certificate loaded 5237  \non the CDS) prior to acting on its contents.   5238  \nT&W:  CWE -345, CWE -347, CWE -1286, CAPEC -176, CAPEC -475, TRTB -00037 , 5239  \nTRTB -00040  5240  \nSIHCR -17.3  [TCDS]  The certificate used to the sign the configuration shall  be from the CDS 5241  \nDeveloper or Customer.  5242  \nT&W:  CWE -347, CWE -668, CA PEC-151, CAPEC -176, CAPEC -194, TRTB -00037  5243  \nSIHCR -17.4  [TCDS]  The XML configuration file should contain  the Ethernet Media Access 5244  \nControl addresses for each of the device\u2019s interfaces that are being  configured and the 5245  \nCDS should verify they are correct for the specific device before apply ing the 5246  \nconfigur ation . 5247  \nClarification:  This is to ensure that the CDS is using the correct configuration file  for the 5248  \ndevice.  5249  \nSIHCR -18 [~*/HB]  The CDS operating in enterprise environments should use th e GRMP for 525", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}407{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "406", "chunk": "0  \nremote management , configuration , and software patching.  5251  \nT&W:  CWE -347, CWE -354, CWE -1125, CAPEC -151, CAPEC -176, CAPEC -194, 5252  \nCAPEC -234 5253  \nSIHCR -19 Patching a CDS from removable media via booting off that media shall comply with 5254  \nthe RBACR requirement s for patching systems.  5255UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 195 of 397 SIHCR -20 [~*/HB] For Linux based CDS, CDS software shall not be installed in operating 5256  \nsystem specific directories as described in The Linux Foundation\u2019s Linux Standard Base 5257  \n(LSB)185 5.0 Core Specification186 and Filesystem Hierarchy Standard (FHS) 3.0 5258  \nSpecification187. 5259  \nRationale:  This prevents t he CDS software from being overwritten or modified during 5260  \noperating system  updates and patching.  5261  \nSIHCR -20.1 [~*/HB] In accordance  with the  Filesystem Hierarchy Standard 3.0 Specification , 5262  \nCDS software shall be ins talled in  either /opt  or  /usr/local . 5263  \nSIHCR -21 [~*/HB] After the completion of the CDS software installation and reboot the system 5264  \nshall be its in normal operati", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}408{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "407", "chunk": "onal locked down state.  5265  \nClarification: This means the all the normal RTB requirements for securing the CDS are 5266  \nenabled.  5267  \n 5268  \n10.8 Process Isolation  Requirements  (PIR)  5269  \nThe primary goal of the process isolation requirements is  to reduce or eliminate a compromised 5270  \nprocess being used to move laterally though the CDS  or exfiltrat e configuration files or binaries 5271  \noff the CDS  by enforcing:  5272  \n\u2022 Isolation,  5273  \n\u2022 Restricted File Sy stem/Process Visibility, and  5274  \n\u2022 Immutability.  5275  \nPIR-1 [~*/HB] Each CDS subsystem shall use a unique operating system user as the owner of 5276  \nthe subsystems\u2019  process(es) so that DAC and MAC enforcement can be used to  enforce 5277  \nflow control, process containment /isolation , and least privilege . If the CDS subsystem 5278  \noperates in multiple domains/levels/categories on the CDS, then each instance of the 5279  \nsubsystem will have a unique operating system user.188 5280  \nClarification:  In an Access CDS (client) the virtual machine manager may run as the 5281  \nuser logged in so the unique user for multiple domains sub -requirements does not 5282  \napply.  Some  system startup  processes may run as the root  user (or preferably  as a 5283  \nuser wit h a subset of root  privi", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}409{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "408", "chunk": "leges  via Linux Capabilities ) for system startup and 5284  \n \n185 https://refspecs.linuxfoundation.org/lsb.shtml  \n186 https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB -Core -generic/LSB -Core -generic/book1.html  \n187 https://refspecs.linuxbase.org/fhs  \n188 Even though most CCOTS systems will not use MAC, if there exists the ability to control which users can invoke \nspecific processes, then unique operating system users must be used for each subsystems\u2019 processes.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 196 of 397 system monitoring  and control  (e.g., system monitor/control process needs to kill 5285  \nanother  user\u2019s processes) . However, the core CDS subsystems like JAL subsystem, 5286  \nGUIs, pipeline  processes (e.g., protocol adapter, filters ) shall  never run as  the root  5287  \nuser. Ideally 196ystem  should be used to start as many processes as possible  to avoid 5288  \nrunning processes as root . 5289  \nT&W:  CWE -223, CWE -284, CWE -668, CAPEC -122, CAPEC -180, TRTB -00037  5290  \nPIR-2 [~*/HB] CDS Filters and Protocol Adapter s shall use unique operating system users f or 5291  \ne", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}410{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "409", "chunk": "ach unique instantiation of  this class of components. For example , a filter pipeline in a 5292  \nthree domain guard that contain s three unique filters shall have a total of nine unique 5293  \noperating system users.  5294  \nT&W:  CWE -284, CWE -668, CAPEC -122, CAPEC -180, CAPEC -216 5295  \nPIR-3 [~*/HB] CDS Filters and Protocol Adapters shall not share configuration files between 5296  \ninstances (i.e. , users) or betwe en domains.  5297  \nT&W:  CWE -200, CWE -284, CWE -668, CAPEC -497, CAPEC -122, CAPEC -180, 5298  \nCAPEC -116 5299  \nPIR-4 [~*/HB] The only CDS processes that shall be able to create, edit, or delete configuration 5300  \nfiles or binaries/libraries/ package files shall be th e processes responsible for configuring 5301  \nthe system and dataflow  policy and this shall be enforced with MAC and DAC policy.  5302  \nT&W:  CWE -223, CWE -284, CWE -668, CAPEC -122, CAPEC -180 5303  \nPIR-5 [~*/HB] CDS subsystems shall only be  able to read those configuration files , binaries , 5304  \nlibraries, and support files  that are necessary for the CDS subsystem operation . This shall 5305  \nbe enforce d with MAC and DAC policy.  CDS subsystems ( e.g., integrity monitors) 5306  \nwhose purpose is to read other files are exempt from this requirement.  5307  \nClarification:  Thi", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}411{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "410", "chunk": "s generally does not apply to normal OS configuration files (e.g., 5308  \n/etc/hosts, /etc/passwd) that must be read by processes operating on the OS.  5309  \nT&W:  CWE -284, CWE -668, CAPEC -122, CAPEC -180 5310  \nPIR-6 [~*/HB] CDS subsystem s shall  be able to writ e (i.e., send) data (but not read or delete 5311  \ndata) to the CDS audit and logging system(s) . The CDS audit management subsystem , 5312  \nincluding system administration applications required to view and manage audit and logs , 5313  \nare exempt  from this requirement . 5314  \nT&W:  CWE -668, CWE -284, CAPEC -93, CAPEC -116, CAPEC -180 5315  \nPIR-7 [~*/HB] The CDS shall not use  multi -level  ranged processes189 for processing content or 5316  \nfor protocol adapters .  5317  \n \n189 Essentially this means running a single pr ocess at multiple levels concurrently.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 197 of 397 Clarifica tion:  Multi -level databases that integrate with  operating system  MAC enforcing 5318  \nmulti -level labeling in the database are exempt from this requirement.  Multi -level 5319  \nprocess refers to a process runni", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}412{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "411", "chunk": "ng at different security levels (e.g., U, S, TS). This 5320  \nusually applies to MAC systems that implement the Bell -LaPadula -Biba (BLB) 5321  \nmodel.  This would apply to systems running Multi -Category Security (MCS)  if a 5322  \nprocess with multiple categories is not using the categories to enforce a linear 5323  \npipeline.  5324  \nT&W:  CWE -668, CWE -669, CAPEC -554, CAPEC -216, CAPEC -180 5325  \nPIR-7.1 [~*/HB] The CDS should not use any multi -level  ranged  processes.  5326  \nClarification:  Instead of using multi -level ranged processes, the CDS should run each 5327  \ninstance of a process at a unique level.  Pipeline startup proce sses and Domain Routers 5328  \nare examples when ranged process may be used.   5329  \nT&W:  CWE -668, CAPEC -216, CAPEC -180 5330  \nPIR-8 [~*/HB] Dataflow processes shall be started and monitored by processes that are not part 5331  \nof the dataflow processing.  For example: the FOE shall  not start filters ; however , filters 5332  \nof the same type can  start ( e.g., spawn) filters of the same type.  It is acceptable for 5333  \nsystemd  on Linux\u00ae  systems to start and stop dataflow processes.    5334  \nT&W:  CWE -269, CWE -653, CAPEC -554, CAPEC -180 5335  \nPIR-9 [~*/HB] The users that CDS subsystems run as shall not own  or have write ac", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}413{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "412", "chunk": "cess to  the 5336  \nbinaries, libraries or configuration files  of those subsystems.  5337  \nRationale:  This prevents the subsystem process(es) from changing the DAC permissions 5338  \non the files so that it can write to them. System administration applications are 5339  \nallowed to write to their own configuration files but they may not own them.  5340  \nT&W:  CWE -269, CWE -653, CAPEC -180, CAPEC -176 5341  \nPIR-10 [~*/HB] Linux based CDS\u2019 that have  systemd  shall use systemd  to secure and 5342  \nsandbox CDS processes.  5343  \nPIR-10.1 [~*/HB] CDS processes shall be configured with PrivateTmp=yes  to secure access 5344  \nto the process\u2019 s temporary files by setting up a new file system namespace and mounting 5345  \n/tmp  and /var/tmp  directories inside it that are not shared by processes outside of the 5346  \nnamespace.  5347  \nT&W:  CWE -377, CWE -653, CAPEC -165, CAPEC -155 5348  \nPIR-10.2 [~*/HB] CDS processes that do  not need  network access shall be configured with 5349  \nPrivateNetwork=yes  so that a new network namespace shall be configured with only 5350  \nthe loopback  network inside it.  5351  \nT&W:  WRTB -00043 , CAPEC -234, CAPEC -554, TRTB -00002, TRTB -00034  5352  \nPIR-10.3 [~*/HB] CDS processes shall be configured with PrivateDevices=yes  so that 5353UNCLA", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}414{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "413", "chunk": "SSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 198 of 397 access to physical devices by the CDS processes is turned off.  5354  \nClarification:  Processes that need access to a specific device (e.g., like a GPU for video 5355  \nencoding) are exempt from this requirement.  5356  \nT&W:  WRTB -00045 , CAPEC -549, CAPEC -74, CAPEC -552 5357  \nPIR-10.4 [~*/HB] CDS processes shall be configured with NoNewPrivileges=yes  so that a 5358  \nCDS process and its children cannot escalate privileges.  5359  \nT&W:  CWE -269, CAPEC -233, TRTB -00044  5360  \nPIR-10.5 [~*/HB] CDS processes shall be conf igured with ProtectHome=yes  so that the 5361  \ndirectories /home , /root , and /run/user  are inaccessible to those processes.  5362  \nT&W:  CWE -653, CAPEC -176, CAPEC -122 5363  \nPIR-10.6 [~*/HB] CDS processes shall be configured with ProtectSystem=full  so that the 5364  \n/usr , /boot , /efi , and /etc  directories are read -only. 5365  \nT&W:   CWE -284, CAPEC -552, CAPEC -558, CAPEC -176 5366  \nPIR-10.7 [~*/HB] CDS processes shall be configured with ProtectKernelTunables=yes  to 5367  \nmake kernel variables accessible through", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}415{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "414", "chunk": " /proc/sys , /sys , /proc/sysrq -trigger , 5368  \n/proc/latency_stats , /proc/acpi , /proc/timer_stats , /proc/fs  and 5369  \n/proc/irq  read-only.  5370  \nT&W:  WRTB -00047, CAPEC -75, CAPEC -233 5371  \nPIR-10.8 [~*/HB] Where  possible, CDS processes shall be configured with 5372  \nMemoryDenyWriteExecute=yes  to deny memory mappings that are writable  and 5373  \nexecutable at the same  time, prevent memory from being changed to executable or 5374  \nmapping shared memory segments as executable . 5375  \nClarification : This does not apply programs that generate code dynamically at runtime 5376  \nlike Java\u00ae virtual machines.  5377  \nT&W : WRTB -00044 , CAPEC -549 5378  \nPIR-10.9 [~*/HB] CDS processes shall be configured with PrivateMounts=yes  so that any  5379  \nfile system mount points established or removed by a process will be private to the 5380  \nprocess.  5381  \nT&W:  CWE -284, CAPEC -176, TRTB -00045, CAPEC -558 5382  \nPIR-10.10 [~*/HB] CDS processes shall be configured with ProtectControlGro ups=yes  so 5383  \nthat the Linux Control Groups hierarchies accessible through / sys/fs/cgroup  are read - 5384  \nonly to those processes.  5385  \nT&W:  WRTB -00046, CAPEC -233, TRTB -00046  5386  \nPIR-10.11 [~*/HB] CDS processes shall be configured with 5387UNCLASSIFIED//FOR OFFICI A", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}416{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "415", "chunk": "L USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 199 of 397 SystemCallArchitecture s=native  to disable invocation of non -native syscalls . 5388  \nRationale:  Non-native binaries can potentially bypass SECCOMP protections since the 5389  \nsystem call numbering differs between architectures.  5390  \nT&W : WRTB -00078  , CAPEC -554 5391  \nPIR-10.12 [~*/HB] CDS shall not use Type=notify  in the service description for CDS 5392  \nprocess es. 5393  \nT&W:  CWE -1125 , CAPEC -153, CAPEC -234 5394  \n10.9 Role -Based Access Control (RBAC) Requirements  (RBACR)  5395  \nThis section describe s how RBAC  and Two Knowledge Person Control (TKPC)190 should be 5396  \nimplemented in a CDS. Specific CDS may vary from the specific roles and functions described 5397  \nin this section as long a s role separation and TKPC are achieve d. Developers are encouraged to 5398  \ndiscuss the design of their specific implementations with the NCDSMO . 5399  \nRBAC supports the Principle of Least Privilege by dividing responsibilities over system 5400  \nresources, files, and processes between distinct groups with limite d and related span of authority.  5401  \nRBAC a", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}417{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "416", "chunk": "llows authority to be granted to selected users in a modular way and tightens the 5402  \nconnection between privileged users and accountability for actions performed.  It also limits 5403  \nauthority in areas not related to assign ed responsibilities. TKPC protects against deliberate or 5404  \naccidental changes to the system that reduce its effectiveness or security.  By requiring every 5405  \nsecurity critical action to have a separate and disinterested reviewer, TKPC reduces the 5406  \nlikelihood of any system change reducing the effectiveness or security of the overall system.  5407  \nMany  operating system s lack the granularity to fully implement all functions of all roles directly 5408  \nso RBAC in many cases has be en implemented using a combination of a CDS appli cation and 5409  \nthe operating system. For example, if the CDS has a filter policy editor there would typically be 5410  \ntwo roles associated with it: policy  editor and policy  approve r. The operating system has no 5411  \nknowledge of CDS filter policies so there is not an op erating system level role to directly enforce  5412  \nthe policy editor and policy approver function s. However, you can use the operating system to 5413  \nenforce RBAC in the filter policy editor by using operating system  file manipul", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}418{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "417", "chunk": "ation  security 5414  \nmechanisms  (e.g., DAC and MAC) to  enforce the movement of a filter policy from  the policy 5415  \neditor working director y, to policy approve r working director y, and then to the  filters\u2019 5416  \nconfiguration directories.  5417  \nRBACR -1 [~*/HB] The CDS shall employ RBAC to enforce  role-based  separation within each 5418  \nCDS subsystem  (e.g., account management, filter policy management, audit, network 5419  \nadministration, etc.) . 5420  \n \n190 TKPC is sometimes called Two Knowledgeable Person Approval (TKPA) or Two Knowledgeable Person \nReview (TKPR).UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 200 of 397 T&W: CWE -266, CWE -268, CWE -708, WRTB -00072, CAPEC -180 5421  \nRBACR -2  [~*/HB] The CDS shall implement one of the following Two Knowledg eable Person 5422  \nControl191 approaches:  5423  \nRBACR -2.1 [~*/HB] Two different administrators  in different roles \u2013 one makes the change and 5424  \nthe other reviews and approves it.  5425  \nT&W: CWE -269, WRTB -00071, CAPEC -180 5426  \nRBACR -2.2 [~*/HB] Two different administrators  in different roles \u2013 one administrator  is", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}419{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "418", "chunk": " in 5427  \none (or more)  of the roles (described in RBAC -3) and the other  administrator  is an 5428  \napprover -only role. In this approach , administrators  in non-approver roles make changes 5429  \nto the system and a separate admin istrator  in a dedicated approv er-only role reviews and 5430  \napproves the changes.  5431  \nT&W: CWE -269, WRTB -00071, CAPEC -180 5432  \nRBACR -2.3 [~*/HB] Two different administrators in the same role approve changes made by 5433  \nother members of the same role.  5434  \nT&W: CWE -269, WRTB -00071, CAPEC -180 5435  \nRBACR -2.3.1 [~*/HB] The administrators shall not be able to approve changes made by 5436  \nadministrators in  different  roles (e.g. , an administrator in role A will not be able to 5437  \napprov e changes by an administrator in role B) . 5438  \nT&W: CWE -269, WRTB -00071, CAPEC -180 5439  \nRBACR -2.3.2 [~*/HB] The CDS administration applications shall prevent users from approving 5440  \ntheir own changes  (e.g., user A cannot  approve user A\u2019s changes).  5441  \nT&W: CWE -269, WRTB -00071, CAPEC -180 5442  \nRBACR -3 [~*/HB] The CDS shall implement the following roles  and functions : 5443  \nRBACR -3.1 [~*/HB] System Ad ministrator  Role:  5444  \nRBACR -3.1.1 [~*/HB] Add, retire , or modify  Administrative  Users  5445  \nRBACR -3.", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}420{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "419", "chunk": "1.2 [~*/HB] Install operating system  patch clusters  and CDS  updates (e.g. , patches)  5446  \nClarification:  This does NOT include adding new software to the CDS.  5447  \nRBACR -3.1.3 [~*/HB] Configure system network and tuning p arameters  5448  \nRBACR -3.1.4 [~*/HB] Generate or install  CDS encryption certificates  for the purpose  of 5449  \nnetwork encryption  (e.g., for TLS connections)  5450  \n \n191 Knowledgeable is defined an administrator trained to operate the CDS for the function to which he/she is  \nassigned. Additional training may be required for Policy configuration roles since that may require understanding \nthe dataflow  details including the risks posed by allowing specific filter options to be used.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 201 of 397 RBACR -3.1.5 [~*/HB] Install certificates for verifying the authorization and integrity of 5451  \ndataflow  policies   5452  \nRBACR -3.1.6 [~*/HB] System Backup  5453  \nRBACR -3.1.7 [~*/HB] Initiation of the non-interactive update of the Configuration Integrity 5454  \nChecker  (CIC) database  5455  \nRBACR -3.1.8 [~*/HB] Initiation of th", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}421{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "420", "chunk": "e non-interactive update of the System  Integrity Checker  5456  \n(SIC) database  5457  \nRBACR -3.1.9 [~*/HB] Update the Security Content Automation Protocol  (SCAP)192 content  5458  \nRBACR -3.1.10 [~*/HB] Run the SCAP scanner  (if present)  5459  \nRBACR -3.1.11 [~*/HB] Selecting a previous CDS configuration state to which to revert.  (See 5460  \nSASR -11) 5461  \nRBACR -3.1.12 [~*/HB] Initiate  a request to wipe the CDS.  5462  \nRBACR -3.1.13 [~*/HB] Enable full disk encryption  for the CDS storage devices . 5463  \nRBACR -3.1.14 [~*/HB] Request disabling of full disk encryption of CDS storage  devices.  5464  \nRBACR -3.2  [~*/HB] Security Administrator  Role:  5465  \nRBACR -3.2.1 [~*/HB] Add or remove administrative users to /from  roles  5466  \nRBACR -3.2.2 [~*/HB] Enable  and disable dataflow s \u2013 but not add, delete, or modify dataflow s 5467  \nRBACR -3.2.3 [~*/HB] Add, retire , and modify non-administrative users of the CDS  5468  \nRBACR -3.2.4 [~*/HB] Initiation of the non-interactive update of the Configuration Integrity 5469  \nChecker  database  5470  \nRBACR -3.2.5 [~*/HB] Assign (but not create) an administrator\u2019s public key certificate used for 5471  \nremote management to the administrator\u2019s  operating  system  account  5472  \nRBACR -3.2.6 [~*/HB] Approve a request to wi", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}422{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "421", "chunk": "pe the CDS.  5473  \nRBACR -3.2.7 [DCCDS]  Approve additions, retirement, and modifications to RHR Reviewers in 5474  \nthe RHR  System (if implemented for the CDS) . 5475  \nRBACR -3.2.8 [~*/HB] Approve a request to disable full disk encryption of CDS storage 5476  \ndevices.  5477  \nRBACR -3.3 [~*/HB] Policy Administrator  Role:  5478  \nRBACR -3.3.1 [~*/HB] Add, delete , and modify dataflow s\u2013but not enable/ disable dataflow s 5479  \nRBACR -3.3.2 [~*/HB] Approv e reverting the  CDS to a previous CDS configuration state.  (See 5480  \n \n192 See https://scap.nist.govUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 202 of 397 SASR -11) 5481  \nRBACR -3.4 [~*/HB] Log Administrator  Role:  5482  \nRBACR -3.4.1 [~*/HB] Backup audit and log data 5483  \nRBACR -3.4.2 [~*/HB] Delete audit and log data, only if backed up or remotely transferred first. 5484  \nRBACR -3.4.3 [~*/HB] Adjust the logging  level  for the amount of de tail provided ( e.g., debug 5485  \nmode) \u2013 but not what  is logged.  5486  \nRBACR -3.4.4 [~*/HB] Adjust audit/log retention policy for how many records /logs  are stored ; 5487  \nfor how long  records/l", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}423{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "422", "chunk": "ogs are stored; and under what conditions  (e.g., % disk full, 5488  \ndate/time based)  records/ logs are rotated . 5489  \nRBACR -3.4.5 [DCCDS]  Create , retire,  or modify  (including resetting  passwords)  RHR 5490  \nReviewers in the RHR System (if implemented for the CDS).  5491  \nRBACR -4 [~*/HB] All admin istrative  roles may: 5492  \nRBACR -4.1 [~*/HB] Shutdown or reboot s ystem  5493  \nRBACR -4.2 [~*/HB] Start  and s top dataflow s193 when the dataflow  is enabled  5494  \nRBACR -4.3 [~*/HB] View  system and application  logs and audit data  5495  \nRBACR -4.4 [~*/HB] Reset passwords for other users in the same  role as the administrator  5496  \nRBACR -4.4.1  [~*/HB] RBACR -4.4 shall not be impleme nted if RBAC R-2.3 is implemented , 5497  \nunless TKPC is also implemented  and the  approve r must be an administrator in a 5498  \ndifferent role.  5499  \nT&W: CWE -269, WRTB -00071, CAPEC -180 5500  \nRBACR -5 [~*/HB] The CDS may implement additional  roles as needed based on its CDS Class 5501  \nand CDS model and design.  5502  \nRBACR -6 [~*/HB] The CDS developer may add or delete functions as needed based on its CDS 5503  \nClass and CDS model and design.  5504  \nRBACR -7  [~*/HB] The CDS shall implement TKPC on the following CDS administration 5505  \nfunctions:  5506  \nRBACR -7.", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}424{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "423", "chunk": "1 [~*/HB] Network Configuration/Reconfiguration in a multi -domain194 CDS  5507  \nT&W: CWE -200, CWE -653, CWE -668, WRTB -00071, CAPEC -176, CAPEC -180 5508  \n \n193 Enable/Activate and Disable/Deactivate are part of the process of authorizing/deauthorizing the use of the \ndataflow. Starting/Stopping a dataflow is equivalent to rebooting the system. If a dataflow is not enabled, then it \ncannot be started or stopped. Starting/Stopping a  dataflow does not fundamentally change the accreditation and \nauthorization of the CDS.  \n194 A multi -domain CDS is a CDS that supports more than two domains.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 203 of 397 RBACR -7.2 [~*/HB] Any changes to the CDS Dataflow /Filter Policy  5509  \nT&W: WRTB -00038, WRTB -00071, CAPEC -176, TRTB -00029  5510  \nRBACR -7.3 [~*/HB] Activation (Enable)/Deactivation (Disable) of a Dataflow  Policy  5511  \nT&W: WRTB -00071  , CAPEC -176, TRTB -00056, TRTB -00058  5512  \nRBACR -7.4 [~*/HB] Any changes configuration of the network for the domains  which  are 5513  \nauthorized to connect  to the CDS  5514  \nClarification:  Example  changes  ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}425{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "424", "chunk": "include changes to the domain name service (DNS) 5515  \nfully qualified domain name (if applicable), subnet, IP address of interface  (if moved 5516  \nto a different subnet) , associated network device,  DNS server (s) (if applicable), 5517  \nallowed endpoints that can connect (if applicable), default gateway/router (if moved 5518  \nto a different subnet) , network ports allowed inbound or outbound to/from the CDS, 5519  \nsecurity labels associated with the domain, or internal (to the CDS) r outing or 5520  \nnetwork identifiers that could cause an administrator to misinterpret what the domain 5521  \nis (e.g., changing internal CDS identifie r from SIPRnet to just Secret Network even 5522  \nthe network is actually SIPRnet) . 5523  \nT&W: CWE -200, CWE -668, WRTB -00071, CAPEC -176, CAPEC -180 5524  \nRBACR -7.5 [~*/HB] Deletion  of audit data  from the CDS  or changes to what is audited.   5525  \nClarification:  Enabling debug mode for the CDS audit system does not require TKPC if 5526  \nall security related audit ev ents are still audited.  5527  \nT&W: WRTB -00071  , CAPEC -268 5528  \nRBACR -7.6 [~*/HB] Any changes to log retention policy  5529  \nT&W: WRTB -00071  , CAPEC -268 5530  \nRBACR -7.7 [~*/HB] Creation or modification of  admin istrati ve user  accounts  including the 5531", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}426{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "425", "chunk": "  \nassignment of certif icates of administrative users to support multi -factor authentication 5532  \n(MFA) on the console of the CDS or for remote management  of the CDS . 5533  \nT&W: WRTB -00071  , CAPEC -176, TRTB -00057  5534  \nRBACR -7.7.1 [~*/HB] Password resets by an admin for accounts in the same  role do not require 5535  \nTKPC.  5536  \nRBACR -7.8 [~*/HB] Changes to digital  certificates involved in verification of dataflow s (e.g., 5537  \npublic keys used to verify Data Flow Configuration  files)  5538  \nT&W:  WRTB -00071, CAPEC -122, CAPEC -176, CAPEC -180, TRTB -00042  5539  \nRBACR -7.9 [~*/HB] Updates to the System and Configuration Integrity Checkers  configuration  5540  \nnot part of an automated operating s ystem or CDS patch installation  5541  \nT&W: CWE -829, WRTB -00038, WRTB -00071, CAPEC -17, CAPEC -176, CAPEC -180, 5542  \nCAPEC -523, CAPEC -558, CAPEC -562, CAPEC -75 5543UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 204 of 397 RBAC R-7.10 [~*/HB] Addition, modification, or removal  of software components . This 5544  \nrequirement does not apply to operating system or CDS  patches that", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}427{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "426", "chunk": " are digitally signed  5545  \nby the CDS developer and previous versions of the software are already installed on the 5546  \nCDS.  5547  \nClarification: This applies to protocol adapters, filters or other CDS or operating system 5548  \ncomponents.  5549  \nT&W: CWE -354, CWE -829, WRTB -00071, CAPEC -165, CAPEC -17, CAPEC -523, 5550  \nCAPEC -558 5551  \nRBACR -7.11 [~*/HB] Enable,  disable or changing of the configuration of  filter reports being 5552  \nsent to users (see GDFR -38) 5553  \nT&W: WRTB -00071  , CAPEC -176, TRTB -00059, TRTB -00060  5554  \nRBACR -7.12 [~*/HB] Restore from backup  5555  \nT&W: CWE -345, WRTB -00071, CAPEC -1, CAPEC -176, CAPEC -75 5556  \nRBACR -7.13 [~*/HB] Creation, Modification or Deletion of Virtual Machines. This primarily 5557  \napplies to  Access  CDS . 5558  \nClarification: Changing of a VM\u2019s performance parameters (e.g., memory, CPU Cores) 5559  \ndoes not require TKPC.  5560  \nRationale:  The creation, modification , or deletion of a VM is the equivalent of installing, 5561  \nmodifying, and deleting a computer on a network.  This is intended to reduce the 5562  \nlikelihood of VM not authorized for the system being installed. For example, a TS 5563  \nVM being installed on a Secret level Access CDS.  5564  \nT&W: CWE -829, WRTB -00071, CAPEC -176, C", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}428{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "427", "chunk": "APEC -234, CAPEC -523 5565  \nRBACR -7.14 [~*/HB] Assignment of Virtual Machines to a specific security domain and 5566  \nnetwork interface(s) . This primarily applies to Access CDS.  5567  \nT&W: CWE -668, WRTB -00071, CAPEC -176, CAPEC -180 5568  \nRBACR -7.15 [~*/HB] Allowlist ing of specific USB devices that are a llowed to be used and by 5569  \nwhich security d omains  (including Virtual Machines) . This primarily applies to Access 5570  \nCDS.  5571  \nT&W: CWE -668, CWE -732, CWE -829, WRTB -00071, WRTB -00073, CAPEC -17, 5572  \nCAPEC -175, CAPEC -176, TRTB -00024  5573  \nRBACR -7.16 [~*/HB] Reverting to a previous CDS configuration state.  (See SASR -11) 5574  \nT&W:  CWE -345, WRTB -00071, CAPEC -1, CAPEC -176, CAPEC -75 5575  \nRBACR -7.17 [~*/HB] Disabling of full disk encryption of CDS storage devices.  5576  \nRBACR -7.18 [~*/HB]  Wipe a disk  5577UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 205 of 397 RBACR -8 [~*/HB] Operating system users shall be constrained in accordance with their defined 5578  \nrole/function . 5579  \nT&W: CWE -269, CAPEC -180 5580  \nRBACR -9 [~*/HB] CDS  Administrators shall n", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}429{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "428", "chunk": "ot be given unconstrained root privileges . 5581  \nT&W: CWE -269, CAPEC -122, CAPEC -554 5582  \nRBACR -10 [~*/HB] CDS may have \u201c Break Glass\u201d Accounts (BGA) that are used for cr eation 5583  \nof the initial CDS administration  accounts . BGA  must meet the following requirements : 5584  \nRationale: BGAs are  critical to reliable and safe operation  of a CDS. They are also used 5585  \nto gain access to th e CDS system when an  unexpected event occur s that results in an 5586  \ninsufficient number of CDS administration accounts necessary for proper 5587  \nadministration of the CDS ( e.g., locked out, employees terminated, contract changed 5588  \nwith no administrator turnover). Additionally, t he use of TPM backed Trusted Boot 5589  \nwith encrypted drives would prevent side loading ( e.g., booting off DVD media) the 5590  \nsystem to reset passwords. Therefore,  there  must be a mechanism to gain access to  the 5591  \nsystem if all the CDS admin istrator s get locked out.  5592  \nClarification:  BGAs are equivalent to NIST 800 -53 Rev 5 AC-2(2) emergency accounts.  5593  \nT&W: CWE -645, WRTB -00070, CAPEC -2, TRTB -00033  5594  \nRBACR -10.1 [~*/HB] If the CDS has B GAs, there must be at least two  and no more than three  5595  \nBGA so that  TKPC can be implemented.  5596  \nT&W: WRTB", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}430{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "429", "chunk": " -00071, WRTB -00080, CAPEC -122, CAPEC -180 5597  \nRBACR -10.2 [~*/HB] BGA may be configured  to not expire.  5598  \nRBACR -10.3 [~*/HB] BGA shall be configured to comply with the system temporary lockout 5599  \ntime period but may be configured to prevent permanent lock out . 5600  \nT&W: CWE -307, CWE -645, CAPEC -16, CAPEC -2, CAPEC -49, CAPEC -565, CAPEC - 5601  \n600 5602  \nRBACR -10.4 [~*/HB] BGA shall not be allowed to reset other B GA account passwords. A 5603  \nBGA password  can only be changed by that BGA user.   5604  \nT&W:  CWE -268, CWE -269, CAPEC -122, CAPEC -180 5605  \nRBACR -11 [~*/HB] TKPC must be enforced by DAC and MAC.  TKPC implemented solely 5606  \nwithin the administrative applications is not sufficient.  5607  \nClarification: If a CDS management system is implementing the RBAC for the 5608  \nconfiguration of the CDS  then this requirement applies to the CDS management 5609  \nsystem  (server variant)  not the CDS. However, if the CDS also has local 5610  \nconfiguration capabilities then this requirement also applies  to the CDS.  5611  \nT&W: CWE -288, CAPEC -180 5612UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NAT", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}431{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "430", "chunk": "O, NOR, SAU, SWE, QAT  \nPage 206 of 397  5613  \nRBACR -12 [~*/HB] TKPC approvals and rejections of change actions shall be audited.  5614  \nT&W: CWE -778, TRTB -00037  5615  \n10.10  Encryption  and Digital Signature Requirements  (EDSR)  5616  \nEDSR -1 Encryption  used by the CDS to protect data -in-transit (DIT) or for data-at-rest (DAR)  5617  \nshall use Commercial National Security Algorithm s (CNSA).  5618  \nClarification: These are described in Commercial National Security Algorithm Suite and 5619  \nQuantum Computing FAQ , January 2016195. (See Appendix B \u2013 Encryption 5620  \nStandards)  and as updated in the Commercial National Security Algorithm Suite 2.0 , 5621  \nSeptember 2022196. DAR is sometimes called Full Disk Encryption  (FDE) . The 5622  \nprimary intent of DAR in this document is focused on preventing manipulation and/or 5623  \ntheft of the CDS software whil e the CDS is in transit between the CDS Developer and 5624  \nthe Customer.  DIT applies to all encrypted communications to/from the CDS.  5625  \nEDSR -1.1 The use of Commercial Solutions for Classified (CSfC) approved solutions fo r DIT 5626  \nand DAR  shall be used.  5627  \nRationale: The requirements for CSfC DAR is to reduce the risk of successful theft of 5628  \nthe CDS software if the CDS is lost (e.g., sto", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}432{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "431", "chunk": "len, loss in operational use, improperly 5629  \ndisposed of).  5630  \nEDSR -1.2 If the CDS Developer intends for the CDS to be considered unclassified while 5631  \npowered off then the CDS must use either an approved Type -1 encryption solution for the 5632  \nstorage media or an approved and registered implementation of the  CSfC  DAR  5633  \nCapability Package197. 5634  \nEDSR -2 Protocols  used to protect DIT shall use Transport Layer Security (TLS) version 1.2 (or 5635  \nhigher) , Datagram Transport Layer Security  (DTLS)  version 1. 2 (or higher)  or IPSEC . 5636  \nEDSR -2.1 The CDS may have the ability to use TLS  1.1 and below . 5637  \nRationale: Some legacy mission systems do not support TLS 1.2 and above    5638  \n \n195 https://apps.nsa.gov/iaarchive/library/ia -guidance/ia -solutions -for-classified/algorithm -guidance/ cnsa-suite -and-\nquantum -computing -faq.cfm  and https://apps.nsa.gov/iaarchive/library/ia -guidance/ia -solutions -for-\nclassified/algorithm -guidance/commercial -national -security -algorithm -suite-factsheet.cfm   and \nhttps://apps.nsa.gov/iaarchive/programs/iad -initiatives/cnsa -suite.cfm  \n196 https://media.defense.gov/2022/Sep/07/2003071834/ -1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF , \nhttps://media.defense.gov/2022/Sep/07/2003071836/ -1/-1/0/CSI_CNSA_2", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}433{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "432", "chunk": ".0_FAQ_.PDF , and \nhttps://www.nsa.gov/Press -Room/News -Highlights/Article/Article/3148990/nsa -releases -future -quantum -resistant -\nqr-algorithm -requirements -for-national -se/ \n197 https://www.nsa.gov/Resources/Commercial -Solutions -for-Classi fied-Program/Capability -Packages/#data -at-restUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 207 of 397 EDSR -2.2 The CDS shall  have the ability to enforce only the use of TLS 1. 2 and higher.  5639  \nEDSR -3 Protocols used to protect DIT shall comply with \u201cRFC6460 \u2013 Suite B Profile for 5640  \nTransport Layer Security (TLS) \u201d. 5641  \nEDSR -4 Protocols  used to protect DIT shall not use any version of Secure Sockets Layer (SSL) . 5642  \nEDSR -4.1 The CDS may allow use of SSL for interoperability with legacy systems,  but SSL 5643  \nmust be explicitly enabled and off by default.   5644  \nEDSR -5   The CDS shall employ encryption libraries and applications that are certifi ed to the 5645  \nNIST FIPS 140 -2 or 140 -3. This includes the use of cryptographic functions implemented 5646  \nin hardware ( e.g., ASIC, FPGA) . 5647  \nEDSR -5.1  CDS encryption capabilitie", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}434{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "433", "chunk": "s shall be configured to  operate in accordance with  NIST 5648  \nFIPS 140 -2 or 140 -3 configuration  policy under which the library was certified.  5649  \nEDSR -5.2  The CDS vendor must provide FIPS validation lab documentation that confirms the 5650  \ncertificati on status of the FIPS crypto graphic mechanism ( e.g., hardware or software) 5651  \nbeing  used.  5652  \nEDSR -6 CDS components implementing Digital Signing shall use the CNSA suite  of algorithms 5653  \nand techniques . 5654  \nEDSR -7 The minima l allowed SHA output  size (bits)  used by  the CDS  in cryptographic 5655  \nfunctions including to hash files  shall be  at least SHA -384. 5656  \nEDSR -8 [TCDS , ~TCDS/HB ] The CDS shall implement  and employ  full disk encryption  5657  \n(DAR) . 5658  \nClarification:  If a TCDS is implementing ADP -10 or similar approach then encrypted  5659  \nflash  memory in lieu of full disk encryption is allowed so long as the real-time 5660  \ndecryption (e.g., for booting the CPU) is handled by custom code in the FPG A and 5661  \nthe CPU run s entirely out of RAM . 5662  \nEDSR -9 [DCCDS ] The CDS shall implement and empl oy full disk encryption  (DAR) . 5663  \nEDSR -10 [TCDS, ~TCDS/HB, DCCDS ] The NIAP C ollaborative Protection Profile for Full 5664  \nDrive Encryption \u2013 Encryption Eng", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}435{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "434", "chunk": "ine Version 2.0  should be used for evaluating the 5665  \nCDS \u2019 full disk encryption mechanism.  5666  \nEDSR -11  [TCDS , ~TCDS/HB , DCCDS ] If the CDS will automatically  boot ( e.g., no human in 5667  \nthe loop during boot)  on system start/power -on or reboot, then a TPM  shall be used to 5668  \nstore the decryption keys for the DAR  solution.198 5669  \nEDSR -12  [TCDS, ~TCDS/HB, DCCDS ] If the CDS software has been loaded on the hardwar e 5670  \n \n198 Using the TPM to store the DAR decryption keys will only prevent decryption of the media (e.g., disks) that have \nbeen separated from the server.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 208 of 397 prior to shipment, then the CDS shall use split keys for encrypting the storage device  5671  \nduring transit  with one half of the key being a password and other half TPM -based.  5672  \nClarification: The disk encryption password should not be shipped with the CDS system 5673  \nand should be provided via different  transfer  mechanism  (e.g., encrypted email, 5674  \nclassified network email) . The use of a TPM -based key ensures that if the CDS 5675  \nsto", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}436{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "435", "chunk": "rage device  is modified in transit then the system cannot  be decrypted.  5676  \nEDSR -13 [TCDS, ~TCDS/HB, DCCDS ] During operation of the CDS , one of the following two 5677  \nstorage device (e.g., solid state disk (SSD) , hard drive, flash memory) encryption 5678  \npassword  policies shall be used : 5679  \nEDSR -13.1 [TCDS, ~TCDS/HB, DCCDS ] Human enters the storage device encryption  5680  \npassword during bo sot.  5681  \nRationale: This protects against unauthorized access to  the contents of  the CDS storage 5682  \ndevice  in the event o f theft of the storage device  or the system.  5683  \nEDSR -13.2 [TCDS, ~TCDS/HB, DCCDS ] Storage device  encryption password stored in the 5684  \nTPM .  5685  \nRationale: This protects against unauthorized access to  the content of  the CDS storage 5686  \ndevice  in the event of theft  of the storage device  but not theft of the system.  This 5687  \npassword approach is not sufficient to  protect the CDS software and config uration  5688  \nduring transit  to the installation site or in situations where loss of physical control of 5689  \nthe device is likely.  5690  \nEDSR -13.2.1 [TCDS, ~TCDS/HB, DCCDS ] The TPM shall be configured to use parameter 5691  \nencrypti on199. 5692  \nRationale:  This increases the cost and complexity of physical ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}437{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "436", "chunk": "access attacks that are 5693  \nattempting to gain access to the encrypted storage.  5694  \nEDSR -14  The CDS shall not generate PKI certificates for encrypted communications (e.g. , 5695  \nTLS) or users that expire in more than 36 months.  5696  \nEDSR -15 The CDS and CDS Management System (CMS) shall have the ability to enforce 5697  \nMulti -Factor Authentication (MFA) for network and physical access to the CDS and  5698  \nCMS for users (e.g., human).  5699  \nRationale:  Multi -factor authentication is now required per National Security 5700  \nMemorandum 8 Section 1(b)(iii).  5701  \nClarification:  This includes local physical access to the CDS (e.g., sitting at the console) 5702  \nand remote access to the CD S for the purposes of CDS administration; RHR 5703  \nsubmission, review, and approval; submission of content to the CDS for transfer; and 5704  \n \n199 https://dolosgroup.io/blog/2021/7/9/from -stolen -laptop -to-inside -the-company -networkUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 209 of 397 retrieval of content from the CDS.  MFA does not apply to RBACR -10 Break Glass 5705  \nAccounts. The CMS MF", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}438{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "437", "chunk": "A requirements apply  regar dless of how the CMS is 5706  \nconnected to the CDS.  This requirement does not, at this tim e, apply to  machine -2- 5707  \nmachine communications  with the CDS or CMS.  Test PIV cards available from 5708  \nNIST200 and the NCDSMO will sponsor CDS developer request s for test CAC and 5709  \nSIPRnet Tokens  (if available).  5710  \nEDSR -15.1 The CDS/CMS shall support the use of DOD NSS/ SIPRNet Token  authentication 5711  \nfor local and remote user MFA . 5712  \nEDSR -15.2 The CDS/CMS shall support certificate validation combined with a local (to CDS) 5713  \npassword for authentication of local and remote user login.  5714  \nEDSR -15.3 The CDS/CMS developer may also provide their own smartcard -based solution for 5715  \nlocal and remote user MFA.  5716  \nClarification:  A smartca rd will be classified at system high for the CDS  after 5717  \nprovisioning  for user. NSS/SIPRnet Tokens (if used ) will remain unclassified unless 5718  \nunlocked.  5719  \nEDSR -15.4 The CDS shall support MFA for remote user authentication for  content delivery to 5720  \nthe CDS.  5721  \nClarification: Content delivery includes both content being sent to the CDS for transfer 5722  \nthrough the device and for content sent to the devic e for the purposes of management 5723  \nor ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}439{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "438", "chunk": "operation of the CDS (e.g., patches, certificate revocation lists) . This requirement 5724  \ndoes not, at this time, apply to machine -2-machine communications with the CDS.  5725  \nEDSR -15.5 The CDS shall support MFA for remote user authentication for content retrieval 5726  \nfrom the CDS.   5727  \nClarification: This requirement does not, at this time, apply to machine -2-machine 5728  \ncommunications with the CDS.  5729  \nEDSR -16 The CDS shall have the ability to disable  full disk encryption and decrypt the CDS 5730  \nstorage device(s).  5731  \nClarification: The ability to decrypt the CDS storage device(s) is intended to support incident 5732  \nresponse and insider threat activities where the storage d evice (s) must be removed from 5733  \nthe CDS and imaged.  5734  \nEDSR -16.1 Disabling the full disk encryption and decryption will required TKPC.  5735  \nEDSR -17 The CDS shall have the ability to enable  full disk encryption and encrypt the CDS 5736  \nstorage  device(s).  5737  \n \n200 https://csrc.nist.gov/projects/piv/nist -piv-test-cardsUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 210 of 397  573", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}440{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "439", "chunk": "8  \n10.11  System Integrity Requirements  (SIR)  5739  \nThis section provides the req uirements for how the integrity of the system will be monitored and 5740  \nhow integrity violations will be detected.  5741  \nSIR-1 [~*/HB,  ~*/CCOTS ] CDS , which operate on systems with  Unified Extensible Firmware 5742  \nInterface ( UEFI\u00ae ) support, shall implement  the UEFI\u00ae  Secure Boot201 202 capability  to 5743  \nensure the integrity and authenticity of the bootloader  and operating system.  5744  \nT&W:  CWE -693, CWE -284, CAPEC -1, CAPEC -552 5745  \nSIR-1.1 [~*/HB, ~*/CCOTS ] CDS , implementing UEFI\u00ae  Secure Boot , shall implement it in 5746  \naccordance with the UEFI\u00ae  Specification, Version 2.7, May 2017203 or higher.  5747  \nSIR-1.2 [~*/HB, ~*/CCOTS ] CDS, using Intel\u00ae  x86-based CPUs, shall implement Intel\u00ae  Boot 5748  \nGuard204 protections . 5749  \nT&W:  CWE -1326, CAPEC -122, CAPEC -68 5750  \nSIR-1.3 [~*/HB, ~*/CCOTS ] CDS, operating on x86 CPU architecture, shall  remove  all keys in 5751  \nthe UEFI\u00ae  firmware  responsible for signing operating systems  and replace them  with 5752  \ntheir own certificate to prevent booting of o perating systems not provided by the CDS 5753  \nvendor.  Keys used to sign PCI-based UEFI\u00ae -compatible option ROMs205 for device 5754  \ndrivers do not hav", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}441{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "440", "chunk": "e to be removed.  5755  \nClarification :  Some hardware vendors are using Microsoft \u00ae to sign option ROM s 5756  \nbecause Microsoft \u2019s\u00ae keys are already in the UEFI\u00ae  firmware. This approach is 5757  \nstrongly discouraged and CDS developers are encouraged to use hardware vendors 5758  \nthat do not implement this unsound practice. Options ROMs for PCI devices (e.g., 5759  \nRAID adapters, NI Cs, GPUs) should be signed by their manufacturer (or hardware 5760  \nsystem vendor) and not by operating system developers . If a CDS developer has this 5761  \n \n201 A good explanation of Secure Boot can be found at https://docs.microsoft.com/en -us/previous -\nversions/windows/it -pro/windows -8.1-and-8/hh824987(v%3dwin.10)  and https://docs.microsoft.com/en -\nus/previous -versions/windows/hardware/design/dn653311(v=vs.85)   \n202 https://media.defense.gov/2020/Sep/15/2002497594/ -1/-1/0/CTR -UEFI -SECURE -BOOT -CUSTOMIZATION -\n20200915.PDF/CTR -UEFI -SECURE -BOOT -CUSTOMIZATION -20200915.PDF  and \nhttps://www.nsa.gov/Portals/70/documents/what -we-do/cybersecurity/professional -resources/csi -boot-security -\nmodes -and-recommendations.pdf   \n203 http://www.uefi.org/sites/default/files/resources/UEFI_Spec_2_7.pdf  \n204 https://www.intel.com/content/dam/www/central -libraries/us/en/documents/below", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}442{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "441", "chunk": " -the-os-security -white -\npaper.pdf  \n205 https://docs.microsoft.com/en -us/windows -hardware/manufacture/desktop/uefi -validation -option -rom-validation -\nguidance  and https://eclypsium.com/2020/07/29/theres -a-hole-in-the-boot/UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 211 of 397 situation and switching to a different hardware manufacturer is not possible , please 5762  \ncontact the NCDSMO for fur ther guidance.  5763  \nT&W:  CWE -668, CWE -693, WRTB -00095,  CAPEC -474, TRTB -00039  5764  \nSIR-1.4 [~*/HB, ~*/CCOTS ] CDS shall  not use the Microsoft \u00ae or hardware developer signed 5765  \nboot-loader shim and shall  instead use a boot-loader signed by the CDS developer.  5766  \nClarification:  The same boot -loader shim software can be use d but must  be signed by 5767  \nthe CDS developer\u2019s certificate.  5768  \nT&W:  CWE -668, CWE -693, WRTB -00095,  CAPEC -474, TRTB -00039   5769  \nSIR-2 [~*/HB, ~*/CCOTS ] The CDS should  implement a Trusted Boot206 207 capability to 5770  \nensure  the integrity of the operating system kernel.   5771  \nT&W:  CWE -693, CWE -284, CAPEC -1, CAPEC -552 5772  \nSIR-3 The ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}443{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "442", "chunk": "CDS developer shall verify , prior to delivery of the CDS , that all hardware  and 5773  \nfirmware  resources are patched , no known vulnerabilities exist208 209, and are on the latest 5774  \nsupported version. This includes  (but not limited to) : 5775  \n\u2022 CPU micro code  (e.g., to address problems like Spectre/Meltdown) , 5776  \n\u2022 Syste m BIOS and UEFI\u00ae  firmware210, 5777  \n\u2022 Chipsets,  5778  \n\u2022 Intel\u00ae  ME/AMT (if on Intel\u00ae  based systems) , 5779  \n\u2022 Baseboard Management Controller  (BMC) , and  5780  \n\u2022 Other system components ( e.g., RAID controllers, network interface controllers,  5781  \nGraphics Adapters , hard drives, SSD, and USB devices ). 5782  \nClarification: NSA\u2019s hardware and firmware security guidance is available at: 5783  \nhttps://github.com/nsacyber/ Hardware -and-Firmware -Security -Guidance  5784  \nT&W:  WRTB -00022  , CAPEC -233 5785  \n \n206 Another ex planation of Secure Boot and Trusted Boot can be found at https://docs.microsoft.com/en -\nus/windows -hardware/drivers/bringup/secure -boot \n207 https://sourceforge.net/projects/tboot  \n208 https://arstechnica.com/information -technology/2020/12/dangerous -uefi-malware -is-rare-a-botnet -called -\ntrickbot -may-change -that and https://www.welivesecurity.com/wp -content/uploads/2018/09/ESET -LoJax.pdf  \n209 http", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}444{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "443", "chunk": "s://securelist.com/mosaicregressor/98849  and https://eclypsium.com/2019/12/20/anatomy -of-a-firmware -\nattack  \n210 An open source tool called CHIPSEC, developed in part by Intel ( https://github.com/chipsec/chipsec ), can assist \nin assessing the security of the systems BIOS/UEFI Firmware and other components.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 212 of 397 SIR-3.1 The CDS developer shall be responsible for acquiring, testing, and distributing to 5786  \ncustomers quarterl y, at minimum,  updates for System BIOS, UEFI\u00ae  firmware, processor 5787  \nmicrocode, and other system components ( e.g., RAID controllers, network interface 5788  \ncontrollers, etc.).  5789  \nSIR-3.2  The CDS developer shall provide a mechanism (e.g., bootable DVD) to implement the 5790  \nSIR-3 requirements at a customer site upon receipt of the hardware and firmware at that 5791  \nsite and verify the hardware  and firmware  of the system  is in the identical state from 5792  \nwhen it left the vendor.  5793  \nT&W:  CWE -693, CAPEC -439 5794  \nSIR-3.2.1 For each CDS system delivered  to a customer , the CDS developer shall provi", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}445{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "444", "chunk": "de to the 5795  \nNCDSMO  the prior -to-ship scan results . The CDS developer  must retain  prior -to-ship 5796  \nscan results  for their records  and provide to the NCDSMO the prior -to-ship scan results  5797  \nfor each system shipped during the previous quarter.  5798  \nRationale:  This information will be used by Incident Response Teams  (IRT)  in the event 5799  \nof a CDS being compromised.  5800  \nSIR-3.3 [~*/HB, ~*/CCOTS ] The CDS developer shall  provide a mechanism  to assess the 5801  \ncurrent state of the CDS to determine if the hardware is in the current authorized state and 5802  \nthat there are no known vulnerabilities in the hardware subsystem. This includes the 5803  \nability to update the CDS periodically with  hardware and firmware assessment definition 5804  \nfiles that can be use d to verify the  current  security state of the hardware ( e.g., this is 5805  \nsimilar to how an antivirus  scanner is updated for virus definition files  or SCAP OVAL 5806  \nfiles for the operating system ). 5807  \nT&W:  CWE -284, CWE -668, CWE -1248, WRTB -00022, CAPEC -124, CAPEC -441, 5808  \nCAPEC -624, TRTB -00041  5809  \nSIR-3.3.1 The hardware and firmware assessment mechanism shall  be able to be scheduled to 5810  \nrun and must run at minimum once every 24 hours.  5811  \nT&W: ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}446{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "445", "chunk": " WRTB -00040, TRTB -00040  5812  \nSIR-3.3.2 The hardware and firmware assessment mechanism shall be able to be manually run 5813  \nfrom the system administration application.  5814  \nSIR-3.3.3 The hardware and firmware assessment mechanism shall run on boot  but can run 5815  \nasynchronously during the boot process.  5816  \nT&W:  WRTB -00040  , TRTB -00040  5817  \nSIR-3.3.4 When  the hardware and firmware assessment detects an anomaly the n the  CDS shall  5818  \ntransition into an offline/maintenance mode state with all n etwork interfaces disabled.  5819  \nT&W:  CWE -636, WRTB -00041, CAPEC -554 5820  \nSIR-3.3.5 The CDS shall generate a new hardware and firmware configuration baseline after 5821UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 213 of 397 authorized  hardware and firmware changes ( e.g., addition/removal of a NIC, replacement 5822  \nof a RAID controller, installation of a firmware update) . 5823  \nT&W:  CWE -645, CAPEC -2 5824  \nSIR-3.4 The CDS developer shall use a commercial ly supported hardware  and firmware  state 5825  \nverification mechanism  that tracks know n vulnerabilities in hardw", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}447{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "446", "chunk": "are systems . 5826  \nT&W:  CWE -284, CWE -668, CWE -1248, WRTB -00022, WRTB -00042, CAPEC -124, 5827  \nCAPEC -441, CAPEC -624, TRTB -00041  5828  \nSIR-4  [~*/HB] The CDS developer shall implement the recommendations in NIST SP 800 -147: 5829  \nBIOS Prot ection Guideline s211, NIST -SP 800 -193: Platform Firmware Resiliency 5830  \nGuidelines , and NIST SP 800 -147B: BIOS Protection Guidelines for Servers212.  5831  \nT&W:  CWE -693, CAPEC -552 5832  \nSIR-5 [~*/HB] The CDS shall not operate in BIOS Emulation Mode.  5833  \nT&W : CWE -284, CAPEC -552 5834  \nSIR-6  [~*/CCOTS] If the CDS is operating on an ARM \u00ae CPU architecture -based system , then 5835  \nit must use a 64 -bit ARM\u00ae  with TrustZone support.  5836  \nT&W:  CWE -269, CWE -250, CWE -284, CWE -922, CAPEC -1, CAPEC -234, CAPEC -37 5837  \nSIR-7 [~*/HB, ~*/CCO TS] If the CDS is operating on x 86 CPU architecture -based hardware 5838  \n(either Intel\u00ae  or AMD\u00ae ), then it shall include a Trusted Platform Module v2.0 or higher.  5839  \nT&W:  CWE -20, CWE -1282, CWE -1283, CWE -1326, CAPEC -1, CAPEC -153, CAPEC - 5840  \n180 5841  \nSIR-7.1 [~*/HB, ~*/CCOTS ] The CDS shall comply with NSA \u201c Advisory 5842  \nMemorandum \u2028Deployment of Trusted Platform Modules (TPMs) as Cryptographic 5843  \nComponents in National Security Systems \u201d213, 11", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}448{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "447", "chunk": " April 2017, when leveraging a TPM as 5844  \npart of a trusted boot solution.  5845  \nSIR-7.2 [~*/HB, ~*/CCOTS] TPMs embedded in commodity CPUs shall not be used . A 5846  \nseparate independent TPM chip shall be used.  5847  \n \n211 http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800 -147.pdf , NIST -SP 800 -193: Platform \nFirmware Resiliency Guidelines should be reviewed ( https://csrc.nist.gov/publications/detail/sp/800 -\n193/final ) \n212 https://dx.doi.org/10.6028/NIST.SP.800 -147B  \n213 Available at \nhttps://intelshare.intelink.gov/sites/ncdsmo/Shared%20Documents/Forms/AllItems.aspx?RootFolder=%2Fsites%2F\nncdsmo%2FShared%20Documents%2FPoliciesUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 214 of 397 Rationale:  Commodity CPU s have a poor security reco rd regarding their TPMs.214 5848  \nT&W:  CWE -269, CWE -693, CAPEC -1, CAPEC -180 5849  \nSIR-8 [~*/HB,  ~*/CCOTS ] The CDS  should  generate  a remote attestation report of system 5850  \nintegrity and send the report to a n attestation server215, operating on the management out - 5851  \nof-band network, upon  completion of the operating sy", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}449{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "448", "chunk": "stem boot sequence.  5852  \nSIR-9 [~*/HB,  ~*/CCOTS ] The Trusted Computing Group\u2019s Trusted Network Connection 5853  \n(TNC) should be used if remote attestation is implemented.  5854  \nSIR-10 [~*/HB,  ~*/CCOTS ] The CDS shall have at least two file system  integrity checkers216 to 5855  \nmonitor the system : System I ntegrity Checker and Configuration Integrity Checker.  5856  \nRationale:  The intent of two integrity checkers is to minimize downtime  due to integrity 5857  \ndatabase rebuilds. The SIC is checking files that change infrequently (e.g., patching a 5858  \nsystem) while the CIC is checking files that are changing frequently (e.g., multiple 5859  \ntimes a day ). 5860  \nT&W:  WRTB -00048, CAPEC -74, TRTB -00047  5861  \nSIR-10.1 [~*/HB, ~*/CCOTS ] The CDS System Integrity Checker (SIC) shall be used to 5862  \nmonitor binaries ( e.g., executables  and libraries ), non -dataflow  configuration files, and 5863  \nother system components that are rarely changed.  5864  \nT&W:  WRTB -00041, CWE -732, CAPEC -75, CAPEC -165, CAPEC -184 5865  \nSIR-10.1.1 [~*/HB, ~*/CCOTS ] The CDS MAC policy shall prevent the  system  integrity 5866  \nchecker\u2019s configuration file from being modified when the CDS is in an operational (non - 5867  \nmaintenance mode) state . 5868  \nT&W:  CWE -284, CAP", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}450{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "449", "chunk": "EC -176 5869  \nSIR-10.2 [~*/HB, ~*/CCOTS ] The CDS Configuration Integrity Checker (CIC) shall be used to 5870  \nmonitor configuration files, filter policies, and other components of the system that are 5871  \nroutinely changed by administrators.  5872  \nT&W:  WRTB -00041, CWE -732, CAPEC -165, CAPEC -176 5873  \nSIR-10.2.1 [~*/HB, ~*/CCOTS ] The CDS MAC policy shall allow the  configuration  integrity 5874  \nchecker\u2019s configuration file to be modified by specifi c roles , using a specific application , 5875  \nwhile the system is either operational or , preferably, while the system is in a dedicated 5876  \n \n214 https://arstechnica.com/information -technology/2020/03/5 -years -of-intel-cpus-and-chipsets -have-a-concerning -\nflaw-thats -unfixable  and https://arstechnica.com/gadgets/2021/11/intel -releases -patch -for-high-severity -bug-that-\nexposes -a-cpus-master -key \n215 The remote attestation server does not need to be provided by the CDS vendor.  \n216 Open source exam ples include Monit ( https://mmonit.com/monit ), Samhain ( https://www.la -\nsamhna.de/samhain ), and Aide ( http://aide.sourceforge.net )UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}451{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "450", "chunk": "ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 215 of 397 maintenance mode . 5877  \nT&W:  CWE -284, CAPEC -176 5878  \nSIR-10.3 [~*/HB, ~*/CCOTS ] The execution interval for the SIC and CIC  shall be configurable  5879  \nto run at least every  24 hours . 5880  \nT&W:  WRTB -00040, CWE -354, CAPEC -184, CAPEC -176 5881  \nSIR-10.4 [~*/HB, ~*/CCOTS ] The SIC and CIC shall validate the integrity of files using an 5882  \nallowed  hash algorithm.  5883  \nT&W:  CWE -1240, CAPEC -97 5884  \nSIR-10.5 [~*/HB, ~*/CCOTS ] The SIC and CIC  shall execute during the system boot process . 5885  \nT&W:  CWE -354, CAPEC -184, CAPEC -176 5886  \nSIR-10.6 [~*/HB, ~*/CCOTS ] The SIC and CIC  shall disable  the CDS dataflow (s) if either 5887  \nintegrity check  fails then transition to maintenance mode.  5888  \nClarification:   This applies to integrity violations, if the SIC/CIC fail to start, and if the 5889  \nSIC/CIC fail to successfully complete the integrity scan (e.g., process crash).  5890  \nT&W:  WRTB -00041, CAPEC -176, CAPEC -184 5891  \nSIR-10.7 [~*/HB,  ~*/CCOTS ] The CDS shall enter maintenance mode  if either the SIC or CIC 5892  \nfail during boot.   5893  \nClarification: This applies to integrity violations , if the SIC/CIC fail to start,  and if the 5894  \nSIC/CIC fail to successfully comple", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}452{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "451", "chunk": "te the integrity scan (e.g., process crash).  5895  \nT&W:  WRTB -00041, CAPEC -176, CAPEC -184 5896  \nSIR-10.8 [~*/HB, ~*/CCOTS ] When approving changes to the integrity checker database , the 5897  \nCDS shall use the list of changes  being displayed to the administrator for approval to 5898  \nupdate the integrity checker database  and shall not regenerate (via a system rescan) the 5899  \nintegrity checker database after the changes are approved.  5900  \nT&W:  CWE -345, CWE -354, CWE -367, CAPEC -29, CAPEC -165 5901  \nSIR-10.9 [~*/HB, ~*/CCOTS] The CDS shall be able to detect the addition of new files and 5902  \ndeletion of existing files to/from  the system in directories tha t are not expected to have 5903  \nfile system changes . This event would be considered an integrity violation.  5904  \nClarification:  Examples of directories that are not generally allowed to have file system 5905  \nchanges are  (but not limited to)  /etc, /usr/bin, /usr/lib, /bi n, 5906  \n/opt,  and /usr/local . Basically,  directories that contain configuration 5907  \ninformation or binaries. They would  only have file system changes  under very 5908  \nprescribed conditions like approved software installation and patching or 5909  \nconfiguration changes through the administration tools.  5910  \nT&W:  WRT", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}453{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "452", "chunk": "B -00041, CWE -732, CAPEC -165, CAPEC -184 5911UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 216 of 397 SIR-10.10 [~*/HB, ~*/CCOTS ] The SIC and CIC shall only be suspended for the duration  of 5912  \ntime necessary to apply the changes to the system  and rebuild of the integrity database.  5913  \nT&W: CWE -367, CWE -693, WRTB -00076, CAPEC -176, CAPEC -184, CAPEC -29, 5914  \nCAPEC -554 5915  \nSIR-10.10.1 [~*/HB, ~*/CCOTS] The CIC should rebuild the integrity database prior to 5916  \nsuspending and restarting the integrity checker.  5917  \nSIR-10.11 [~*/HB, ~*/CCOTS] The SIC sha ll only be disabled when the CDS is in maintenance 5918  \nmode  and only during activities that require to be disabled (e.g., installing system 5919  \nsoftware patches).  5920  \nT&W:  WRTB -00076, CWE -693, CWE -367, CAPEC -176, CAPEC -184, CAPEC -554, 5921  \nCAPEC -29 5922  \nSIR-11 [~*/HB,  ~*/CCOTS ] The CDS shall  implement  an application allowlist217/denylist  5923  \ncapability  beyond traditional MAC -based enforcement .  5924  \nRationale:  Application allowlist ing/denylisting  is an integrity check that is immediate on 5925", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}454{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "453", "chunk": "  \naccess while traditional integrity checkers (SIR -10) are run at much longer intervals 5926  \ndue to the CPU and disk impact on running. They complement each other.  5927  \nT&W:  WRTB -00020, WRTB -00094, CAPEC -17, CAPEC -640 5928  \nSIR-11.1  [~*/HB, ~*/CCOTS ] The CDS should implement a kernel -based application allowlist 5929  \nmechanism beyond traditional MAC -based enforcement.  5930  \nT&W:  WRTB -00020, WRTB -00094, CAPEC -17, CAPEC -640 5931  \nSIR-11.2 [~*/HB, ~*/CCOTS ] For Linux\u00ae systems, the fapolicyd218 framework219 or the 5932  \nLinux\u00ae Integrity Measurement Architecture  in Appraisal mode may be  used for 5933  \napplication allowlisting . 5934  \nT&W:  WRTB -00094,  CAPEC -17, CAPEC -640 5935  \nSIR-11.3 [~*/HB, ~*/CCOTS ] The allowlisting capability  mechanism shall use a hash to 5936  \ndetermine if a file is allowed. The sole u se of file size or date/timestamp or  other  non- 5937  \ncryptographic means to determine authenticity is not allowed.  5938  \nT&W:  CWE -347, CAPEC -17, CAPEC -441, CAPEC -475 5939  \n \n217 The document will use the term \u201callowlist\u201d to cover both allowlisting and denylisting.  \n218 https://access.redhat.com/documenta tion/en -\nus/red_hat_enterprise_linux/8/html/security_hardening/assembly_blocking -and-allowing -applications -using -\nfapolic", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}455{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "454", "chunk": "yd_security -hardening  and https://github.com/linux -application -whitelisting/fapolicyd  \n219 NCDSMO funded the development of an application to support creation and analysis of fapolicyd configurations. \nIt is available at https://github.com/ctc -oss/fapolicy -analyzerUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 217 of 397 SIR-11.4 [~*/HB, ~*/CCOTS] The allowlisting capability  shall be used to measure the integrity 5940  \nof binari es, libraries, and configuration files on access.  5941  \nT&W:  WRTB -00094, CAPEC -17 5942  \nSIR-11.5 [~*/HB]  The allowlisting capability shall restrict read access to only those files that a 5943  \nprocess needs.   5944  \nSIR-11.6 [~*/HB] An allowlisting capability shall not rely solely on a file path, file descriptor, 5945  \nor inode to determine if the correct application is being executed.  5946  \nT&W:  CWE -284, CWE -347, CWE -706, CAPEC -177, CAPEC -441, CAPEC -475, 5947  \nCAPEC -558, CAPEC -642 5948  \nSIR-12 [~*/HB,  ~*/CCOTS ] The CDS shall  implement a  packet filtering  Firewall . 5949  \nT&W:  WRTB -00029, CWE -1125, TRTB -00034  5950  \nSIR-13 [~*/HB, ~*/CCOTS ]", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}456{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "455", "chunk": " The CDS should implement a stateful packet filtering Firewall.  5951  \nT&W:  CWE -400, CWE -290, CAPEC -482, CAPEC -151 5952  \nSIR-14 [~*/HB,  ~*/CCOTS ] The CDS shall  implement process  monitoring  to detect  and log  5953  \nunauthorized process es. 5954  \nT&W:  CWE -15, CWE -119, CWE -200, CWE -223, CWE -405, CWE -642, CWE -778, 5955  \nWRTB -00012, CAPEC -100, CAPEC -123, CAPEC -203, CAPEC -216, TRTB -00014, 5956  \nTRTB -00025, TRTB -00037  5957  \nSIR-15 [~*/HB] CDS should implement an antivirus  scanning capability for the CDS 5958  \nfilesystems . 5959  \nRationale: This requirement is intended to detect malicious, non -dataflow related files, 5960  \nappearing in sensitive areas of the CDS not related to data flow processing.  5961  \nT&W:  CWE -668, CAPEC -442, CAPEC -17 5962  \nSIR-15.1 [~*/HB]  The CDS shall  scan the file system at a configurable interval with a maximum  5963  \nperiod between scans of every 6 hours. Dataflow file systems used for holding and 5964  \nprocessing data are exempt from this requirement since that data is scanned by the 5965  \nantivirus engi nes in  the filter pipeline.  5966  \nT&W:  WRTB -00040  , CAPEC -442 5967  \nSIR-15.2 [~*/HB]  If the file system antivirus  scanner detects a virus it shall notify the EM/ PE 5968  \nsystem which in turn initia", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}457{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "456", "chunk": "te s a shutdown of the CDS functionality, disable s all network 5969  \ninterfaces, and transition s into maintenance mode.   5970  \nRationale:  If the CDS detects malware outside of the filtering  related  filesystems then 5971  \nthat is  a potential  indication of compromise of the CDS.  5972  \nT&W:  CWE -755, CAPEC -17, CAPEC -442 5973UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 218 of 397 SIR-15.3 [~*/HB]  The antivirus  scanner  shall not be used to clean any malicious files.  5974  \nRationale:  Malicious files must be kept for incident response forensics . 5975  \nT&W:  WRTB -00049, TRTB -00037, TRTB -00048  5976  \nSIR-16 [~*/HB, ~*/CCOTS] The CDS shall implement a mechanism to detect and log the death 5977  \n(including process crashes) of all CDS and op erating system processes including 5978  \nprocess es that were intentionally killed by another CDS process.  5979  \nRationale: This is intended to support DCO of CDS and system performance and 5980  \nstability monitoring.  5981  \nSIR-17 [~*/HB, ~*/CCOTS] All operating system and CDS binaries, libraries, and configuraton 5982  \nfiles shall be set to im", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}458{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "457", "chunk": "mutable220. 5983  \nSIR-17.1 [~*/HB, ~*/CCOTS]  CDS administration and software installation and patching 5984  \napplicat ions shall only disable the immutable flag when  necessary to modify or delete  the 5985  \nfile. 5986  \nSIR-17.2 [~*/HB, ~*/CCOTS]  A dedicated application with the CAP_LINUX_IMMUTABLE  5987  \ncapability shall be to set the immutable flag on a file.  5988  \n10.12  Journaling, Auditing, and Logging (JAL) Subsystem  (JALS)  5989  \nRequirements  (JAL SR) 5990  \nThis section covers the requirements for the CDS Journaling, Auditing, and Logging (JAL) 5991  \nSubsystem.  The JAL subsystem is  intended to support the acquisition , processing , and remote 5992  \ntransfer  of the following types of data:  5993  \n\u2022 Audit Data  5994  \n\u2013 Application specific enumerated structured events (e.g., \u201cFilter Y Failed\u201d, \u201cBad 5995  \nMessage Count Exceeded\u201d, \u201cSyntax Error on Line X\u201d, \u201cProcess X kill due to 5996  \nSECOMP violation for SYSCALL fork \u201d) 5997  \n\u2013 Operating system level enumerated events (e.g., Solaris BSM/Linux Audit)  5998  \n\u2013 The Linux Auditing System and JALOP with JAF records are examples of source 5999  \nof audit data.  6000  \n\u2013 Linux journald via sd_journal _send()221 can potentially be considered 6001  \naudit data if the applications leverage the journald fields ve", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}459{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "458", "chunk": "rsus shoving the data 6002  \ninto a big string field. But its fields are quite limited. Journald cannot be used for 6003  \nCDS processes.  6004  \n \n220 https://man7.org/l inux/man -pages/man2/ioctl_iflags.2.html  \n221 https://www.freedesktop.org/software/systemd/man/sd_journal_print.html  and \nhttps://www.freedesktop.org/software/systemd/man/systemd.journal -fields.htmlUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 219 of 397 \u2013 Audit data can be extended wit h custom events and fields.  6005  \n\u2013 Audit data should be able to be easily converted to XML and JSON and validated 6006  \nwith a robust schema.  6007  \n\u2013 Audit data is preferred over the traditional Log Data described  below because of 6008  \nits ability to reliably and efficiently parse d.  6009  \n\u2022 Log Data  6010  \n\u2013 Log data has no format or is loosely formatted . Syslog is an example of loosely 6011  \nformatted data as there is no defined structure for the message part of syslog.  6012  \n\u2013 Log data can be not be easily converted to XML or JSON and validated with a 6013  \nrobust schemas.  6014  \n\u2013 Example, O/S Application Level Logs (e.g., syslog ,", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}460{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "459", "chunk": " files from /var/log/*)  6015  \n\u2013 Application Level Logs (e.g., backup logs, filter errors, app lication  stderr/stdout, 6016  \napplication  Java exceptions)  6017  \n\u2022 Journal Data  6018  \n\u2013 Raw and processed files/dat a sent through the CDS (e.g., images, Microsoft 6019  \nOffice files, XML files, USMTF messages)  6020  \nThe JAL subsystem consists of following components : 6021  \n1) Operating system audit and logging which typically consists of auditd , journald , 6022  \nsyslogd , and the contents of /var/log .  6023  \n2) CDS  JAL daemons  which consist of the Central Audit  and Logging Daemon  (CALD)  6024  \nand the  Central Journal Daemon (CJD) . The CDS JAL daemons are intended to  be 6025  \nseparate from the operating system audit and logging to protect the operating system 6026  \naudit and logs from potentially be manipulated by a compromised CDS process , support 6027  \nportability of the CDS JAL capabilities across operating  systems  versions , enable  6028  \nenhanced integration with the Event Management and Policy Enforcement subsystem, 6029  \nand provide a mechanism for extensibility that does not exist the operating system JAL 6030  \nsystem.  6031  \na. The CALD is the CDS application equivalent of the combined operating system 6032  \nauditd, journald , but syslogd  da", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}461{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "460", "chunk": "emons . However, the intent of the CALD 6033  \nsystem is for CDS applications to send highly structured audit events (usually in 6034  \nthe Journaling, Auditing, and Logging Protocol (JALoP) Audit Format (JAF) ) as 6035  \nopposed to unstructured stri ngs. The use of highly structured audit events 6036  \nsubstantially simplifies the development of robust analytics in a DCO of CDS 6037  \nOOB  and enables rules based policy enforcement in the Event Management and 6038  \nPolicy Enforcement subsystem. The use of  low latency mult iple writer/single 6039  \nreader IPCs like Messages Queues are the preferred IPC  for CALD.  The CALD 6040  \nsyntactically and semantically validates the data before dispatching to other parts 6041  \nof the JAL subsystem .  6042  \nb. The CJD is responsible receiving original, filtered, and failed content from the 6043UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 220 of 397 filter pipeline and sending to local storage and to the subsystem responsible for 6044  \nremote transfer of JAL data off the CDS.  6045  \nc. CDS are required to have a CALD and, if applicable, a CJD. A CJD is optiona", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}462{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "461", "chunk": "l 6046  \nfor a streaming CD S and required for file transfer CDS.   6047  \nd. CDS specific  applications (e.g., filters, protocol adapters) are prohibited from 6048  \nwrite JAL data to  auditd , journald , and syslogd . 6049  \n3) Event Management and Policy  Enforcement (EM/PE)  subsystem  processes structured 6050  \nlogs and system statistics from the operating system components and CDS applications 6051  \nand applies a configurable policy to the data to enforce system security policy.  6052  \na. Historically, CDS processes  enforce d policy  at the application level  (e.g., a filter 6053  \nwould sh utdown after X number bad messages per some unit of time) . That was 6054  \nnot scalable nor was it secure. If a process was compromised the CDS would lose 6055  \nthe ability to enforce some aspects of its security policy . Additionally by centrally 6056  \nmanaging security policy enforcement , it is easier add new policy enforcement 6057  \ncapabilities without having to  modify and thus retest the rest of the CDS 6058  \ncomponents . 6059  \n4) System statistics  gathering, processing,  and remote transfer using via Simple Network 6060  \nManagement  Protocol (SNMP) . This capability is primarily used system operators 6061  \nresponsible for operating CDS  systems  within an enterprise ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}463{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "462", "chunk": ". It provides enough 6062  \ninformation to tell operators if the CDS is operating nominally, degraded but still 6063  \nfunction ing, or no longer functioning as intended . It can also provide performance data to 6064  \nsupport load balancing and high availability  requirements.  6065  \n5) JAL remote transfer usually via the JALoP . This capability supports the following 6066  \nfunctions:  provides a mechanism for offloading JAL data from the CDS for archival and 6067  \noperations analysis purposes, provides  the JAL data necessary to support CDS operator 6068  \nand CDS user inside threat monitoring, and provide s the data necessary to support DCO 6069  \nof CDS monitoring.  JALoP and JAF were develop ed to address the following problems 6070  \nwith previous JAL remote transfer mechanisms:  6071  \na. No support for Journaled data  6072  \nb. No support for  extensible structured audit and log  data 6073  \nc. Severe message size constraints  6074  \nd. No industry standard data format for representing audit records  6075  \ne. Inappropriate handling (i.e., truncation of oversized messages \u2013 RFC 5424)  6076  \nf. Delivery of JAL dat a was not reliable or  guaranteed  6077  \ng. No restart/retransmit/resend ability  6078  \nh. Weak Security  (e.g., lack of TLS)  6079  \ni. Lack of support fo", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}464{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "463", "chunk": "r SCAP standard s 6080  \n6) Local JAL storage system . A local copy of the JAL data is necessary to support on -box 6081  \ntroubleshooting.  6082  \n 6083  \nThe below  drawing shows  the components of a typical JAL subsystem and how they interact.  6084UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 221 of 397  6085  \nFigure 40 \u2013 Example Journaling, Audit, and Logging Subsystem Architecture  6086  \n 6087  \nJALSR -1  [~*/HB, ~*/CCOTS ] The CDS shall enforce least privilege  and least functionality  by 6088  \nmoving system security enforcement actions from PA, FOE, and Filters processes to a 6089  \nsubsystem that does not process external data.  6090  \nT&W: CWE -250, CWE -653, CAPEC -69 6091  \nJALSR -2 [~*/HB, ~*/CCOTS ] The CDS sha ll implement security enforcement actions in a 6092  \ndedicated Event Manager/Policy Enforce r subsystem . 6093  \nRationale: A core function of the EM/PE is the ability to enforce security actions within 6094  \nthe CDS based on automated processing of the audit and log data by a dding new rules 6095  \nand DCO analytics without changing the CDS software. A n EM/PE should have a set 6", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}465{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "464", "chunk": "096  \nof \u201ccanned\u201d actions and provide access to all the data point s from the audit and log .  6097  \nT&W:  CWE -657, CWE -693, CAPEC -112, CAPEC -28, CAPEC -69 6098  \nJALSR -2.1  [~*/HB, ~*/CCOTS ] The EM/ PE subsystem should have  a programmatic rules 6099  \nlanguage that enables the ability to create custom rules . 6100  \nJALSR -2.2 [~*/HB, ~*/CCOTS ] The EM/PE shall have the ability to be configu red via a  non- 6101  \nprogrammatic  rules language (if JALSR -2.1 is not implemented).  6102  \nClarification : A non -programmatic rules language could be an XML or JSON file that 6103  \ndescribe s the specific thresholds and actions to perform for each event.  It would not 6104  \ncontain conditionals, variables, or looping constructs.  6105  \nJALSR -2.3 [~*/HB, ~*/CCOTS ] The EM/PE shall have the ability to enable /disable and 6106  \nstart/stop data flows;  enable/disable and start/stop security domain filter ing pipelines ; 6107  \nrestart P as, filters , modular pipeline components, and FOE processes; enable/disable 6108UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 222 of 397 communications  interfaces;  tr", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}466{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "465", "chunk": "ansition to maintenance mode;   and enable/disable and 6109  \nstart/stop remote managem ent and monitoring capabilities via the rules language.  6110  \nT&W:  CWE -636, CWE -693, CAPEC -554 6111  \nJALSR -2.4 [~*/HB, ~*/CCOTS ] The EM/PE should have the ability to force P as, filters , 6112  \nmodular pipeline components,  and FOE processes to reload configuration files via the 6113  \nrules language.   6114  \nClarification:  SASR -7.8 still applies in this case . 6115  \nJAL SR-2.5 [~*/HB, ~*/CCOTS ] The EM/PE shall have the ability to run analytics on filter 6116  \nreports and audit/log  messages including from modular pipeline components  to generate 6117  \nfailure statistics to take corrective action.  6118  \nJALSR -2.5.1 [~*/HB, ~*/CCOTS ] The EM/PE shall have the ability to stop and disable a data 6119  \nflow if a configurable number of failed  message s per a configurable unit of time is 6120  \nexceeded . 6121  \nRationale:  This is intended to help reduce the attack risk against both the CDS and the 6122  \ndestination environment.  6123  \nT&W:  CWE -799, CAPEC -112, CAPEC -28 6124  \nJALSR -2.5.2  [~*/HB, ~*/CCOTS ] The EM/PE shall have the ability to stop and disable a 6125  \nsecurity domain pipeline if a configurable number of data flows for that domain are 6126  \ndisabled wit", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}467{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "466", "chunk": "hin a configurable unit of time . 6127  \nT&W:  CWE -799, CAPEC -112, CAPEC -28 6128  \nJALSR -2.5.3  [~*/HB, ~*/CCOTS ] The EM/PE shall have the configurable ability to stop and 6129  \ndisable the origin and destination security domains of a linear assured  pipeline if a file 6130  \nfails filtering in the inbound  pipeline.   6131  \nClarification: For Fixed Format dataflows including XML where the data can be 6132  \nprecisely validated consistently and deterministically by different filter independent 6133  \nimplementations,  this configu rable parameter should be set to shut down the pipeline  6134  \nafter a small number of failures.  However, for dataflows (like those Microsoft 6135  \nOffice\u00ae  filters  or image  filters  with randomized changes ) where two independent 6136  \nimplementations might not result in the s ame exact same output then the parameter 6137  \ncan be configurable.  6138  \nT&W:  CWE -799, CAPEC -112, CAPEC -28 6139  \nJALSR -2.5.4  [~*/HB, ~*/CCOTS ] The EM/PE shall have the ability to create custom rules that 6140  \ncan stop and disable a security domain pipeline based on the results from filter reports  6141  \n(e.g., too many dirty words found per unit of time per data type, too many Microsoft 6142  \nOffice\u00ae  documents w ith tracked changes, too many JPEG fil", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}468{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "467", "chunk": "es with EXIF metadata, 6143  \netc.). 6144UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 223 of 397 T&W:  CWE -799, CAPEC -28, CAPEC -112 6145  \nJALSR -3 [~*/HB, ~*/CCOTS ] The EM/PE shall not have the ability to enable/disable or 6146  \nstart/stop CALD or other CDS or OS  audit/logging pr ocesses.  6147  \nT&W: CWE -250, CAPEC -268 6148  \nJALSR -4 [~*/HB,  ~*/CCOTS ] CDS functions shall  not use the operating system audit 6149  \nsubsystem for audit/logging data other than as part of the normal operating system 6150  \nauditing and logging of a process.  6151  \nClarification: This specifically means that CDS processes and subsystems shall not use 6152  \njournald , syslogd, or auditd  for audit/logging the CDS processes events.  6153  \nRationale:  Operating System audit subsystems have been shown in testing to be fragil e 6154  \nand can be manipulated to cause kernel panics. Additionally, operating system audit 6155  \nis not very extensible and cannot store the types and amount of information require d 6156  \nfor CDS auditing. Lastly, tying  CDS auditing to operating system audit locks the 6157  \nCDS to a speci", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}469{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "468", "chunk": "fic release of the operating system, which  makes future operating 6158  \nsystem upgrades complex and expensiv e. 6159  \nT&W:  CWE -1125, CWE -20, CWE -221, CAPEC -113, TRTB -00037  6160  \nJALSR -4.1 [~*/HB, ~*/CCOTS] On CDS using systemd  to manage processes, the systemd  6161  \n[Services]  section directive for a service shall set the directives  for 6162  \nStandardOutput  to either  null  or file: /path/to/ a/processes_ logfile  6163  \n(recommended setting) and StandardError  to inherit .  6164  \nRationale:  If not set the location  of StandardOutput  and StandardError  is 6165  \njournald . 6166  \nT&W:  CWE -20, CWE -221, CAPEC -113, TRTB -00037  6167  \nJALSR -5 [~*/HB,  ~*/CCOTS ] All CDS  processes  shall send audit and logging  data to a central 6168  \naudit and logging daemon (CALD)  via a one-way inter -process communications (IPC) 6169  \nmechanism . 6170  \nT&W: WRTB -00034, CAPEC -554, TRTB -00004, TRTB -00021  6171  \nJALSR -6 [~*/HB, ~*/CCOTS ] Unless otherwise stated, all CDS subsystems  shall audit all 6172  \nadministrative actions performed including the user name, user ID , the time , the role used, 6173  \nthe action performed, the parameters/ data tied to the action, and the results of that action.   6174  \nT&W: CWE -778, TRTB -00037, TRTB -00071  6175  \nJALSR -7 [", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}470{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "469", "chunk": "~*/HB,  ~*/CCOTS ] The CALD shall  syntactically and semantically  filter all CDS 6176  \naudit/log data to verify that it complies  with its specification before  acting on the data and 6177  \nbefore  transferring audit/log data to other processes and to storage .  6178  \nT&W: CWE -20, CAPEC -153 6179UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 224 of 397 JALSR -7.1  [~*/HB, ~*/CCOTS ] The CDS shall go into maintenance mode and disable all 6180  \ncommunications interfaces if CALD receives malformed audit/log data.  6181  \nT&W: CWE -636, CWE -799, WRTB -00041, CAPEC -184, CAPEC -554 6182  \nJALSR -8  [~TCDS ] The CDS shall hav e the ability to retain logs for 90 days . 6183  \nClarification: All logs include (but are not limited to) system boot /shutdown logs , 6184  \nsystem hardware status/errors, operating systems logs (e.g., dmesg, 6185  \n/var/log/messag es, syslogd , journald, auditd ), integrity 6186  \nmonitoring logs, logs of all CDS processes,  and filter logs . 6187  \nJALSR -9 [TCDS] The CDS shall have the ability to retain logs for 30 days . 6188  \nClarification: All logs include (but are not limite", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}471{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "470", "chunk": "d to) sys tem boot /shutdown logs , 6189  \nsystem hardware status/errors, operating systems logs (e.g., dmesg, 6190  \n/var/log/messages, syslogd, journald, auditd ), integrity 6191  \nmonitoring logs, logs of all CDS processes,  and filter logs . 6192  \nJALSR -9.1  [TCDS] The CDS shall  have the ability to auto -rotate and purge logs that are 6193  \nbeyond the retention time perio d or if a minimum free disk space (e.g., < 5% free ) 6194  \nsituation has occurred.  6195  \nJALSR -10 A stateless CDS may use an  external system high system to retain logs if delivery of 6196  \nthe logs to the external system can be confirmed.  6197  \nT&W: CWE -221, CWE -668, TRTB -00037, TRTB -00071, TRTB -00077  6198  \nJALSR -11  [TCDS]  The CDS shall have the confi gurable ability to continue processing  data if 6199  \nthe system is not able to store or send audit or log data . 6200  \nRationale:  This requirement exists for CDS that are mission critical systems (e.g. , Sensor 6201  \nto Shooter) where the risk of the CDS dataflow shutting dow n due to failure to audit 6202  \nis operationally too great.   6203  \nClarification:  This applies only to CDS integrated into weapon systems, sensors, and 6204  \nSCADA/ICS systems.  This does not apply to JAL processes crashing.  6205  \nT&W: CWE -221, CWE -400, ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}472{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "471", "chunk": "CAPEC -125, TRTB -00037  6206  \nJALSR -12 Deleted. Merged  with  JALSR -9.1 6207  \nJALSR -13 [~*/HB,  ~*/CCOTS ] The CDS shall not delete the dataflow /filter policy files  and 6208  \nassociated audit events  until dataflow/filter policy files and the associated audit/log 6209  \nrecords  that reference those policy files are archived . 6210  \nT&W: CWE -221, TRTB -00037, TRTB -00071  6211  \nJALSR -14 [~*/HB,  ~*/CCOTS ] The JALS  process(es) shall ingest OS audit data ( e.g., auditd 6212  \nprocess ) and OS logging ( e.g., /var/log  or syslogd ) information into a common 6213  \ndata store  (e.g., a local database on the CDS).  6214UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 225 of 397 JALSR -15 [~*/HB,  ~*/CCOTS ] The JALS  subsystem should provide a mechanism to transfer  6215  \nCDS audit and  log data , via the CDS\u2019 management interface , to the DCO of CDS Out -of- 6216  \nBand (OOB) network  the for archival and analysis . 6217  \nJALSR -16 [~*/HB, ~*/CCOTS ] The JALS subsystem should provide a mechanism to transfer 6218  \njournal and quarantined data, via the CDS\u2019 management interface, to the DCO of CDS ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}473{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "472", "chunk": "6219  \nOut-of-Band (OOB) network for archival and analysis.  6220  \nJALSR -17 Deleted.  6221  \nJALSR -18 [~TCDS] Auto -rotation and/or auto -deletion of logs on non -tactical systems may be 6222  \nused if automated remote transfer (with confirmation of receipt) is used prior to removal 6223  \nof the logs . 6224  \nT&W: CWE -221, TRTB -00037, TRTB -00071  6225  \nJALSR -19 [~*/HB] Operating System Audit subsystem  shall  be configured to comply with the 6226  \naudit requirements of the relevant DISA STIGs222 even if the processes  are not expected 6227  \nto be run or not allowed to be run via MAC policy . 6228  \nJALSR -20 [~*/HB,  ~*/CCOTS ] The CDS shall log all content filterin g failure s, failure reasons, 6229  \nand error conditions . 6230  \nT&W: CWE -778, TRTB -00037  6231  \nJALSR -21 [~*/HB,  ~*/CCOTS ] The CDS shall have the ability to quarantine data that fails 6232  \nfiltering or causes an error during filtering . 6233  \nT&W: CWE -223, TRTB -00037  6234  \nJALSR -22 [~*/HB,  ~*/CCOTS ] The CDS shall have the ability to log all filtering actions and 6235  \nresults for content being filtered . 6236  \nT&W: CWE -778, TRTB -00037  6237  \nJALSR -23 [~*/HB,  ~*/CCOTS ] If a JAL subsystem process fails , the CDS shall  shutdown or 6238  \ntransition the CDS to maintenance  mode . 623", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}474{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "473", "chunk": "9  \nT&W: CWE -221, CWE -636, TRTB -00037  6240  \nJALSR -24 [~TCDS /*, ~*/CCOTS ] The CDS shall provide a mechanism to alert system 6241  \nadministrators on the management  network  or high side network of system if there are 6242  \nproblems  or security issues requiring operator assistance to resolve.  6243  \nJALSR -25 [~*/HB, ~*/CCOTS ] The  CDS shall implement a  mechanism  to configure  the log 6244  \nretention policy . 6245  \nJALSR -26 [~*/HB ] All CDS process es shall use  a common logging format internal to the CDS 6246  \n \n222 https://iase.disa.mil/stigs/os/Pages/index.aspxUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 226 of 397 that supports robust enumeration of fields in each record.  6247  \nJALSR -26.1  [~*/HB ] The CDS Audit/Logging system shall support export of the audit/log data 6248  \ninto XML or JSON for backup/archival and automated (or manual) remote transfer to log 6249  \nanalysis system ( e.g., a SIEM tool).   6250  \nJAL SR-26.2  [~*/HB ] The CDS should use the Journaling, Auditing and Logging Protocol 6251  \n(JALoP) Audit Format (JAF) for internal audit/logging storage.  6252  \nJALSR ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}475{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "474", "chunk": "-26.3  [~*/HB ] The CDS shall  use JAF as the format for remote audit/log transfer.  6253  \nJALSR -27 The CDS should  not implement syslogd type of strings -based  logging because of the 6254  \nlack of enumeration of fields, possibly of truncation (by the syslogd daemon), and 6255  \ncomplexity in parsing the data.  6256  \nT&W: CWE -1120, CWE -20, CWE -222, CAPEC -153, TRTB -00037  6257  \nJALSR -28 The CDS shall utilize JAF as the data format for CDS audit and log records if  the 6258  \nCDS cannot implement a database  backend for performance or operational environment 6259  \nreasons.  6260  \nJALSR -29 The JALS shall have the ability to transfer Audit and Log data to the Remote 6261  \nMonitoring components to support audit/log off -load and statistical analysis . 6262  \nJALSR -30 The CDS shall implement a Central Journal Daemon (CJD) which will be 6263  \nresponsible for receiving content (called journaled data) processed by the CDS .  6264  \nClarification: This requirement is optional for streaming data.  6265  \nT&W: CWE -223, CWE -653, WRTB -00106, CAPEC -69, TRTB -00037  6266  \nJALSR -30.1 The CDS shall have the ability to set journaling levels, at minimum , to: all content  6267  \n(includes original and filtered content ); failed content ( e.g., quarantined data);  selective 62", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}476{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "475", "chunk": "68  \ncontent based on metadata about the content including source/destination domains, 6269  \ncustomer  ID (e.g., email address) , dataflow ID, and filter policy ID; filtered content; and 6270  \noriginal content.  6271  \nJALSR -30.2  The CDS shall use a one -way IPC mechanism to transfer journaled data  from CDS 6272  \nprocesses to the CJD . 6273  \nT&W: WRTB -00034  , CAPEC -554, TRTB -00004, TRTB -00021  6274  \nJALSR -30.3  The CJD shall wrap journal ed/quarantined data in an SFTF223 container upon 6275  \nreceipt for safe storage and  transfer to other processes . 6276  \nT&W: CWE -707, TRTB -00081  6277  \nJALSR -31 The JAL Subsystem must be  able to detect if a log file was removed or truncated  6278  \n \n223 SFTF Speci fication is available from the NCDSMO\u2019s unclassified portal.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 227 of 397 without going through the CDS\u2019s controlled archiving and deletion process.  6279  \nT&W:  CWE -221, CWE -222, CAPEC -268 6280  \nJALSR -31.1  If an uncontrolled removal of a log file occurs, then the CDS shall audit the event 6281  \nand transition to  maintenance mode.  6282  \n", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}477{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "476", "chunk": "T&W: CWE -221, CWE -222, CAPEC -268 6283  \nJALSR -32 Logs  or statistical data  for processes that are externally facing (e.g., protocol 6284  \nadapters) or that process  external  data (e.g., filters)  shall be syntactically and semantically  6285  \nfiltered prior to processing by EM/PE components.  6286  \nT&W: CWE -117, TRTB -00004  6287  \nJALSR -33 The CDS shall implement  the audit requirements described in the CDS Overlay ( as 6288  \nrequired by the SCR -2 RTB requirement ). If an audit event in CDS overlay conflicts with 6289  \nan audit event in this document, then this document shall  be used . 6290  \nJAL SR-34 The CDS shall implement the baseline CDS JAF profile rtb-v4-base-cds- 6291  \naudit-profile  described in Required Audit Events for Cross Domain Solutions , 6292  \nv1.0, NCDSMO Doc ID : NCDSMO -R-00019 -001_00 . 6293  \nJALSR -34.1 If the audit event does not apply to the CDS, then the design documentation shall 6294  \nprovide an explanation for why the audit event is not implemented.  6295  \nJALSR -35 The CDS shall provide a  vendor device specific  JAF Profile with the  unique audit 6296  \nevents  for the CDS. This vendor specific JAF profile is in addition to implementation of 6297  \nthe rtb-v4-base-cds-audit-profile. 6298  \nJALSR -36 [~*/TACDS] The CDS shall shutd", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}478{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "477", "chunk": "own or transition to maintenance mode if the CDS  6299  \nis not able to audit.  6300  \nT&W: CWE -221, CWE -636, TRTB -00037  6301  \nJALSR -37 [*/TACDS] Tactical CDS should  shut down its dataflows  if the CDS  is not able to 6302  \naudit.  6303  \nT&W: CWE -221, CWE -636, TRTB -00037  6304  \nJALSR -38 The CDS shall ensure the JAL , system protection services (e.g., application allowlist 6305  \nprocesses, SCAP scanner processes, system integrity moni toring processes, MAC 6306  \nenabled checker),  and EM/PE subsystems are started and operational prior to starting 6307  \nother CDS subsystems  (e.g., filters  and supporting processes, protocol adapters, remote 6308  \nmanagement systems, domain router) . 6309  \nT&W: CWE -221, WRTB -00105,  CAPEC -554, TRTB -00037  6310  \nJALSR -39 The CDS  developer  shall create a  CDS Log Analysis and Diagnostic Guid e. This 6311  \ndocument shall include at least the following information : 6312  \n\u2022  A list of all logs and their paths created specifically by CDS processes and by the 6313UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 228 of 397 operating system.  6314  \n\u2022  Anno", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}479{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "478", "chunk": "tated example of CDS boot and shutdown logs explaining all messages.  6315  \n\u2022  Annotated example filter reports and filter logs for all data types supported by the 6316  \nCDS. For CDS with fixed forma t parser, representative sample data formats 6317  \nshould be used that exercise the capabilities of the parser. Positive and Negative 6318  \ntest files should be used.  There should be test cases that demonstrate all audit and 6319  \nlog messages generated by the parser.  6320  \n\u2022 Annot ated log files demonstrating the complete configuration process of the CDS  6321  \nincluding demonstrating the actions of the different roles on the system.  6322  \n\u2022 Annotated log files demonstrating known error and failure conditions , for which 6323  \nthere are  audit or log mess ages, in the CDS (e.g., integrity violations, login 6324  \nfailures, process death, shutdowns due to policy violations or filter error 6325  \nthresholds being exceeded, etc.).  6326  \n\u2022 Annotated logs demonstrating correct functioning of the filters, protocols, and the 6327  \nRMAN  and RMON system s. 6328  \n\u2022 Example s of MAC, DAC, and Secure Computing Mode (SECCOMP) violations.  6329  \n\u2022 Annotated logs demonstrating authorized and unauthorized 6330  \nchanges/insertions/removal of hardware.  6331  \n\u2022 Annotated connectio", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}480{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "479", "chunk": "n logs for correct and incorrect/invalid connections.  This is 6332  \nfor all protocol adapters on the system including for dataflow, remote 6333  \nmanagement, and remote monitoring.  6334  \nRationale : The document is used to assist cybersecurity service providers and incident 6335  \nresponders in understanding the normal  operation of the CDS.  The guide should 6336  \nassist in identifying a compromised CDS platform or data channel .  6337  \nJALSR -40 [~*/HB, ~*/CCOTS] The JALS subsystem shall provide a mechanism to transfer 6338  \nCDS audit and log data, via the CDS\u2019 monitori ng interface directly into the DCO of CDS 6339  \nOut-of-Band (OOB) network the for archival and analysis.  6340  \nJALSR -41 [~*/HB, ~*/CCOTS] The JALS subsystem shall provide a mechanism to transfer 6341  \njournal and quarantined data, via the CDS\u2019 monitoring interface directly into the DCO of 6342  \nCDS Out -of-Band (OOB) network the for archival and analysis.  6343  \nJALSR -42 [~*/HB, ~*/CCOTS] The CDS shall have the ability  to capture the STDOUT and 6344  \nSTDERR of all CDS and operating system process es and send  the results to the CALD . 6345  \n Rationale: This is intended to support DCO of CDS and system performance and 6346  \nstability monitoring.  6347  \nJALSR -43 [~*/HB, ~*/CCOTS] The CDS devel", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}481{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "480", "chunk": "oper shall implement a JAL API for creating 6348  \nand sending audit/log events to the CALD and wrapping (e.g., via SFTF) and sending 6349UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 229 of 397 journal data to the CJD.  6350  \nClarification:  API essentially creates standardized JAF records that are  used to report 6351  \nfailure conditions in the PA and filters so that the EM/PE subsystem can act on those 6352  \nfailures. Inconsistent reporting of failures would impact the ability to defend the CDS.  6353  \nJALSR -44 [~*/HB, ~*/CCOTS] The CDS developer s hall implement an EM/PE API for the 6354  \nCDS components  (including Modular Pipeline Compnents) to receive and act on 6355  \nmessages from the EM/PE subsystem.  6356  \nClarification:  This API shall include support for graceful shutdown of the components 6357  \nand reloading of the component\u2019s  configuration.  6358  \n 6359  \n10.13  Remote Monitoring  Requirements  (RMONR) 6360  \nRemote monitoring is defined as the ability to remotely retrieve audit  data, log data, journaled 6361  \ndata,  compliance data,  and health, status, and performance informatio", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}482{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "481", "chunk": "n from the CDS for the 6362  \npurpose of ensuring the security and availability of the CDS.   6363  \nRMONR-1 [~*/HB] The CDS should implement a mechanism to transfer JAL data from the 6364  \nCDS via the manageme nt network interface . 6365  \nRMONR-2 [~*/HB] The CDS should implement the Journaling, Auditing and Logging Protocol 6366  \n(JALoP)  to transfer Audit, Log, and Journal (including quarantined) data off the CDS.  6367  \nRMONR-3 [~*/HB] If the CDS does not implement JALoP , then the CDS shall implement \u201c The 6368  \nSyslog Protocol \u201d as defined in IETF RFC 5424 for the remote transport of Audit and Log 6369  \ndata. 6370  \nRMONR-3.1  The CDS shall implement \u201c Transmission of Sys log Messages over TCP\u201d  as 6371  \ndefined in IETF RFC 6587 . 6372  \nRMONR-3.2 The CDS shall implement \u201c Transport Layer Security (TLS) Transport Mapping for 6373  \nSyslog \u201d as defined IETF RFC 5425 to ensure reliable and secure delivery of Syslog 6374  \nmessages . 6375  \nRMONR-3.3 The CDS may also implement \u201cTransmission of Syslog Messages over UDP \u201d as 6376  \ndefined in IETF RFC 5426 . 6377  \nRMONR-3.4 The CDS  should  implement \u201cDatagram Transport Layer Security (DTLS) 6378  \nTransport Mapping for Syslog \u201d as defined in IETF  RFC 6012  if Syslog over UDP is 6379  \nenabled.  6380  \nRMONR-3.5 The CDS ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}483{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "482", "chunk": "should implement \u201c Signed Syslog Messages \u201d as defined in IETF RFC 6381  \n5848 to ensure integrity of syslog messages  in transit . 6382  \nRMONR-4 [~*/HB] If the CDS does not implement JALoP, then the CDS shall implement 6383  \nHTTPS to transfer journal data (e.g., quarantined  data) from the CDS .  6384UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 230 of 397 RMONR-4.1 [~*/HB, ~*/CCOTS ] The CDS journal  transfer mechanism shall be an HTTPS 6385  \nclient  but not an HTTPS server . 6386  \nRMONR-5 [~*/HB] If the CDS does not implement JALoP, the CDS  may also implement SFTP 6387  \nto transfer journal ( e.g., quarantined data) from the CDS .  6388  \nRMONR-5.1 [~*/HB, ~*/CCOTS ] The CDS journal transfer mechanism shall be an SFTP client  6389  \nbut not an SFTP server . 6390  \nRMONR-6  [~TCDS/*] The CDS shall have the ability to delete local JAL  data only if the CDS 6391  \ncan transfer that data and confirm receipt at the remote monitoring server  after the data 6392  \nhas been transfe rred. 6393  \nRMONR-7 To enable rem ote monitoring of CDS health, status, and performance, the CDS 6394  \nshould implement the ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}484{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "483", "chunk": "NS A \u201cGuidance for Remote Monitoring of Cross Domain 6395  \nSolutions Using Simple Network Management Protocol (SNMP) Version 3 \u201d version 1.1 6396  \nor higher including CDS SNMP Management  Inform ation Base (MIB) Version 1.0.10  or 6397  \nhigher . 6398  \nRMONR-7.1 The CDS SNMP daemon shall not implement  SNMP SET commands . The CDS 6399  \nshall compile out the SET feature of SNMP v3 to restrict the usage to SNMP GET and 6400  \nSNMP Traps only . 6401  \nRMONR-7.2 The CDS shall implement one -way IPC transfer mechanism s from the CALD and 6402  \nother operating services to the SNMP processes.  6403  \nRMONR-8 The CDS shall  only send JAL data or SNMP data via the management network 6404  \ninterface or the system high network interface , except when the CDS is implemented 6405  \nusing a hardware based one-way transfer mechanism.  6406  \nRMONR-8.1 CDS that are implemented using a hardware based one -way transfer mechanism 6407  \nshall use a dedicated management interface for the low side pitcher/catcher of the one - 6408  \nway transfer mechanism to transfer JAL and SNMP  off the CDS.  6409  \nRMONR-9 The CD S shall not use TFTP for JAL data transfer . 6410  \nRMONR -10 The CDS process responsible for transferring JAL data off the CDS shall get its 6411  \ndata via  a one -way IPC from th", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}485{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "484", "chunk": "e JAL subsystem.  6412  \nRMONR -10.1 The CDS process responsible for transferring JAL shall not have the ability to 6413  \ndelete or alter JAL data.  6414  \nRMONR-11 [~*/HB] The CDS shall  implement a mechanism to transfer JAL data from the 6415  \nCDS via the monitoring  network interface.  6416  \n10.14  Remote Management  Requirements  (RMANR)  6417  \nRemote management is defined as the abil ity to remotely modif y the configuration of the CDS 6418  \nand includes  actions such as:  installation of patches and software updates, dataflow policy 6419UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 231 of 397 changes, account management , reviewing logs, performance tuning , and examining  the security 6420  \nstate of the device . Remote management can be used to monitor the CDS.  6421  \nRMANR -1 The CDS shall implement a mechanism to remotely manage the CDS via the 6422  \nmanagement interface . 6423  \nRMANR -1.1 The CDS may implement a mechanism to remotely manage the CDS over the 6424  \nsystem high dataflow interface.  6425  \nRMANR -2 [~*/HB,  ~*/CCOTS ] The CDS shall implement a remote virtual desktop 6426  \n", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}486{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "485", "chunk": "infrastructure (VDI)224 for remote management .  6427  \nRationale:  This remote VDI approach to remote management is easier to secure at 6428  \nprotocol level than SSH or Telnet and doesn\u2019t suffer from the RBAC and audi ting 6429  \nproblems that web -based web administration has.  6430  \nRMANR -2.1 [TCDS ] The CDS should implement a remote VDI for remote management . 6431  \nRMANR -2.2  The CDS shall not allow command line access in a VDI session . 6432  \nRMANR -2.3 The CDS shall filter all inbound keyboard/mouse data to ensure syntactic and 6433  \nsemantic correctness . 6434  \nRMANR -2.4 The CDS shall filter all outbound image data to ensure syntactic and semantic 6435  \ncorrectness and introduce loss to reduce the possibil ity of potential misuse of the VDI  6436  \nprotocol  for unauthorized  file transfer.  6437  \nRMANR -2.5 The VDI system shall implement two-factor  authentication : mutually authenticated  6438  \nTLS via PKI (user\u2019s soft certificate or hardware token ) for the initial network connection 6439  \nthen username/password to login into the operating system . 6440  \nRMANR -2.5.1  The user logging into the VDI must match the certificate provided . 6441  \nRMANR -2.6 All VDI network communications must be encrypted using TLS  or DTLS . 6442  \nRMANR -2.7 The VDI server s", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}487{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "486", "chunk": "oftware on the CDS must block all USB or similar device access 6443  \n(e.g., to prevent DVD, hard drive, etc. ) inbound or outbound to prevent devices being 6444  \nmount ed onto or from the CDS.  6445  \nRMANR -2.8 VDI access shall be restricted to the  CDS  management or system high  dataflow 6446  \ninterface s. 6447  \nRMANR -2.9  The filters described in RMANR -2.3 and RMANR -2.4 must be inline between the 6448  \nexternally facing VDI interface and the internal session /display manager (e.g., X11 6449  \nServer) . 6450  \n \n224 For example, the Remote Frame Buffer Protocol (IETF RFC 6143, https://tools.ietf.org/html/rfc6143 ) would be a \ngood example if transmitted over TLS. Transport over IPSEC or SSH would not be acce ptable due to the tunneling \ncapabilities of the protocol.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 232 of 397 RMANR -3 [~*/HB]  The CDS shall not implement Secure Shell (SSH)225 for remote 6451  \nmanagement . However, if an exception is granted for a mission critical reason the 6452  \nfollowing requirement s shall be implemented : 6453  \nRMANR -3.1 The CDS shall use a chroot environment", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}488{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "487", "chunk": "  or similar mechanism to control access to 6454  \nsystem commands and files  that can be executed via SSH . 6455  \nRMANR -3.2 If SSH is implement ed, then t he CDS shall  only support  SSH Protocol Version 2 6456  \n(SSH -2). 6457  \nRMANR -3.3 The CDS shall disable  root login over SSH.  6458  \nRMANR -3.4 The CDS shall disable  host-based authentication , IP address based authentication, 6459  \nand support for .rhost  files for SSH connections.  6460  \nRMANR -3.5 SSH access shall be restricted to the  CDS  management or system high interface.  6461  \nRMANR -3.6 The SSH servers shall implement two-factor  authentication : mutually 6462  \nauthenticated  SSH keys for the network  connection , then username/password to login 6463  \ninto the operating system . 6464  \nRMANR -4 [~*/HB] The public keys of  authorized remote management users shall be stored on 6465  \nthe CDS to enable authentication of remote management connections.  6466  \nRMANR -5 [~*/HB] The CDS  shall only allow remote management connections from  users 6467  \nwhose  public keys are stored on the CDS.  6468  \nRMANR -6 [~*/HB] The CDS shall  validate PKI user certificates are signed by an 6469  \norganizationally approve d Certificate Authority, have not been revoked, and have not 6470  \nexpired before allowing their us", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}489{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "488", "chunk": "e.  6471  \nRMANR -6.1  [~*/HB] A CDS may use Online Certificate Status Protocol (OCSP) , RFC 6960, 6472  \nto validate that certificates have not been revoked ; however , all OSCP responses 6473  \n(inbound into the CDS)  shall  be filtered by separate filters prior to be ing processed and 6474  \nused by the CDS.  6475  \nRMANR -6.2  [~*/HB] A CDS may use HTTPS to retrieve Certificate Revocation Lists (CRL) 6476  \nto validate the certificates have not been revoked ; however , all CRL responses (inbound 6477  \ninto the CDS) shall be filtered by separate filters prior to be ing processed and used by the 6478  \nCDS.  6479  \nRMANR -7 [~*/HB] The CDS shall disable  Telnet for remote management connections . 6480  \nRMANR -8 [~*/HB] The CDS shall disable  TFTP for transfe r of files for remote manag ement . 6481  \nRMANR -9 [~*/HB] The CDS may implement  Stelnet (Telnet over TLS) for remote 6482  \n \n225 While use of SSH is allowed, primarily because of its efficiency over low bandwidth communications, its use is \ndiscouraged in favor VDI -type protocols because of the excessive capabilities of the protocol (e.g., VPN, GUI \ntunneling, file transfer, etc.). The option to use SSH will be removed in future revisions of this document.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FV", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}490{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "489", "chunk": "EY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 233 of 397 management connections226. 6483  \nRMANR -10  CDS sh all not use  Baseboard Management Controllers  (BMC ), Intelligent  6484  \nPlatform Management Interface  (IPMI)227 and similar remote management capabilities 6485  \n(e.g., Dell\u00ae iDRAC, HP \u00ae iLO, Oracle \u00ae ILOM) for remote installation, configuration or 6486  \nmanagement  of the CDS .   6487  \nClarification:  Unfortunately, many tier 1 hardware manufacturers do not provide server 6488  \nhardware without BMC/ILOM/IPMI -type of modules and they cannot be removed.  6489  \nUnfortunately, some hardware systems require the IPMI or similar management 6490  \ncontrollers to be used for firmware updates. If that situation occurs , the IPMI or 6491  \nsimilar management controller may be temporarily enabled for purpose of firmware 6492  \npatching but the connection to the controller must be via a dedicated device (e.g., a 6493  \nsystem hi gh maintenance laptop).  6494  \nRationale: This is due to the lack of a robust security design and well known insecure 6495  \nimplementations228 See vulnerabilities like  Cloudborne, CVE -2019 -6260, iDRACula, 6496  \nand CVE -2017 -12542 ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}491{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "490", "chunk": ". 6497  \nRMANR -10.1 If the IPMI controller can failover to other NI Cs (usually the first NIC) then that  6498  \nNIC shall be  physically disabled via a port protector and disabled in  the UEFI\u00ae  6499  \nconfiguration options  (if possible) . 6500  \nRMANR -10.2 BMC/ILOM/IPMI -type of modules may exist in a system so long as it is disabled 6501  \nin the UEFI\u00ae  firmware and physical protections against use ( e.g., port blockers, tamper 6502  \ntape) are applied.  6503  \nRMANR -10.3 If a BMC/ILOM/IPMI -type module i s in the system, the passwords for all built -in 6504  \nuser accounts must be set to random password s compliant with the password rules  6505  \nreferenced in SIHCR -11 but with a length set to the maximum allowed  by the module .  6506  \nRMANR -10.3.1 Each system shipped by the CDS developer shall have unique passwords.  6507  \nRMANR -10.3.2 The passwords shall not be share d with end -users/customers.   6508  \nClarification: Vendors may retain the passwords if that information is encrypted and not 6509  \nstored  on a computer connected to the Internet or Corporate network. It could be 6510  \nstored in an isolated development environment.  6511  \nRMANR -10.4 Remote access to BMC/ILOM/IPMI -type modules shall  be physically disabled  6512  \n \n226 While use of STelnet is a", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}492{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "491", "chunk": "llowed, primarily because of its efficiency over low bandwidth communications, its use \nis disco uraged in favor VDI -type protocols because of the excessive capabilities of the protocol (e.g., VPN, GUI \ntunneling, file transfer, etc. The option to use of STelnet may be removed in future revisions of this document.  \n227 https://www.trentonsystems.com/blog/ what -is-ipmi \n228 See https://blog.rapid7.com/2013/07/02/a -penetration -testers -guide -to-ipmi as an example of the types of \nproblems BMC/IPMI systemsUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 234 of 397 (e.g., port protectors , non -conductive epoxy ). 6513  \nRMANR -11 The CDS should use Guard Remote Management Protocol (GRMP) v3.1 or higher 6514  \nfor remote management.  6515  \n10.15  Protocol Adapter Requirements  (PAR)  6516  \nPAR -1 The CDS shall use separate  protocol adapters  (PA)  for each support ed protocol ( e.g., 6517  \nHTTPS PA, SFTP PA, Raw TCP Socket PA, Raw UDP Socket PA, etc.) . PA shall not 6518  \nsupport multiple protocols. There is an exception for TCP and UDP P as that use a 6519  \nconfiguration language to support custom da", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}493{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "492", "chunk": "ta flows protocols ( e.g., data flows that have 6520  \ncustom framing) \u2013 in this case mult iple protocols can be supported by a single PA.  6521  \nClarification:  This requirement also applies to application layer protocols.  6522  \nT&W: CWE -1125, CWE -653, CAPEC -233 6523  \nPAR -2 The CDS shall not allow a  single  PA instance  to access communication int erfaces in 6524  \nmore than one domain . 6525  \nT&W: CWE -668, CAPEC -1, CAPEC -180, CAPEC -554, TRTB -00042  6526  \nPAR -3 [~*/HB,  ~*/CCOTS ] The CDS shall , without operator intervention,  configure the IP 6527  \nFirewall when a PA is enabled to restrict the ports and protocols used by a PA to only 6528  \nthose required for the PA .  6529  \nT&W:  WRTB -00043, TRTB -00034  6530  \nPAR -4 [~*/HB,  ~*/CCOTS ] The CDS shall , without operator intervention, configure the IP 6531  \nFirewall to disable the ports and pro tocols used by a PA when the PA is disabled  or 6532  \nremoved . 6533  \nT&W:  WRTB -00043, TRTB -00034  6534  \nPAR -5 [~*/HB,  ~*/CCOTS ] The CDS s hall use MAC and DAC to isolate  the PA from other 6535  \nprocesses on the CDS  except via approved IPC mechanisms . 6536  \nT&W: CWE -653, CAPEC -180, CAPEC -234 6537  \nPAR -6 [~*/HB,  ~*/CCOTS ] The CDS shall use separate unidirectional IPCs into/out of the PA . 6538  \n", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}494{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "493", "chunk": "T&W: CWE -424, CWE -668, CAPEC -180, CAPEC -554, TRTB -00042  6539  \nPAR -7 [~*/HB,  ~*/CCOTS ] The PA shall not be a multi -level process . 6540  \nT&W: CWE -668, CWE -669, CAPEC -180, CAPEC -216, CAPEC -554 6541  \nPAR -8 [~*/HB] The CDS may implement P as that only accept inbound connections, only 6542  \ninitiate outbound connection s, or both ( e.g., for web services) . 6543  \nPAR -9 [~*/HB] Each dataflow protocol adapter should  be operated out of a separate chroot -like 6544  \nenvironment or Open Container Init iative  (OCI)  compliant container  on operating 6545UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 235 of 397 systems that support it.   6546  \nRationale: This reduce s the likelihood that a configuration or implementation mistake in 6547  \nthe PA could lead to remote traversal of the filesystem and the possible exfiltration of 6548  \ndata off the CDS or corruption of system files.  6549  \nT&W: CWE -284, CWE -668, CAPEC -122, CAPEC -180 6550  \nPAR -9.1 [~*/HB] Symlinks into the chr oot environment are not allowed to prevent \u201c cd .. \u201d 6551  \nattacks.  Hardlinks to system binaries are allowed to r", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}495{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "494", "chunk": "esolve patching complexity . 6552  \nT&W: CWE -284, CWE -668, CAPEC -122, CAPEC -180 6553  \nPAR -10 [~*/HB]  The CDS shall not perform content filtering in protocol adapters.  6554  \nClarification:  Protocol  parsing and  filtering  for the purposes of protocol validation and 6555  \nmetadata and content extraction is allowed.  6556  \nT&W: CWE -1125, CWE -653, CA PEC-153, CAPEC -180, CAPEC -234, CAPEC -554, 6557  \nCAPEC -69, WRTB -00109  6558  \nPAR -11 [~*/HB] Externally -facing protocol adapters shall not use the same IPC mechanism as 6559  \nthe rest of the data flow pipeline.  6560  \nRationale:  PAs are the processes in a CDS that are at highest risk of compromise  due to 6561  \ntheir direct interaction with the environment. A compromise of the PA could expose 6562  \nthe IPC mechanisms and APIs used in the  CDS.  6563  \nClarification:  The IPC mechanism (e.g., Unix Domain Socket, M essageQ, Named Pipe) 6564  \nused by the PA can  be used in other internal CDS communication except for the 6565  \ndataflow pipeline and communications from  the dataflow pipeline to the CALD/CJD . 6566  \nAll PAs can use the same IPC mechanism (but not the instance of the IPC).  6567  \n10.16  Domain Router  Requirements  (DRR)  6568  \nNormally a Domain Router is not needed in a fixed two domain CDS. How", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}496{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "495", "chunk": "ever, its 6569  \nimplementation  is encouraged because it will enable extending the CDS to multiple doma ins. 6570  \nDRR -1 [~*/HB,  ~*/CCOTS ] The Domain Router process shall move dataflow  content between 6571  \ndomains within the CDS  in accordance with the dataflow  policy.  6572  \nT&W:  CWE -424, CWE -668, CAPEC -554, TRTB -00042  6573  \nDRR -2 [~*/HB,  ~*/CCOTS ] The Domain Router process shall not filter or parse dataflow  6574  \ncontent . 6575  \nT&W:  CWE -1125, CAPEC -153, CAPEC -234, CWE -653, WRTB -00109, TRTB -00065  6576  \nDRR -3 [~*/HB,  ~*/CCOTS ] The Domain Router process shall validate the dataflow  metadata to 6577  \nensure t hat the correct dataflow  filtering policy was used to filter the data prior to 6578  \ntransferring the data to the recipient domains.  6579UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 236 of 397  T&W: CWE -707, TRTB -00061 , CWE -707, TRTB -00061  6580  \nDRR -4 [~*/HB,  ~*/CCOTS ] In ADP -1, ADP -3, ADP -4, and ADP -5 the Domain Router (if 6581  \npresent) process shall validate the hash of the dataflow  content matches the hash in the 6582  \ndataflow  metadata  or ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}497{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "496", "chunk": "filter report  prior to transferring the data to the recipient domains.  6583  \nT&W:  CWE -354, CAPEC -148 6584  \nDRR -5 [~*/H B, ~*/CCOTS ] The Domain Router process shall verify the  content successfully 6585  \npassed filtering  before transferring the content to the receiving domain.  6586  \nT&W: CWE -707, TRTB -00061  6587  \nDRR -6 [~*/HB, ~*/CCOTS ] The CDS shall use MAC and DAC to isolate the Domain Router 6588  \nprocess from other processes on the CDS except via a one -way IPC mechanisms.  6589  \nT&W:  CWE -653, CAPEC -180, CAPEC -234 6590  \nDRR -7 [~*/HB, ~*/CCOTS ] The Domain Router process shall log a fi lter report verification 6591  \nfailure and shutdown if any filter report does not pass all verifications since this condition 6592  \nshould never occur.  6593  \nT&W: CWE -636, CWE -778, CAPEC -184 6594  \nDRR -8 [~*/HB, ~*/CCOTS ] If a Domain Router process crashes , the CDS shall shutdown all 6595  \ndataflow s and  transition  immediately  to maintenance mode . 6596  \nT&W:  CWE -636, CAPEC -184 6597  \nDRR -9 [~*/HB, ~*/CCOTS ] In ADP -2 and ADP -6, the Domain Router process should validate 6598  \nthe hash or HMAC of the dataflow content matches the hash in the dataflow metadata or 6599  \nfilter report prior to transferring the data to the recipient domains.   6600  \nCl", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}498{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "497", "chunk": "arification:  If ADP -2 or ADP -6 are being used to process Complex Document Data, 6601  \nthen DRR -4 applies and DRR -9 does not. ADP -2 and ADP -6 design patterns are 6602  \nintended to process high throughput low latency data ( e.g., fixed format military 6603  \nmessaging, XML, video, audio) and the computation t ime introduced by the HMAC 6604  \nor Digital Signing  may introduce too much latency and jitter  which is why this 6605  \nrequirement is a should , not a shall . Additionally, these data types support 6606  \nnormalization which reduces the attack surface against the dataflow pipel ine.  6607  \nT&W:  CWE -354, CAPEC -148 6608  \n10.17  Filter Report Validator  Requirements  (FRVR)  6609  \nThis section applies to CDS that do not have fully redundant and independent recursive 6610  \ndecomposition pipelines ( i.e., ADP -3, ADP -5) or in multi -domain versions of ADP -3 and ADP - 6611  \n5. In some two-domain variations of the ADP -4 design pattern an FRV is required to achieve 6612  \nsufficient independence when there  are dual instances of a  single FOE implementation.  6613  \nFRVR -1 [~*/HB , ~*/CCOTS ] The Filter Report Validator shall implement filter report 6614UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}499{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "498", "chunk": "\nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 237 of 397 validation via a n independent  implementation tha n the Results Processor . 6615  \nT&W:  CWE -1286, WRTB -00020, WRTB -00077, CAPEC -153, TRTB -00029, TRTB - 6616  \n00055  6617  \nFRVR -2 [~*/HB,  ~*/CCOTS ] The Filter Report Validator shall verify the dataflow  content was 6618  \nfiltered according to the correct dataflow  filtering policy . 6619  \nT&W: WRTB -00031, TRTB -00065  6620  \nFRVR -3  [~*/HB,  ~*/CCOTS ] The Filter Report Validator shall verify  that the content passed or 6621  \npassed with change . 6622  \nT&W: WRTB -00031, TRTB -00065  6623  \nFRVR -4 [~*/HB,  ~*/CCOTS ] The Filter Report Validator shall  verify  the integrit y of the filter 6624  \nreports.  6625  \nT&W: CWE -354, CAPEC -148, TRTB -00065  6626  \nFRVR -5 [~*/HB,  ~*/CCOTS ] The Filter Report Validator shall verify the filter report has been 6627  \nsigned by the appropriate filters  (i.e., those required by the correct dataflow  filtering 6628  \npolicy)  and by the FOE.  6629  \nT&W:  CWE -354, CAPEC -148, TRTB -00065  6630  \nFRVR -6 [~*/HB,  ~*/CCOTS ] The Filter Report Validator shall verify that the hash(es), size(s), 6631  \nand filename(s) of the content matches that in the repor", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}500{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "499", "chunk": "t.  6632  \nT&W:  CWE -354, CAPEC -148, TRTB -00061  6633  \nFRVR -7 [~*/HB,  ~*/CCOTS ] The Filter Report Validator shall log a filter report verification 6634  \nfailure and terminate,  if any filter report does not pass all verifications  as such a  condition 6635  \nshould never occur.  6636  \nT&W: CWE -636, CWE -778, CAPEC -184 6637  \nFRVR -8 [~*/HB, ~*/CCOTS ] The CDS shall use MAC and DAC to isolate the Filter Report 6638  \nValidator from other processes on the CDS except via one-way IPC mechanisms . 6639  \nT&W:  CWE -653, CAPEC -180, CAPEC -234 6640  \nFRVR -9 [DCCDS -CD/TSB , DCCDS -CD/THA ] A second , independently implemented  filter 6641  \nreport validator shall be placed in the filter pipeline  to ensure that the receiving domain  6642  \nside of the CDS is getting  data authorized for the domain and that the data  has passed 6643  \nfiltering  with the correct filter policy for  receiving domain . 6644  \nT&W: WRTB -00020, WRTB -00077, TRTB -00029, TRTB -00055  6645  \nFRVR -9.1 [DCCDS -CD/TSB , DCCDS -CD/THA ] If the second, independently  implemented  6646  \nfilter report validator  is implemented prior to the Domain Router then there shall  be a 6647  \nprocess in the receiving pipeline that verifies that the received content and associated 6648  \nmetadata are authorized f", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}501{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "500", "chunk": "or that domain . 6649UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 238 of 397 Clarification: The preferred location for the second Filter R eport Validator is in the 6650  \nreceiving domain after the Domain Router.   6651  \nT&W:  WRTB -00020, WRTB -00107, CAPEC -554, TRTB -00029, TRTB -00077  6652  \nFRVR -10 [~*/HB,  ~*/CCOTS ] The CDS shall not all ow content that failed or errored to be 6653  \ntransferred to the receiving domain.  6654  \nT&W: CWE -636, CWE -707, TRTB -00061  6655  \nFRVR -11 [~*/HB, ~*/CCOTS] The Filter Report Validator shall log success ful verifications of 6656  \nfilter  reports.  6657  \nT&W: CWE -778, TRTB -00037  6658  \nFRVR -12 [~*/HB, ~*/CCOTS] In multi -domain versions of the ADP -3 and ADP -5 the first 6659  \nFilter Report Validator must verify the content was filtered with the correct policy for the 6660  \ndestination domain.   6661  \nT&W: CWE -707, WRTB -00020, TRTB -00029, TRTB -00061  6662  \n10.18  Job Scheduler  Requirements  (JSR)  6663  \nThis section only applies to CDS that are implementing a Recursive Decomposition type of 6664  \narchitecture pattern (See ADP -3, ADP -4, ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}502{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "501", "chunk": "ADP -5). 6665  \nJSR-1 [*/TSB, */THA]  The Job Sc hedule r shall send dataflow  content and dataflow  metadata to 6666  \nthe appropriate filter(s) based on the dataflow  content type and the dataflow  filter policy 6667  \nselected . 6668  \nJSR-2 [*/TSB,  */THA ] The Job Scheduler shall have the ability to map a dataflow ID to a 6669  \ndataflow filtering policy . 6670  \nJSR-3 [*/TSB,  */THA ] The Job Scheduler shall not parse or filter dataflow  content . 6671  \nT&W:  CWE -1125, CWE -653, WRTB -00109, CAPEC -153, CAPEC -234, TR TB-00065  6672  \nJSR-4 [*/TSB,  */THA ] The Job Schedule r shall communicate with filters via a one -way IPC 6673  \nmechanism . 6674  \nT&W: WRTB -00034, CAPEC -554, TRTB -00004, TRTB -00021  6675  \nJSR-5 [*/TSB,  */THA ] The CDS shall use MAC and DAC to isolate the Job Scheduler from 6676  \nother processes on the CDS except via one-ways IPC mechanisms . 6677  \nT&W: CWE -653, CAPEC -180, CAPEC -234 6678  \nJSR-6 [~*/HB, ~*/CCOTS] If the Job Scheduler crashes, the CDS shall shutdow n all dataflows 6679  \nand transition immediately to maintenance mode.  6680  \nT&W: CWE -636, CAPEC -184 6681UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY,", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}503{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "502", "chunk": " ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 239 of 397 10.19  Results Processor  Requirements  (RPR)  6682  \nThis section only applies to CDS that are implementing a Recursive Decomposition type of 6683  \narchitecture pattern  (See ADP -3, ADP -4, ADP -5). In ADP -5, the Results Processor functionality 6684  \nis spread between the Operations Evaluator and the Dynamic  Router.  6685  \nRPR -1 [*/TSB,  */THA ] The Results Processor shall rec eive filtered content, filtered artifacts, 6686  \nunfiltered ar tifacts, and filter reports from filters . 6687  \nRPR -2 [*/TSB,  */THA ] The R esults Processor shall validate  filter reports for correctness . 6688  \nT&W: CWE -1286, CWE -354, CAPEC -148, CAPEC -153, TRTB -00065  6689  \nRPR -3 [*/TSB,  */THA ] The R esults Processor shall validate  that each filter report  contain s 6690  \npass/pass with change/fail/error filtering status . 6691  \nT&W: CWE -1286, CWE -636, CAPEC -153, TRTB -00061  6692  \nRPR -4 [*/TSB,  */THA ] The R esults Processor shall combine  individual filter reports for a given 6693  \ntransaction into a singl e report . 6694  \nRPR -5 [*/TSB,  */THA ] The R esults Processor shall digitally sign the combined filter report  6695  \nwith its unique key.  6696  \nT&W:  CWE -345, WRTB -00108, CAPEC -148, TRTB -00061  6697  \nR", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}504{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "503", "chunk": "PR -6  [*/TSB,  */THA ] The R esults Processor shall send dataflow  content to the next stage 6698  \n(usually the Filter Report Validator)  in the pipeline only after all artifacts are processed, 6699  \nall filter reports are validated,  and it generates and digitally signs the final filtering report 6700  \nfor the content.  6701  \nT&W:  CWE -1286, CWE -345, CWE -372, WRTB -00108, CAPEC -148, CAPEC -153, 6702  \nTRTB -00061  6703  \nRPR -7 [*/TSB,  */THA ] The Results Processor shall send unfiltered and filtered  artifacts  to the 6704  \nJob Schedule r for processing . 6705  \nRPR -8 [*/TSB,  */THA ] The Results Processor shall either drop  failed/errored content or send  it 6706  \nto quarantine.  6707  \nT&W: CWE -221, CWE -636, CWE -707, TRTB -00037, TRTB -00061  6708  \nRPR -9 [*/TSB,  */THA ] The Results Processor shall communicate with filters, the Job Scheduler 6709  \nand the next stage of the pipeline via one -way IPC s. 6710  \nT&W: CWE -424, WRTB -00034, CAPEC -554, TRTB -00004, TRTB -00021  6711  \nRPR -10 [*/TSB,  */THA ] The CDS shall use MAC and DAC to isolate the Results Processor 6712  \nfrom other processes on the CDS except via one-way IPC mechanisms.  6713  \nT&W:  CWE -653, CAPEC -180, CAPEC -234 6714  \nRPR -11 [~*/HB, ~*/CCOTS] If the Results Processor crashes, the CDS", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}505{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "504", "chunk": " shall shutdown all 6715UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 240 of 397 dataflows and transition immediately to maintenance mode.  6716  \nT&W: CWE -636, CAPEC -184 6717  \nRPR -12 [~*/HB, ~*/CCOTS] In multi -domain versions of the ADP -3 and ADP -5 the Results 6718  \nProcessor  must verify the content was filtered with the correct policy for the destination 6719  \ndomain.   6720  \nT&W: CWE -707, WRTB -00020, TRTB -00029, TRTB -00061  6721  \n 6722  \n10.20  Tamper Protection Requirements  (TPR)  6723  \nThe section contains the requirements for the implementation of passive and active anti -tamper 6724  \ntechnologies in CDS. It also includes requirements addressing TEMPEST issues in CDS.  6725  \nTPR -1 The CDS system shall have tamper -evident labels /coatings  placed on each point of 6726  \nphysical access to the internal components of the system ( e.g., case seams, screws, 6727  \nlatches) . 6728  \nTPR -2 The CDS system shall use port protectors for  unused USB, network, and other  6729  \ndevice /communications ports.   6730  \nTPR -3 CDS  tamper -evident labels /coatings  shall leave a detectable mar", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}506{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "505", "chunk": "king on the label /coating  6731  \nand the system when removed after initial application.  6732  \nTPR -4 Each CDS tamper -evident label /coating  shall be marked with a unique identification, 6733  \nwhich  can be recorded for future verification.  6734  \nTPR -5 The CDS shall only use NSA -approved  or NSA -recommended  tamper -evident 6735  \nmechanisms  for identification  of unauthorized modification during transit from Vendor to 6736  \nCustomer and while  under operation at the Customer  site. 6737  \nClarification: This applies to hardware, software media ( e.g., DVD, hard disks, tape, 6738  \nFobs, etc.) and documentation.  Contact the NCDSMO for  details on approved and 6739  \nrecommended mechanisms.  6740  \nTPR -6 Deleted and moved to SC -12 6741  \nTPR -7 Deleted and moved to SC -13. 6742  \nTPR-8 The list of  tamper -evident seals serial numbers for tamper-evident wrapped hardware, 6743  \nsoftware media, and documentation shall be delivered to the customer via a separate 6744  \nmechanism (e.g., encrypted email, SIPRNet , JWICS) than the delivery of the material.  6745  \nTPR -9 The customer, upon receipt of the  equipment , documentation,  and media; must verify the 6746  \nserial numbers of the tamper -evident seals against previously provided list of serial 6747  \nnumbers.  6", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}507{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "506", "chunk": "748  \nTPR -10 The customer must inspect the equipment, documentation,  and media for damage to the 6749UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 241 of 397 tamper -evident mechanism and report issues to the CDS Vendor.  6750  \nTPR -11 CDS developer may keep \u201cdepot level spares\u201d at customer facilities but those spares  6751  \nmust be wrapped in tamper -evident packaging which must be verified upon initial receipt 6752  \non the equipment from the developer and again prior to configuration of the device for 6753  \nplacement into operational use.  6754  \nTPR -12 CDS designed and implemented to protect a  weapon system or  C4ISR systems \u2019 Critical 6755  \nProgram Information (CPI)  data and are embedded and integrated with in the anti -tamper 6756  \nboundary  of the  weapon system or  C4ISR system shall implement mutually authenticated 6757  \nNSA approve d cryptographic techniques (e.g., Type -1 or CSfC ) between the weapon 6758  \nsystem or C4ISR system and the CDS.  6759  \nRationale:  This is intended to prevent an attacker from removing the CDS and being able 6760  \nto directly communicate with the weapon ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}508{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "507", "chunk": "system or C4ISR system  using the mission 6761  \nprotocols  and allow an  attack risk against the system  (perhaps to obtain CPI)  that the 6762  \nCDS was installed  to prevent.  6763  \nTPR -13 [TCDS /*] The CDS shall employ passive and active anti -tamper techniques to deter, 6764  \ndetect, and re spond to tamper violations in complianc e with the requirements stated in the 6765  \nNCD SMO document CDS Anti -Tamper and TEMPEST Implementation Requirements , 6766  \nv1.0 and higher.  6767  \nClarification:  While this requirement primarily applies to Tactical CDS. It may app ly 6768  \nto DCCDS  that are operated in environments (e.g., forward operating base s, ships, or 6769  \naircraft ) where los s of positive control of the CDS is likely.  6770  \nTPR -13.1 The CDS shall be able to detect and react to penetration and probing of the device via 6771  \nphysical, optical, radiological, and electrical means.  6772  \nTPR -13.2 The CDS shall be able to detect and react to the removal or opening of access panels 6773  \nthat allow access to the protect ed volume229. 6774  \nTPR -13.3 The CDS shall be able to detect and react to attempts to use radiation  and electrical  6775  \nfluctuations in an  attempt to alter the behavior of the device\u2019s anti -tamper mechanisms . 6776  \nTPR -13.4 The CDS ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}509{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "508", "chunk": "shall ensure that all software, configuration information , dataflow  6777  \nconfiguration  (e.g., rulesets , schemas) , and sensitive FPGA logic are cryptographically 6778  \nand electrically erase d on detection of a tamper event.  6779  \nTPR -13.5 The CDS shall have a mechanism that allows the CDS to be zeroized by an operator 6780  \nof the CDS without t riggering a tamper event.  6781  \nTPR -13.6 The CDS shall  have a mechanism that allows the CDS to be zeroized remotely  by a 6782  \n \n229 Protected Volume is portion of a device that contains the critical program information (e.g., technologies) that \nbeing protected by the anti -tamper mechanism. This typically contains sensitive chips, electronics, and storage (e.g., \nflash) and encryption keys.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 242 of 397 wired  electrical signal  (called a discrete) . 6783  \nRationale:  This allows the CDS to be integrated into a weapon system or C4ISR 6784  \nsystem \u2019s integrated zeroization system.  6785  \nTPR -13.7 A CDS integrated into a weapon system may inherit anti -tamper protections provided 6786  \nby the weapon i", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}510{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "509", "chunk": "f they meet or exceed the requirements in CDS Anti -Tamper and 6787  \nTEMPEST Implementation Requirements , v1.0 and higher , and test  procedures and  6788  \nevidence can be provided to NCDSMO.  6789  \nTPR -13.8 The CDS developer shall create a tamper attack tree analysis  for the CDS and map it 6790  \nto how the CDS\u2019s anti -tamper design mitigates the attacks.  6791  \n 6792  \n10.21  Supply Chain Requirements (SC)  6793  \nSC-1  The CDS developer is required to ensure integrity of the supply chain  in accordance with 6794  \nDoD , IC, and USG regulations and policies  (see Section 0   6795UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 243 of 397 Government Documents ). 6796  \nSC-2 The CDS documentation shall identi fy how the CDS developer minimize d supply chain 6797  \nrisk in accordance with CNSSD No. 505 Supply Chain Risk Management , DoD I 5200.44  6798  \nProtection of Mission Critical Functions to Achieve Trusted Systems and Networks , 6799  \nIntelligence Community Direction (ICD) 731 Supply Chain Risk Management (if an IC 6800  \nsystem) , and the process outlined in the Defense Acquisition Guidebook, C", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}511{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "510", "chunk": "hapter 9 6801  \n(Program Protection)230. This includes utilization of Hardware and Software Assurance 6802  \nbest practices . 6803  \nSC-3 The CDS developer shall conduct supply chain risk identification, assessment, 6804  \nprioritization, and mitigation activities in accordance with DoD , IC, and USG regulations 6805  \nand policies.  6806  \nSC-4 The CDS developer shall define a supply chain mitigation pla n and review/update it 6807  \nperiodically.   6808  \nSC-4.1 The supply chain mitigation plan shall cover  all aspects of the CDS system including 6809  \nsoftware , hardware, and system and component manufacturing and assembly . 6810  \nSC-5 The CDS developer supply chain mitigation plan shall include procedures for the 6811  \nidentification of counterfeit components prior to integration.  6812  \nSC-6 The CDS developer supply chain mitigation plan shall include provisi ons for responding to 6813  \nvulnerabilities found in components, whether directly developed or provided by a 6814  \n3rd party.  6815  \nSC-7 The CDS developer shall provide Supply Chain Risk Management (SCRM)  training to 6816  \ndevelopment staff on the program\u2019s SCR M procedures.  6817  \nSC-8 The CDS developer shall ensure DoD  SCRM  best practices are incorporated into 6818  \nagreements with 3rd party component de", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}512{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "511", "chunk": "velopers/manufacturers/suppliers.  6819  \nSC-9 The CDS developer shall request periodic veri fication from 3rd party component 6820  \ndevelopers/manufacturers/suppliers that they are following the SCRM  practices.  6821  \nSC-10 The CDS developer shall develop and implement test procedures to ensure th at non -CDS 6822  \ndeveloper developed or manufacture d software and hardware has not be en implanted  6823  \nwith malicious software /devices  at time of development/manufacture.  6824  \nSC-11 The CDS Developer shall only obtain  commercial closed and open source s oftware from 6825  \neither a n authorized Government  operated  repository or the primary distribution server 6826  \nfor the developer. Software distribution mirror  sites shall  not be used.  6827  \nClarification:  An example of a Government  operated software repository are the 6828  \nrepositories run by the DISA . Many other agencies including the major Intelligence 6829  \nCommunity agencies operate their own authoritative software repositories. The 6830  \n \n230 https://www.dau.edu/tools/dagUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 244 of 3", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}513{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "512", "chunk": "97 primary distribution server is a server that is  either  operated by the organization 6831  \nresponsible for the software project (e.g., the Apache Software Foundation \u00ae) or is the 6832  \nofficial hosting  site for  the software (e.g., Github \u00ae). This is in support of the 6833  \nSoftware Bill of Materials (SBOM) requirement described in t he Executive Order on 6834  \nImproving the Nation\u2019s Cybersecurity  (12 May 2021).  6835  \n 6836  \nSC-11.1 The CDS Developer shall verify the hashes of the 3rd party software match the vendor\u2019s 6837  \nsupplied hashes.  6838  \nSC-12 The CDS Vendors shall be responsible for the hardware  and firmware configurations  for 6839  \nthe installations.  6840  \nSC-13 CDS customers shall only purchase CDS hardware directly from the CDS vendor.  6841  \nClarification : Exceptions are allowed fo r: 6842  \ni) Tactical systems that have custom built hardware that is integrated into the 6843  \ntactical  system however, the CDS vendor must be provided sufficient access to 6844  \nthe hardware to implement the hardware security checks described in this  6845  \ndocument.  The anti -tamper requirement s are still required to be met.  6846  \nii) Enterprise environments where the customer has a requirement for a specific IT 6847  \nhardware vendor for their environmen", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}514{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "513", "chunk": "t. In this case, the customer must provide 6848  \nthe hardware to the CDS vend or so they can qualify their software on the 6849  \nhardware. If changes are made to the CDS , a review will need to be conducted by 6850  \nthe NCDSMO to determine what, if any, testing maybe required.  The NCDS MO 6851  \nmay require documentation to confirm the CDS  customer must  use a specific 6852  \nvendor\u2019s hardware.  The CDS vendor  must certify their software on the hardware 6853  \nand provide letter to the NCDSMO stating they will support the hardware  until 6854  \nthe CDS product is sunset or the customer replaces the hardware, whichever 6855  \ncomes fir st. 6856  \n10.22  Defensive Cyber space  Operations (DCO) of CDS Requirements  6857  \n(DCO R) 6858  \nDCO R-1 The CDS shall support the near -real time231 and periodic delivery of JAL data to a 6859  \nDCO Enclave for automated and manual analysis . 6860  \nDCO R-2 Deleted.  6861  \nDCO R-3 Deleted.  6862  \n \n231 Near real time means \u201cno significant delays\u201d but typically in the DCO in the range of hundreds of milliseconds to \n2-3 seconds. Periodic is defined as multiple times (e.g., every 2, 4, 6, etc. hours) within a given period (e.g., a day)UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}515{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "514", "chunk": "  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 245 of 397 DCO R-4 The CDS shall support  a capability to transfer  JAL data  to an isolated system high 6863  \nDCO Enclave.  6864  \nDCOR -5 Deleted.  6865  \nDCOR -6 The CDS developer shall provide to the NCDSMO the list of  all files (i.e., executables, 6866  \nscripts, libraries, config uration  files) for each version of their product including after 6867  \npatches are applied. Files that are intended to change (e.g., configuration files) shall be 6868  \nmarked as such.  This includes operating system , third -party  files and the contents of any 6869  \nMPCR containers.   6870  \nRationale: This information is needed to support forensic analysis of the CDS if a 6871  \ncompromise is suspected.  This is also in support of the Software Bill of Materials 6872  \n(SBOM) requirement described in the Executive Order on Improving the Nation\u2019s 6873  \nCybersecurity  (12 May 2021).  6874  \nDCOR -6.1 This list shall be provided in a CSV 232 format with the following fields (in order): 6875  \ncomplete name of file  with extension , path, SHA -384 hash, date/timestamp of the file, 6876  \nand true/false (Boolean if  the file\u2019s contents would be changed post install).  This file ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}516{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "515", "chunk": "6877  \nmust be provided  to the NCDSMO with 30 days of a release of a new version of the CDS 6878  \nor an OSPC . 6879  \nDCOR -6.2 The list of the CDS and Operating System log files and which processes use th em 6880  \nshall be provided in a CSV file  with the following fields: log file name, path, and 6881  \nsemicolon separated list of applications that write to that log.  This file must be provide d 6882  \nto the NCDSMO with in 30 days of a release of a new version of the CDS . 6883  \nDCOR -7 A CDS may have  an internal diode NIC to transmit  DCO data to the DCO OOB.  6884  \n11 Dataflow  Filtering Requirements  6885  \n11.1 General Dataflow  Filtering Requirements  (GDFR)  6886  \nThis section  applies primarily to Transfer CDS,  but it would also apply to R emote VDI based 6887  \nAccess CDS. It  does not apply to a Virtual Machine based Access CDS.  6888  \nGDFR -1 A Dataflow  Filter Policy shall be applied to the verification , inspection , sanitization, 6889  \nand transformation of each type of  data transiting the CDS . 6890  \nT&W:  CWE -707, TRTB -00061  6891  \nGDFR -2 The number of concurrent and active dataflow s supported by the CDS should only be 6892  \nlimited by available resources ( e.g., CPU, Memory, Storage Space) and not artificially 6893  \nlimited /throttled . Contr", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}517{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "516", "chunk": "olling resource allocation by configurable parameters is allowed.  6894  \n \n232 Comma -separated va luesUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 246 of 397 Each dataflow should have its own distinctly defined and separate dataflow filter policy.  6895  \nGDFR -3 [~*/HB] The CDS shall generate a unique job ID for each unique stream (e.g., 6896  \nvideo/audio) or file  (e.g., Microsoft Office\u00ae , PDF, images, XML, fixed format data)  6897  \nsubmitted to the CDS for transfer.  6898  \nT&W:  CWE -223, CWE -693, CWE -694, CWE -99, CAPEC -177, TRTB -00037  6899  \nGDFR -4 [~*/H B] CDS filters processing streaming data ( e.g., Full Motion Video, VOIP, XML 6900  \nWeb Services, etc.) may generate filter reports.  6901  \nT&W: CWE -223, CWE -345, CWE -778, CAPEC -148, TRTB -00037  6902  \nGDFR -4.1 [~*/HB]  CDS should use the NCDSMO\u2019s  Verification, Inspection, and Sanitization 6903  \n(VIS) Specification , version 1 .0 or higher, as the format  for its filter reports.  6904  \nGDFR -5 [~*/HB] CDS filters processing non -streaming data ( e.g., complex data  \u2013 like 6905  \nMicrosoft Office\u00ae , PDF, Imagery,  XML (a as file", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}518{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "517", "chunk": "), etc.) shall generate filter reports.  6906  \nT&W: CWE -223, CWE -345, CWE -778, CAPEC -148, TRTB -00037  6907  \nGDFR -5.1 [~*/HB]  CDS should use the NCDSMO\u2019s Verification, Inspec tion, and Sanitization 6908  \n(VIS) Specification , version 1.0 or higher, as the format for its filter reports.  6909  \nGDFR -6 [~/HB ,~*/CCOTS ] Filter reports shall be digitally -signed , XML -based , and be 6910  \nvalidated  by the  Filter Report Validator .  See EDSR -6. 6911  \nT&W:  CWE -345, CWE -349, CWE -778, CAPEC -148, CAPEC -194, TRTB -00037  6912  \nGDFR -6.1 Filter reports shall be generated for filtered content for design patterns ADP -1 (if 6913  \ncontent is Comp lex Data ), ADP -2 (if content is Complex Data), ADP -3, ADP -4, and 6914  \nADP -5. 6915  \nT&W: CWE -778, WRTB -00083, CAPEC -234, TRTB -00037, TRTB -00061  6916  \nGDFR -6.2 Filter reports may be generated for filtered content for design patterns ADP -1 and 6917  \nADP -2 unless the content is considered Complex Data  (see DCCDS -CD). If the  content 6918  \nis considered complex data , then Filter  Reports shall be generated.  6919  \nT&W:  WRTB -00083, CWE -778, CAPEC -234, TRTB -00037, TRTB -00061  6920  \nGDFR -6.3  Filter reports shall be digitally signed using the W3C XML Digital Signature  6921  \nspecification.  6922  \nGDFR", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}519{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "518", "chunk": " -6.4 Each filter shall have its own unique signing certificate . 6923  \nClarification: This mandatory for ADP -3 and ADP -5 and optional for ADP -4 due to the 6924  \nredundant independent pipeline.  6925  \nT&W:  CWE -653, CAPEC -194  6926  \nGDFR -6.5 The FOE processes shall have its own unique signing certificate . 6927  \nClarification: This mandatory for ADP -3 and ADP -5 and optional for ADP -4 due to the 6928UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 247 of 397 redundant independent pipeline.  6929  \nT&W:  CWE -653, CAPEC -194 6930  \nGDFR -6.6 Filter reports shall contain at least the following:  6931  \nGDFR -6.6.1 The filtering actions  and results ( i.e., pass, pass with change, fail, error) performed 6932  \non each piece of unique content  6933  \nT&W: CWE -223, TRTB -00037  6934  \nGDFR -6.6.2 Each filter \u2019s results  shall be signed by the filter with its own unique certificate  6935  \nClarification: This mandatory for ADP -3 and ADP -5 and optional for ADP -4 due to the 6936  \nredundant independent pipeline.  6937  \nT&W:  CWE -653, CAPEC -194 6938  \nGDFR -6.6.3 The file size s and hashes of the o", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}520{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "519", "chunk": "riginal and final content  6939  \nT&W:  CWE -778, TRTB -00037  6940  \nGDFR -6.6.4 The Job ID of the content  6941  \nT&W:  CWE -778, TRTB -00037  6942  \nGDFR -6.6.5 The timestamp of when the content was received  6943  \nT&W:  CWE -778, TRTB -00037  6944  \nGDFR -6.6.6 The original and new filename (s) of the content  6945  \nT&W:  CWE -778, TRTB -00037  6946  \nGDFR -6.6.7 The original and new MIME  (or similar mechanism that un iquely identifies the 6947  \ntype of the con tent) types of the content  6948  \nT&W:  CWE -778, TRTB -00037  6949  \nGDFR -6.6.8 The policy ID used to filter the content  6950  \nT&W:  CWE -778, TRTB -00037  6951  \nGDFR -6.6.9 The final filtering result for the content  shall be one of the following : pass, pass 6952  \nwith change, fail, or error  6953  \nT&W:  CWE -778, TRTB -00037  6954  \nGDFR -6.7 The results of all filtering actions shall be combined by the FOE into a single 6955  \ndigitally -signed report . This report will contain the digitally -signed reports by each of the 6956  \nfilters that filtered the content.  6957  \nClarification: The signing of filter report content by filters is  mandatory for ADP -3 and 6958  \nADP -5 and optional for ADP -4 due to the redundant independent pipeline.  But the 6959  \nentire filter report must be signed for all thr", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}521{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "520", "chunk": "ee design patterns.  6960UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 248 of 397 T&W:  CWE -223, CWE -345, CWE -349, CAPEC -148, CAP EC-194, TRTB -00037  6961  \nGDFR -7 [~*/CCOTS ] The CDS shall implement a mechanism to enforce the integrity and 6962  \nauthorization of dataflow  filter policies using a digital signing mechanism . 6963  \nT&W: CWE -345, CWE -349, CAPEC -148, CAPEC -194 6964  \nGDFR -7.1 The CDS shall require that dataflow  filter policies be signed by at least one digital 6965  \nsignature . This is not in lieu of the requirement for TKPC for installation and activation 6966  \nof a dataflow  defined in  the Role -Based Access Control (RBAC) Requirements  section.  6967  \nClarification:  Dataflows are normally signed by the Authorizing Official,  or their 6968  \ndesignee and their certificates are loaded onto the CDS during the initial provisioning 6969  \nof the CDS.  6970  \nGDFR -7.2 The CDS shall verify the integrity and signature of dataflow  filter policies prior to 6971  \ninstalling and activating the dataflow . 6972  \nT&W: CWE -345, CW E-349, CAPEC -148, CAPEC -194 6973  \nGDFR -7.3 The C", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}522{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "521", "chunk": "DS dataflow  signing private key should be treated as system high.   6974  \nGDFR -8 The CDS shall verify a file submitted for transfer  complies syntactically and 6975  \nsemantically with its stated data type specification (usually via file extension, claimed 6976  \nMIME -Type, or Magic Number) prior to other content aware filtering.  Antivirus  may 6977  \noccur prior to this filteri ng.  6978  \nT&W: CWE -434, CWE -351, CWE -646, CAPEC-209, CAPEC -635 6979  \nGDFR -9  The CDS filters for a given data type or class of data types shall apply mission specific 6980  \npolicies to the data to prevent data spills, data exfil tration , implant C2 and augmentation, 6981  \nexploit delivery, exploit execution, and malware implantation.  6982  \nClarification:  Mission specific policies are filter policies and rulesets unique to specific  6983  \na customer and potentially to a specific mission . A data owner\u2019s guide is another term 6984  \nfor a mission specific policy. Mission specific policies can include XML Schemas, 6985  \nconfiguration settings for specific filters (e.g., like a PDF or JPEG filter), 6986  \nruleset/parse tables, dirty/clean word list, etc.  6987  \nT&W:  CWE -707, TRTB -00061  6988  \nGDFR -10 For the data typ es and protocols that have a corresponding NSA Inspection and 6989", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}523{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "522", "chunk": "  \nSanitization Guidance (ISG) document, the CDS filters shall implement  the appropriate 6990  \nISG recommendations , as determined by the Authorizing Official/Organization,  to 6991  \nmitigat e the described data attack, data hiding, and data disclosure risks233.   6992  \n \n233 NSA ISG documents do not exist for all possible data types. CDS developers are encouraged to work with the \nNSA, NCDSMO, and supporting USG agency to determine the appropriate type and level of filtering required for \nthat data type.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 249 of 397 GDFR -11 All filters, including pass/fail only filters , shall always read  from and write to separate 6993  \nmemory or storage media ( e.g., hard drive) locations  for each action , and those locations 6994  \nshall be  MAC  and DAC isolated . 6995  \nClarification:  Moving data from filter input to filter output directories is not allowed. 6996  \nFilters must read data in, filter it, and explicitly write it back out.  6997  \nT&W: CWE -653, WRTB -00034 , CAPEC -180, TRTB -00021, TRTB -00065 6998  \nGDFR -12 The CDS shall ensure that all data being ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}524{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "523", "chunk": "transferred through the CDS has been sent 6999  \nthrough a filtering pipeline and only the filtered data is delivered to the destination 7000  \ndomain.  7001  \nT&W: CWE -424, TR TB-00065  7002  \nGDFR -13 CDS Filters shall ensure that only filtered content will be transferred to the next 7003  \nprocess  in the pipeline.  7004  \nT&W: CWE -707, CWE -424, TRTB -00061, TRTB -00065  7005  \nGDFR -14  CDS processing intelligence collect data can transfer the original message  unfiltered .  7006  \nRationale:  Modifications to intelligence collect data may result in the loss of inte lligence 7007  \ninformation ( e.g., stegano graphic ally  encoded data).  7008  \nGDFR -14.1 CDS processing intelligence collect data shall obfuscate the data prior to delivery to 7009  \nan endpoint. CDS may use any obfuscation  technique that will prevent accidental 7010  \nexecution of malicious content. The techniques could in clude XOR, base64, encryption, 7011  \nSFTF, or an organizationally  defined specification.  7012  \nT&W: CWE -707, TRTB -00067  7013  \nGDFR -15 [DCCDS -CD/*, ~*/HB ] A CDS shall support the ability to quarantine content that 7014  \nfails filtering . 7015  \nT&W: CWE -221, TRTB -00048  7016  \nGDFR -16  [DCCDS -FF/*, TCDS/* ] A CDS should support the ability to quarantine  content that 7017 ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}525{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "524", "chunk": " \nfails filtering . 7018  \nT&W: CWE -221, TRTB -00048  7019  \nGDFR -17 If the filter fails the content, then the content that was the input to that filter shall 7020  \nnever leave the filter  as output  except via a secondary channel (non -dataflow ) for 7021  \nquarantine (if quarantin ing is enabled ).  7022  \nT&W: CWE -668, TRTB -00065  7023  \nGDFR -17.1 A CDS may convert failed  content  to another datatype234 and send the content  back 7024  \n \n234 For example, co nverting a Microsoft Word file to PDF.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 250 of 397 through a pipeline to be filtered again.   7025  \nClarification: However, this is not allowed for content that fails due to data disclosure 7026  \nproblems (e.g., found dirty words, invalid/incorrect classification markings).  The original 7027  \nfailed file would still be sent to DCO OOB  for analysis.  7028  \nGDFR -18 If the CDS supports quarantine, then it shall use the Suspect File Transmission 7029  \nFormat (SFTF)  to obfuscate the quarantined data prior to transfer  off the CDS  (e.g., 7030  \nsending to a DCO OOB) . 7031  \nRationale: Obfuscati", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}526{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "525", "chunk": "ng the quarantined data reduces the risk of acci dental detonation of 7032  \nthe potentially malicious content.  7033  \nT&W:  CWE -707, TRTB -00067  7034  \nGDFR -19 [~*/HB , ~*/CCOTS ] If a filter crashes or enters a non -recoverable error state during 7035  \noperation, the CDS shall audit the error and  alert the administrators via  one or more of 7036  \nthe following means:  SNMP , remote JAL transfer, or email sent on the management 7037  \nnetwork . The CDS shall also  implement one of the following actions:  7038  \nT&W: CWE -778, WRTB -00085, TRTB -00064  7039  \nGDFR -19.1 [~*/HB , ~*/CCOTS ] The CDS shall immediately fail the content, mark the content 7040  \nas failed due to error, restart the filter, and , if quarantine is enabled  by the CDS,  send the 7041  \ncontent to quarantine.   7042  \nT&W: CWE -778, WRTB -00085, TRTB -00064  7043  \nGDFR -19.2 [~*/HB , ~*/CCOTS ] The CDS shall restart the filter and resubmit the failed content 7044  \nto the filter for processing. If the content causes the filter to fail a configurable number of 7045  \ntimes  but no greater than three , the content shall be marked as failed due to error, sent to 7046  \nquarantine ( if quarantin ing is enabled ), and the filter restarted.   7047  \nClarification: This is called the Three  Strikes rule fo", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}527{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "526", "chunk": "r filtering.  7048  \nT&W: CWE -778, WRTB -00085, TRTB -00064  7049  \nGDFR -19.3 [~*/HB , ~*/CCOTS ] The CDS shall stop the dataflow  if the filter fails, mark 7050  \ncontent as failed due to error, and send the content to quarantine ( if quarantin ing is 7051  \nenabled ). In ADP -3 and ADP -4 design patterns  based CDS , the Results Processor may be 7052  \nused to send the failed content to quarantine.  7053  \nT&W: CWE -778, WRTB -00085, TRTB -00064  7054  \nGDFR -19.4 [~*/HB , ~*/CCOTS ] The CDS shall shut  down the  CDS or transition the CDS to 7055  \nmaintenance (offline) mode.  7056  \nT&W: CWE -778, WRTB -00085, TRTB -00064  7057  \nGDFR -19.5 [~*/HB, ~*/CCOTS] The CDS shall stop all dataflow s associated with the security 7058  \ndomain in which the filter was running.  7059UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 251 of 397 T&W: CWE -778, WRTB -00085, TRTB -00064  7060  \nGDFR -20 [~*/HB,  ~*/CCOTS] Object Serialization (e.g., Java\u00ae  Object Serialization ) shall  not 7061  \nbe used  as message passing data forma t between filters , C2/ metadata messaging,  or other 7062  \ncomponents of the system . ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}528{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "527", "chunk": "7063  \nT&W: CWE -502, CWE -74, CAPEC -586 7064  \nGDFR -21 [~*/HB , ~*/CCOTS ] If a Protocol Adapter crashes or enters a non -recoverable error 7065  \nstate, the CDS shall audit the error and alert the administrators via one or more of the 7066  \nfollowing means: SNMP , remote JAL transfer,  or email sent on the management 7067  \nnetwork . The CDS shall also  implement one of the following actions:  7068  \nT&W: CWE -778, WRTB -00085, TRTB -00064  7069  \nGDFR - 21.1 [~*/HB , ~*/CCOTS ] The CDS shall stop all dataflow s associated with the security 7070  \ndomain in  which the PA was running . 7071  \nT&W: CWE -778, WRTB -00085, TRTB -00064  7072  \nGDFR -21.2 [~*/HB , ~*/CCOTS ] The CDS shall shut  down the CDS or transition the CDS to 7073  \nmaintenance (offline) mode.  7074  \nT&W: CWE -778, WRTB -00085, TRTB -00064  7075  \nGDFR -22 [~*/HB , ~*/CCOT S] For CDS that implement a FOE, i f a FOE  process crashes or 7076  \nenters a non -recoverable error state, the CDS shall  audit the error; alert the administrators 7077  \nvia one or more of the following means:  SNMP , remote JAL transfer, or Email sent on 7078  \nthe management network ; and shall shut down the CDS or transition it to maintenance 7079  \n(offline) mode . 7080  \nT&W: CWE -778, WRTB -00085, TRTB -00064  7081  \nGDFR -23 The", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}529{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "528", "chunk": " CDS should  implement least privilege for filters  by ensuring  that individual 7082  \nfilters are limited to processing  messages of a single data type , except in the case of 7083  \ngeneral  purpose filters, such as antivirus  or a fixe d format data parser.  7084  \nT&W: CWE -1125, CWE -653, CAPEC -234 7085  \nGDFR -24 The CDS shall support dirty  and clean word filtering of textual data extracted from 7086  \ncontent being filtered by the CDS . 7087  \nT&W: CWE -200, TRTB -00042  7088  \nGDFR -24.1 The CDS shall support dirty and clean  words in UTF -8 format . 7089  \nGDFR -24.2 The CDS shall support the use of IEEE POSIX\u00ae , Perl Compatible Regular 7090  \nExpressions (PCRE), or Java\u00ae  regular expressions for dirty and clean word matching . 7091  \nGDFR -24.3 The CDS shall support dirty and clean words in any language that can be 7092  \nrepresented  by UTF -8. 7093  \nGDFR -24.4 The CDS shall support per dataflow dirty word lists.  7094UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 252 of 397 T&W: CWE -200, TRTB -00042  7095  \nGDFR -24.5 The CDS should support per dataflow clean word lists.  7096  \nT&W: CWE -2", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}530{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "529", "chunk": "00, TRTB -00042  7097  \nGDFR -25 The CDS shall be able to detect encoded and encrypted data in text ual data and fail 7098  \nthe content.  7099  \nT&W: CWE -20, CWE -515, CAPEC -267, CAPEC -636 7100  \nGDFR -25.1 The CDS should  identify what type of encoded dat a is found . 7101  \nGDFR -25.2 The CDS shall be able to detect  BASE32 -, BASE64 -, UUENCODE -, and BINHEX - 7102  \nencoded data sequences greater  than 128 successive  characters . 7103  \nT&W: CWE -223, CWE -349, CWE -502, CWE -707, CAPEC -267, CAPEC -523 7104  \nGDFR -26 The CDS filters shall implement cleanliness to guarantee that content ( e.g., any 7105  \nextracted content, generated audit data, or reports) from multiple jobs does not  \u201ccross 7106  \ncontaminate\u201d with information from other  filtering job s. This includes ensuring that the 7107  \nCDS filter processes clean up any in-process  data in the event of a system restart ( e.g., 7108  \npower failure).  7109  \nT&W:  CWE -75, CWE -367, CWE -665, CWE -459, CAPEC -161, CAPEC -29, CAPEC - 7110  \n37, CAPEC -93 7111  \nGDFR -27 The CDS filter shall have the ability to enforce a configurable limit on filename  7112  \nlength  (e.g., 255). 7113  \nT&W: CWE -641, CWE -20, CAPEC -100, CAPEC -165 7114  \nGDFR -27.1 The filename length shall not exceed the operating system limit ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}531{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "530", "chunk": "for filename and 7115  \npath lengths.  7116  \nGDFR -28 The CDS  should convert content filenames to  a UUID prior to sending the content 7117  \nthrough filter pipeline and pass the original filename via the CDS metadata mechanism . 7118  \nClarification: If the content is being filtered is not written to t he file system then this 7119  \nrequirement does not apply.  7120  \nT&W: CWE -694, CWE -641, CAPEC -240, CAPEC -66, CAPEC -88 7121  \nGDFR -29 Externally provided filenames shall be filtered for d irty words and unsafe characters. 7122  \nUnsafe characters are described as characters that could cause accidental shell 7123  \nescape/exec ution or unsafe processing on receiving systems.  Examples of unsafe 7124  \ncharacters are:   | ; ` \u2018 \u201c  ( ) & $ / \\  * ! \u00a5 \u20a9 7125  \nT&W: CWE -641, CWE -200, CAPEC -116, CAPEC -66, CAPEC -88, TRTB -00063  7126UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 253 of 397 GDFR -30 The CDS should use  generic  Filter API  libraries235 and Filter Controller/Servers236 to 7127  \nimprove interoperability with filters  and simplify new filter integration however there are 7128  \nsome res", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}532{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "531", "chunk": "trictions on how those APIs can be implemented:   7129  \nGDFR -30.1 Two implementations of the Filter API libraries and Filter Controller/Servers  must 7130  \nbe implemented, one each for the outbound and inbound pipelines . 7131  \nT&W: WRTB -00020, WRTB -00077, TRTB -00029, TRTB -00055  7132  \nGDFR -30.2 The results processor and filter report validators implementation s shall not  use the 7133  \nFilter API  and Filter Controller/Servers code . 7134  \nT&W: WRTB -00077, CWE -636, CAPEC -554, TRTB -00055  7135  \nGDFR -30.3 The protocol adapter and the inline metadata filter implementations shall not use the 7136  \nFilter API and Filter Controller/Servers  code.  7137  \nRationale: If all components of the filter pipeline use the same filter API and filter 7138  \ncontroller /server  code then faults in that code could cause a fail open condition 7139  \nthroughout the CDS.  7140  \nT&W: WRTB -00077, CWE -636, CAPEC -554, TRTB -00055  7141  \nGDFR -31 All filters implementing reprogrammable rulesets (e.g., XSLT, Schema tron, scripting 7142  \nlanguage based, custom  language)  must be de signed so that a PASS or PASS WITH 7143  \nCHANGE  must be EXPLICITLY invoked and that the default behavior of all rules 7144  \nengines must be to FAIL the data being transferred.  In other  words, the re", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}533{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "532", "chunk": " must be explicit 7145  \nlogic (e.g., if..then..else  statements) in the rules to  pass the file  and if that logic is 7146  \nnot present the content must fail.  7147  \nRationale:  This prevents two problems with ruleset -based filters: the possibility that 7148  \nruleset will \u201cbottom -out\u201d resulting in an unknown/unclear result and reduces potential 7149  \nconfusion by ruleset creators and assessors on th e results of a filter operation. In other 7150  \nwords, when in doubt a CDS should always assume the content failed filtering.  7151  \nT&W: CWE -636, TRTB -00065  7152  \nGDFR -32 To prevent loss of CDS user data being transferred through the CDS, the CDS should 7153  \nimplement a mechanism as part of the system maintenance and shut  down process es to 7154  \nprevent  new inbound content from being receive d and allow existing received content to 7155  \nbe processed prior to the system shutting down or going into a maintenance mode.  7156  \n \n235 A generic filter API provides a standardized interface for interacting with filters including submitting jobs, \nretrieving filtered content, and terminating a job. It also defines common APIs for filter configuration, for \ndiscovering filter features, and f or reporting filtering results.  \n236 A Filter Controller/Server is a process th", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}534{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "533", "chunk": "at invokes a specific filtering library to perform a specific set of filtering \nactions. It is not a FOE.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 254 of 397 Rationale: This requirement  would allow a CDS to be taken offline for maintenance, 7157  \nupdate, and/or replacement without losing data  that is being processed . This is 7158  \nparticular ly useful for CDS being used as a filtering sidecar to another CDS 7159  \nespecially  when  the sidecar operates on a hypervisor and it is updated by replacing 7160  \nthe Virtual Machine.  It is also a critical capability for enterprise CDS service 7161  \nproviders,  as it would allow for the orderly and reliable transfer of dataflows to 7162  \nanother CDS in the  enterprise.  7163  \nGDFR -32.1 CDS shall generate an audit message once  all content processing queues are empty 7164  \nwhen  the CDS  transitioning  to an offline mode . 7165  \nT&W: CWE -223, CWE -778, TRTB -00037  7166  \nGDFR -33 The CDS should provide a mechanism to clear all content processing queues without 7167  \nrebooting the CDS.  7168  \nGDFR -34 The dataflow ID must be unique and must never ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}535{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "534", "chunk": " be reused within a CDS instance.  7169  \nDataflow IDs can be shared  among a grouping of the same type of CDS.  7170  \nT&W: CWE -223, CWE -694, CAPEC -240, TRTB -00037  7171  \nGDFR -35 The filter policy ID must be unique and must never  be reused within a CDS instance.  7172  \nFilter policy IDs can be shared among a grouping of the same type of CDS.  7173  \nT&W: CWE -223, CWE -694, CAPEC -240, TRTB -00037  7174  \nGDFR -35.1 The CDS should change the filter policy ID for a filter policy if the filter policy  is 7175  \nchanged.  7176  \nT&W: CWE -223, TRTB -00037  7177  \nGDFR -35.2 If the filter policy for the CDS is loaded from an external source (e.g., removable 7178  \nmedia, Guard Remote Management Protocol ) and the filter policy ID is present in that 7179  \nfilter policy then a new filter policy  ID shall not be regenerated  on the CDS.  7180  \nGDFR -36 If a hash or hash-based message authentication code  (HMAC)237 is used to assist in 7181  \nvalidating that content was filtered by a previous filter and the value of the hash or 7182  \nHMAC does not match the data provided then the CDS shall consider that a pipeline 7183  \ncompromise and disable the associated pipeline . 7184  \nT&W: WRTB -00041  , TRTB -00065  7185  \nGDFR -37 If dataflow configuration s (e.g., rulesets, schemas", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}536{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "535", "chunk": " , etc. ) are loaded onto the CDS via 7186  \nan external mechanism or created on the CDS, then they shall be placed in  the 7187  \nappropriate component dataflow  staging directories a nd not in to the operational  dataflow 7188  \ndirectories. Once an administrator has enabled  the new dataflow, it shall be moved from 7189  \n \n237 https://en.wikipedia.org/wiki/HMACUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 255 of 397 the staging directory to the operational directory.  7190  \nT&W: CWE -653, TRTB -00068  7191  \nGDFR -38 A CDS may have the ability to provide redacted filter reports to recipients of low to 7192  \nhigh cross domain transfers, subject to the following:   7193  \nClarification: This redacted filter report is a subset of the full filter report that is 7194  \ngenerated as part of the  filtering process.   7195  \nT&W: CWE -200, CAPEC -116 7196  \nGDFR -38.1 The CDS must have a mechanism to enable and disable this capability 7197  \nindependently for each domain.  7198  \nT&W: CWE -1220, CAPEC -180 7199  \nGDFR -38.2 The ability to enable and disable this capability must be enforced via RBAC.  7200  \n", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}537{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "536", "chunk": "T&W:  WRTB -00072 , CAPEC -180 7201  \nGDFR -38.3 The report must be classified at the level of the recip ient\u2019s network.  7202  \nT&W: CWE -200, TRTB -00042  7203  \nGDFR -38.4 The CDS must have the ability to restrict the information that is placed in the  filter 7204  \nreport being sent to the user. A t minimum it must:  7205  \nGDFR -38.4.1 Remove  any information about the  filtering mechanism s (technologies) used by  7206  \nthe CDS.   7207  \nClarification: The report could state \u201cJPEG Filter\u201d or \u201cMS Office Filter\u201d but not which 7208  \none (e.g., \u201cJPEG Filter 1\u201d is not allowed)  or the specific product used to make the 7209  \nfilter.  This includes removal of the technology used. For example, \u201cxerces -c: Invalid 7210  \ncharacter after root element:\u201d would not be allowed but \u201cxml filter: Invalid character 7211  \nafter root element\u201d would be.  7212  \nT&W:  CWE -200, WRTB -00086 , TRTB -00042  7213  \nGDFR -38.4.2 Remove  any information about the network and domain configuration of the CDS.  7214  \nT&W:  CWE -200, WRTB -0008 6, TRTB -00042  7215  \nGDFR -38.4.3 Be able to configure the  ability to remove dirty words on which the  content failed.  7216  \nT&W:  CWE -200, WRTB -00086 , TRTB -00042  7217  \nGDFR -38.4.4 Be able to configure the ability to restrict which filtering settin", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}538{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "537", "chunk": "gs can  be included 7218  \nin the report . 7219  \nT&W:  CWE -200, WRTB -00086 , TRTB -00042  7220  \nGDFR -38.5 In a low to high transfer,  filter reports shall not be sent to the sender in the sending 7221  \n(i.e., low) domain . 7222UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 256 of 397 GDFR -38.6 In a high to low transfer,  redacted filter  reports , in accordance with the rest of 7223  \nGDFR -38, may be sent to the sender in the sending (i.e., origin) domain . 7224  \nGDFR -39 A CDS shall not use libraries in filters from the same vendor that creates the 7225  \napplication used to create that data type. There is one exception to this requirement, in  7226  \nspecial circumstances the use of a vendor\u2019s library may  be used if it is : the only library in 7227  \nexistence for that data type, there are legal restrictions on creating new librar ies (e.g., 7228  \npatent s), and that data cannot be converted into a normalized form the CDS can handle . 7229  \nThe CDS developer will need to provide documentation to prove that the exception is 7230  \nrequired.  7231  \nClarification:  For example,  an Adobe\u00ae PDF li", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}539{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "538", "chunk": "brary cannot be used in a PDF filter 7232  \nbecause that library is also used to generat e PDF files .  This is  the filtering equivalent 7233  \nof the \u201cfox guarding the hen  house\u201d238 scenario.   7234  \nT&W: CWE -758, TRTB -00061  7235  \nGDFR -40 All antivirus products used within  the CDS must be developed in FVEY nations by a 7236  \ncompany that is located in a FVEY nation and that company must be incorporated in a 7237  \nFVEY nation (e.g., Microsoft\u00ae is considered a USA corporation and is located in 7238  \nRedmon d, Washington) . 7239  \nT&W: CWE -506, CAPEC -438 7240  \nGDFR -41 A protocol adapte r that is part of a filter pipeline shall not accept connections until the 7241  \npipeline processes (e.g., filters) are  running.  7242  \nT&W: CWE -665, CAPEC -125, CAPEC -554 7243  \nGDFR -42 If a protocol adapter implements Google \u00ae Protocol Buffer, Google \u00ae Flat Buffer , or 7244  \nother serialized object  format s then the payload shall be c onverted to a normalized form 7245  \n(e.g., XML) for filtering in the CDS pipeline.  The normalized  version of the serialized 7246  \nobject will be converted back into the serialized  form  after c ompletion of all filtering.  7247  \nRationale:  Many serialized objects formats use specifications that are based on code and 7248  \nnot formal spe", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}540{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "539", "chunk": "cification so validating against a specification is not possible  and thus it 7249  \ncannot be reliably and  safely filtered . Addition ally, a substantial number of serialized 7250  \nobjects do a direct load of the object into memory without parsing  and validating the 7251  \ndata. If an attacker manipulates the payload , it can cause faults in the destination 7252  \napplication  and lead to application compromi se. 7253  \nT&W: CWE -502, CWE -707, CAPEC -586, TRTB -00061, TRTB -00065  7254  \nGDFR -43 CDS that implement filters that modify or transform the data shall either verify via a 7255  \nseparate independent validation filter that the modification/transformation  actions were 7256  \n \n238 https://grammarist.com/usage/fox -guarding -the-hen-houseUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 257 of 397 performed  or implement a second independent modify/transform filter that repeats the 7257  \nmodify/transform function s performed by the first modify/transform filter.  7258  \nT&W: WRTB -00020, WRTB -00077, TRTB -00029, TRTB -00055  7259  \nGDFR -44 The SHA -384 hash, CDS UUID, dataflow ID, customer ID (", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}541{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "540", "chunk": "if supported by the CDS), 7260  \nand filtering result s (failure or succe ss) shall be part of each audit event recorded  for each 7261  \nfile/message processed by the CDS.  The SHA -384 hash is optional for streaming data.  7262  \nRationale:  This information is required by enterprise cross domain service providers that 7263  \nneed to be able to efficiently extract a customer\u2019s audi t events from dozens to 7264  \nhundreds of CDS in their environment.  7265  \nT&W:  CWE -778, CWE -223, TRTB -00037  7266  \nGDFR -45 Filters and Protocol Adapters shall not execute filtering  or 7267  \nnormalization/denormalization processes using  system() or popen() system calls.  7268  \nRationale: The use of system()  and popen() increases the risk of command  7269  \ninjection attacks239 and it substantial ly increase s the complexity of the SECCOMP 7270  \npolicy. Filters and Pas are the highest risk processes on the system. Allowing them to 7271  \nexecute other programs increases the options an adversary has at their disposa l to 7272  \ncompromise the system.  Pas and filters are allowed to fork()/exec() copies of 7273  \nthemselves  7274  \nT&W:  CWE -78, CWE -676, CAPEC -88 7275  \nGDFR -45.1 If the exec()  family is used to create child process es, the contents of the string 7276  \ncontaining the ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}542{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "541", "chunk": "file path and executable shall  not contain any data from content being  7277  \nprocessed by  the process  and the file path shall be an absolute file path (e.g., prefixed 7278  \nwith a \u201c/\u201d).  7279  \nT&W: CWE -23, CWE -676, CWE -78, CAPEC -139, CAPEC -88 7280  \nGDFR -46 Deleted. Merged with GDFR -31. 7281  \nGDFR -46.1 Deleted. Merged with GDFR -31. 7282  \nGDFR -47 A filter , including  parsers and ruleset engine s, shall shutdown  if its configuration  files 7283  \nand rulesets/schemas  are not present  or not readable.  7284  \nT&W: CWE -455, TRTB -00040  7285  \nGDFR -48 In a PDC architecture, the filter configuration and network information for the high 7286  \nside of the system shall not exist on the low side of the system.  7287  \nT&W: CWE -653, CAPEC -116 7288  \n \n239 https://owasp.org/www -community/attacks/Command_InjectionUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 258 of 397 GDFR -49 Dataflow compone nts shall only have access to the active approved  configuration s for 7289  \nthat instance of the components.  7290  \nClarification:  This applies to protocol adapters, filters, and domain routers. ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}543{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "542", "chunk": " 7291  \n 7292  \n11.2 General XML and Fixed Format Processing Requirements  (GXFFPR)  7293  \nThis section describes the requirements for XML and Fixed Format filtering in a CDS . This 7294  \nsection only applies to CDS that are processing fixed format or XML data.  7295  \nGXFFPR -1 The CDS shall have the ability to validate XML data using XML Schema 7296  \nValidation . 7297  \nGXFFPR -2 The CDS shall have the ability to transform and sanitize XML .  7298  \nGXFFPR -2.1 The CDS shall implement a mechanism to canonicalize XML to remove inter - 7299  \nelement and inter -attribute whitespace.  7300  \n GXFFPR -2.2  The CDS shall implement a mechanism to remove XML comments , XML  7301  \nprocessing instruction s, and unused namespace s or shall implement a mechanism to fail 7302  \nXML files with them.  7303  \nGXFFPR -2.3  The CDS shall implement a mechanism to rewrite XML namespace prefixes into 7304  \na defined structure to prevent using namespace prefixes to exfiltra te data.  7305  \nGXFFPR -2.4  The CDS shall fail XML files with external entities  (e.g., <!ENTITY) or remove 7306  \nthe external entity references from the XML content.  7307  \nGXFFPR -2.5  XML Document Type Definitions (DTD ) shall not be used for validating XML 7308  \ncontent.  7309  \nGXFFPR -3 The CDS should  have the a", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}544{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "543", "chunk": "bility to validate XML data using Schematron .  7310  \nRationale:  Schematron  is particular ly useful for co-constraint validation and complex if - 7311  \nthen-else logic.  7312  \nGXFFPR -4 The CDS should have the ability to validate, transform, and sanitize XML using 7313  \ncustom filters  (e.g., a Java\u00ae  class that does bounding box calculations for an object that 7314  \nis inside or outside of a polygon of coordinates ). 7315  \nGXFFPR -5 The CDS should  implement the capability  to normalize  (e.g., parse) fixed format 7316  \ndata from its original text or binary forms into XML for content validation and 7317  \nsanitization . 7318  \nGXFFPR -6 The CDS should  implement the capability to denormalize (e.g., 258ystem 258d) 7319  \nXML data derived from fixed format data, subject to any sanitization action s performed,  7320  \nback into the original text or binary forms . 7321  \nGXFFPR -7 The CDS should implement a Data Format Description Language (DFDL) parser  7322UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 259 of 397 and unparser to support normalization/denormalization of fixed format text and binary 7", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}545{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "544", "chunk": "323  \ndata into/out of XML.  7324  \nGXFFPR -7.1 The CDS should support \u201c Data Format Description Lan guage (DFDL) v1.0  7325  \nSpecification\u201d, GFD -P-R.240, October 2020, Open Grid Forum  or higher.240 7326  \nGXFFPR -8 The CDS shall implement at least two independent and redundant XML filters that 7327  \nsupport validation of XML content using XML Schemas . 7328  \nGXFFPR -9 The CDS should implement a filter that uses XML Stylesheet Language 7329  \nTransformations (XSLT) to sanitize XML content . 7330  \nGXFFPR -10 The CDS shall  implement a filter to validate  via XML Schema or Schematron all 7331  \nsanitization actions  performed . 7332  \nGXFFPR -11 The CDS shall implement  a filter  to canonicalize  XML content  and implement  the 7333  \nNamespace recommendations in the NCDSMO document Basic XML Security 7334  \nConsiderations  (NCDSMO Doc ID : NCDSMO -G-00002 -001_00 ). 7335  \nGXFFPR -12 CDS support for XML standards :  7336  \nGXFFPR -12.1 The CDS shall implement \u201c Extensible Markup Language (XML) 1.0 (Fifth 7337  \nEdition) \u201d, 26 November 2008 . 7338  \nGXFFPR -12.2 The CDS  should implement \u201c W3C Extensible Markup Language (XML) 1.1 7339  \n(Second Edition) \u201d specification dated 16 August 2006, edited in place 29 September 7340  \n2006 . 7341  \nGXFFPR -12.3 The CDS shall implement", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}546{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "545", "chunk": " \u201c XML Schema Part 0: Primer Second Edition \u201d, 28 7342  \nOctober 2004 . 7343  \nGXFFPR -12.4 The CDS shall implement \u201c XML Schema Part 1: Structures Second Edition \u201d, 28 7344  \nOctober 2004 . 7345  \nGXFFPR -12.5 The CDS shall implement \u201c XML Schema Part 2: Datatypes Second Edition \u201d, 28 7346  \nOctober 2004 . 7347  \nGXFFPR -12.6 The CDS should implement \u201c W3C XML Schema Definition Language (XSD) 7348  \n1.1 Part 1: Structures \u201d and \u201c W3C XML Schema Definition Language (XSD) 1.1 Part 2: 7349  \nDatatypes \u201d, both dated  5 April 2012 . 7350  \nGXFFPR -12.7 The CDS shall implement \u201cW3C XSL Transformations (XSLT)\u201d, Version 1.0 , 7351  \n16 November 199 9. 7352  \nGXFFPR -12.8 The CDS shall implement \u201c W3C XML Path Language (X path)\u201d, Version 1.0 , 16 7353  \nNovember 1999 (Status updated October 2016) . 7354  \nGXFFPR -12.9 The CDS should implement \u201c W3C XSL  Transformations  (XSLT) \u201d Version  2.0, 7355  \n \n240 https://github.com/OpenGridForum/DFDL  and https://github.com/DFDLSchemasUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 260 of 397 23 January 2007 . 7356  \nGXFFPR -12.10 The CDS should implement  \u201cW3C  XML Path La", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}547{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "546", "chunk": "nguage (X path) 2.0 (Second 7357  \nEdition) \u201d, 14 December 2010 (Link errors corrected 3 January 2011; Status updated 7358  \nOctober 2016) . 7359  \nGXFFPR -12.11 The CDS shall  implement \u201cInformation Technology , Document Schema 7360  \nDefinition Languages (DSDL), Part 3: Rule -based validation, Schematron (ISO/IEC 7361  \n19757 -3:2016) \u201d, Second Edition . 7362  \nGXFFPR -12.12 The CDS should implement \u201cW3C XML Signature Syntax and Processing 7363  \nVersion 1.1\u201d, 11 April 2013 . 7364  \nGXFFPR -12.13 The CDS should implement \u201cW3C XML Encryption Syntax and Processing 7365  \nVersion 1.1 \u201d, 11 April 2013 . 7366  \nGXFFPR -12.14 The CDS shall implement \u201cW3C Canonical XML 1.1 \u201d, 2 May 2008 . 7367  \nGXFFPR -12.15 The CD S shall implement an XML signature validation mechanism for 7368  \nvalidating digitally -signed XML content as part of dataflow  filtering  and for validating 7369  \ndigitally -signed dataflow  policies . 7370  \n11.3 Military Messaging Fixed Format Data Filtering  and Protocol  7371  \nRequirement s (MMFFR)  7372  \nThis section describes the requirements for filtering fixed format data with a specific emphasis 7373  \non the filtering of USG military data formats.  This section only applies to CDS that are 7374  \nprocessing fixed format USG militar y data formats.  Mission r", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}548{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "547", "chunk": "equirements will determine which  7375  \nUSG military data formats are required to be supported by the CDS.  CDS developers may be 7376  \nrequired by their USG customer to support MIL -STD interoperability testing for the CDS at the 7377  \nJoint Interoper ability Test Command (JITC) testing facilities.  If generic parsing capabilities, like 7378  \nDFDL,   7379  \nMMFFR -1 [DCCDS -FF, TCDS] The CDS  shall support  filtering  of Tactical Data Link ( TDL ) 7380  \n16 Message Standard , as defined in MIL-STD -6016 F Change 1, effective 31 Aug 2017 . 7381  \nMMFFR -1.1 Deleted . 7382  \nMMFFR -2 [DCCDS -FF, TCDS] The CDS shall have the ability to transmit and receive TDL 7383  \nmessages using the Joint Range Extension Applications Protocol  (JREAP) C, as defined 7384  \nin MIL-STD 3011 and NATO Standardization Agreement (STANAG)  5518  via the 7385  \nInternet Protocol version of JREAP ; other versions of JREAP may be supported by the 7386  \nCDS . 7387  \nMMFFR -2.1 [DCCDS -FF, TCDS] The CDS should have the ability to support alternate 7388  \ntransport protocols (e.g., SIMPLE) for TDL messages . 7389  \nMMFFR -3 [DCCDS -FF, TCDS] The CDS shall support filtering of  United States Message Text 7390  \nFormat (USMTF)  messages, as defined in MIL -STD 6040 . 7391UNCLASSIFIED//FOR OFFICI AL USE ONL", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}549{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "548", "chunk": "Y//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 261 of 397 MMFFR -3.1 Deleted.  7392  \nMMFFR -4 [DCCDS -FF, TCDS] The CDS shall support filtering of Variable Message Format 7393  \n(VMF) mess ages, as defined in MIL -STD 6017 . 7394  \nMMFFR -4.1 Deleted.  7395  \nMMFFR -5 [DCCDS -FF, TCDS] The CDS shall support the filtering of geographic, source, 7396  \nmessage type, message content, threat classification/identity and exercise241 data 7397  \nMMFFR -6 [DCCDS -FF, TCDS] The CDS shall  have the ability to parse  fixed format ASCII, 7398  \nUnicode, and Binary data to XML . 7399  \nMMFFR -7 [DCCDS -FF, TCDS] The CDS shall have the ability to unparse XML data into 7400  \nFixed Format ASCI I, Unicode, and Binary data after filtering rules have been applied . 7401  \nMMFFR -8 [DCCDS -FF, TCDS] CDS shall have  the ability to reject messages  (i.e., an 7402  \nexclusion filter)  that are not within  defined closed polygon geographic regions  including 7403  \nabove or be low a defined altitude . 7404  \nMMFFR -9 [DCCDS -FF, TCDS] CDS shall have the ability to accept  messages  (e.g., an 7405  \ninclusion filter)  that are within a defined closed polygon geogr", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}550{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "549", "chunk": "aphic regions  including 7406  \nabove or below a defin ed altitude . 7407  \nMMFFR -10 [DCCDS -FF, TCDS] CDS shall have the ability to apply at least six  combinations 7408  \nof exclusion and inclusion geographic filters on each dataflow  supported by the CDS.  7409  \nMMFFR -11 [DCCDS -FF, TCDS] The CDS should support Source Identification Code Filtering  7410  \nfor TDL messages . 7411  \nMMFFR -11.1 [DCCDS -FF, TCDS] The CDS shall have the ability to perform filtering based on 7412  \nidentification of a sensor ( e.g., ATC radar that provides non -TDL formatted messages) 7413  \nand sources that are specifically assigned TDL source identification codes ( e.g., JTIDS 7414  \nUnit Number [JU]). Platforms that participate in Tactical Data Links are assigned and 7415  \nidentified by a unique (two -, thre e-, or five-digit) number.  7416  \nMMFFR -11.2 [DCCDS -FF, TCDS] Source  Identification Code shall  include two checks (tables) 7417  \nto determine transfer between security domains: (1) Source Authorized Table, and (2) 7418  \nSource Not Authorized Table. Tables can contain source identification codes, ranges, and 7419  \nregular expressions. Each track must pass two source t able tests to transfer across security 7420  \ndomains:  7421  \nMMFFR -11.2.1 [DCCDS -FF, TCDS] Test 1 \u2013 the Source", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}551{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "550", "chunk": " Identification C ode must not be 7422  \nentered in the Source Not Authorized Table. If it passes t his test, then it must pass the 7423  \nsecond test.  7424  \n \n241 Exercise data is defined as messages that have been created explicitly to support military or in telligence \ncommunity exercises.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 262 of 397 MMFFR -11.2.2 [DCCDS -FF, TCDS] Test 2 \u2013 the Source Identification Code is checked as 7425  \nbeing listed in the Source Authorized Table.  7426  \nMMFFR -12 [DCCDS -FF, TCDS] The CDS shall  be able to filter (delete, modify or zeroize242 a 7427  \nspecific value/data field) the content of each individual  data elements of each specific 7428  \nmessage.   7429  \nMMFFR -12.1 [DCCDS -FF, TCDS] Content  filtering shall include  the implement ation of  co- 7430  \nconstraints checks and if -then-else logic on sets of data elements.  7431  \nMMFFR -13 [DCCDS -FF, TCDS] The CDS shall  be able to read the Identity Code ( e.g., Friend, 7432  \nSuspect, Hostile, etc.) associated with each track and track update message and determine  7433  \nif it can be  transfer red across se", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}552{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "551", "chunk": "curity domains.  7434  \nMMFFR -14 [DCCDS -FF, TCDS] The CDS shall be able to differentiate between Rea l, Exercise 7435  \nand Simulation tracks to allow selective distribution of track data in support of training 7436  \nand exercises to select lower domains and/or the higher domain s thereby reducing 7437  \npotential negative impacts on current operations.  7438  \nMMFFR -15 [DCCDS -FF, TCDS] The CDS shall  be able to identify track management lines 7439  \n(e.g., drop track) and support transfer across security domains in order to minimize the 7440  \nrequirements for operator intervention/actions  and to maintain a cohere nt 7441  \ndatabase/picture in multiple domains simultaneously.  7442  \n11.4 Modular  Pipeline  Component  Requirements ( MPCR) 7443  \nThis section replaces the Modular Filtration  Requirements (MFR) section in the 2018 RTB 7444  \nrequirements document. Modular Pipeline Components  (MPC) is a technique to reduce the 7445  \ncoupling of filters and protocol adapters  with the rest of the CDS software. It can be used as a 7446  \nmethod  to support reusable filters and protocol a dapters that are evaluated after the CDS goes 7447  \nthrough the LBSA  process , facilitate  easier updates and patches to CDS pipeline components , 7448  \nand potentially reduce certificatio", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}553{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "552", "chunk": "n test time for new filters and protocol adapters .  7449  \nThe use of modular pipeline components is optional, but if done must meet these requirements.  7450  \nMPCR -1 [~*/HB, ~*/CCOTS] The use of a Modular Pipeline Component  Architecture in a CDS 7451  \nshall  not alleviate the requirement to use an acceptable design pattern.  7452  \nMPCR -2 [~*/HB, ~*/CCOTS] The installation of modular components  onto a host CDS system 7453  \nshall be implemented  in a standardized way across all installations of modular 7454  \ncomponents  on that host system  and shall conform with the application installation and 7455  \npackaging guidance found within this document to include revisioning standards.  7456  \n \n242 Zeroize includes writing zeros, nulls, spaces or similar data into the data element depending on what is \npermissible in the data format specification to indicate the field has been cleared.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 263 of 397 T&W:  WRTB -00093, TRTB -00050  7457  \nMPCR -2.1 [~*/HB, ~*/CCOTS]  An MPC shall not be installed if all dependencies are not met . 7458  \nT&W:  WRTB -00052, WRTB ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}554{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "553", "chunk": "-00065, WRTB -00079, CAPEC -554, TRTB -00069  7459  \nMPCR -2.2 [~*/HB, ~*/CCOTS] The CDS developer shall implement a packaging format and 7460  \ninstallation mechanism to support installing MPCs that ensures tha t no scripts, non-MPC 7461  \nexecutables, or operating system packages (e.g., rpms) are installed or run  during the 7462  \ninstallation process. The installation mechanism includes updating all integrity 7463  \nmonitoring and software registration databases on the CDS.  7464  \nClarification : This requirement is only required for CDS implementing CDMPC. It does 7465  \nnot apply to CDS vendor MPCs  which can use the operating system installer.  7466  \nRationale:  This prevents the customer  MPCs  (see CDMPCR section) from being able to 7467  \nuse the insta llation process to potential ly run programs or scripts with privilege in an 7468  \nattempt to alter the security of the CDS platform. For both CDS developer and 7469  \ncustomer MPCs this help s enforce isolation of the MPC from the host operating 7470  \nsystems.  7471  \nMPCR -3 [~*/HB, ~*/CCOTS]  The host CDS system shall isolate a MPC  from the file system of 7472  \nthe h ost via MAC policy.  7473  \nT&W:  CWE -653, WRTB -00091, CAPEC -165, CAPEC -180, TRTB -00005, TRTB - 7474  \n00006  7475  \nMPCR -4 [~*/HB, ~*/CCOTS] ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}555{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "554", "chunk": " The MPC  implementation  shall  not allow any modular 7476  \ncomponent  to access any resource associated with another modular component  except for 7477  \nIPCs necessary to transfer data.   7478  \nClarification:  The purpose of this requirement is to limit the interaction and 7479  \ndependencies b etween MPCs.  MPC should use IPC s to exchange data with other 7480  \nMPCs.  A portion of the temp file system maybe shared between two MPC but only 7481  \nfor the purposes of implementing a n IPC. 7482  \nT&W:  CWE -653, CWE -668, CAPEC -180, TRTB -00005, TRTB -00006  7483  \nMPCR -5 [~*/HB, ~*/CCOTS] The installation locations for all dependencies within a MPC  7484  \nshall be standardized across all MPC s. This facilitates the consistent usage and evaluation 7485  \nof security policy implementation.  7486  \nClarification: The standardization of installation locations within the CDS\u2019 MPC 7487  \ninfrastructure is also intended to enable efficien t Modular Pipeline Component 7488  \nTesting.  7489  \nT&W:  CWE -284, CWE -668, CAPEC -122, CAPEC -180 7490  \nMPCR -6 [~*/HB, ~*/CCOTS] Software infrastructures used for communications, data transfer, 7491  \nand component  management, located within an MPC , shall be standardized across all 7492UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, A", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}556{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "555", "chunk": "RE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 264 of 397 modular components  of the same class  (e.g., filters, protocol adapters) used within a 7493  \nspecific CDS . 7494  \nClarification: The standardization of software infrastructures within the CDS\u2019 MPC 7495  \ninfrastructure is also intended to enable efficient Modular Pipeline Component 7496  \nTesting.  7497  \nMPCR -7 [~*/HB, ~*/CCOTS] The MPC  implementation  shall restrict all modular component  7498  \ncommunications to a standard ized communications interface s/protocol s into and out of 7499  \nthe module to facilitate movement of data and metadata between the host and the modular 7500  \ncomponent .  7501  \nClarification: This includes command/control, content ingress /egress , policy, 7502  \nconfiguration, and JAL information.  Different classe s (e.g. , filters, protocol adapters) 7503  \nof MPC can use different communications interfaces/protocols.  The e xternally facing 7504  \nside of protocol adapters are not impacted by this requirement.  The standardization of 7505  \ninterfaces and protocols within the CDS\u2019 MPC inf rastructure is also intended to 7506  \nenable efficient Modular Pipeline Compo", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}557{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "556", "chunk": "nent Testing.  7507  \nT&W: CWE -20, CWE -424, CWE -1242, CAPEC -36, CAPEC -153, CAPEC -554 7508  \nMPCR -7.1 [~*/HB, ~*/CCOTS] When placed directly in a linear pipeline, s eparate 7509  \ncommunicat ion interfaces shall be used for sending and receiving  content (and associated 7510  \nmetadata) into/out of a modular component .  7511  \nClarification:  This is similar to the approach  used for separate IPCs for sending and 7512  \nreceiving data int o/out of component s in a pipeline . 7513  \nT&W: CWE -424, WRTB -00092, CAPEC -554, TRTB -00021  7514  \nMPCR -7.2 [~*/HB, ~*/CCOTS] The CDS shall use a separate dedicated host process for each 7515  \nmodular component . 7516  \nClarification:  MPCs  can be  multi-threaded , multi -process, or both . A process within a 7517  \ncontainer can spawn copies to support parallel operation.  7518  \nT&W: CWE -653, WRTB -00088, CAPEC -234, CAPEC -554 7519  \nMPCR -8 [~*/HB, ~*/CCOTS]  The modular component  implementations  shall  be based on 7520  \nOpen Container Initiative  (OCI)243 image  (v1.0.2 or higher) , runtime  (v1.0.2 or higher) , 7521  \nand distribution (v1.0.1 or higher) specification s. 7522  \nMPCR -9 [~*/HB, ~*/CCOTS] Contain er orchestration frameworks (e.g.,  Kubernetes \u00ae) shall 7523  \nnot be used to manage or install modular componen", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}558{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "557", "chunk": "ts  on a CDS  due to potential security 7524  \nrisks a ssociated with these frameworks.  7525  \nRationale: Many container orchestration frameworks have bidirectional  communications 7526  \n \n243 See https://www.opencontainer s.orgUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 265 of 397 into the running container. These communications, usually file system and socket, 7527  \npotentially provide a way for a compromised container to attack the rest of the CDS  7528  \ncontainer s via the framework  and thus provide a way to bypass the filtering pipeline.  7529  \nT&W: CWE -653, WRTB -00020, CAPEC -180, TRTB -00021  7530  \nMPCR -10 [~*/HB, ~*/CCOTS] MPC  containers shall  be used to contain  only a single filter or 7531  \nprotocol adapter.  7532  \nClarification:  Containers shall perform a single core function (e.g., implementing UDP 7533  \nprotocol adapter, perform XML validation against a schema, normalizing a compress 7534  \nimage into a raw bitmap).  7535  \nRationale:  The two primary uses of containers on CDS are to improve the distribution 7536  \nand installation of pipeline components and to simplify the p", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}559{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "558", "chunk": "rocess isolation between 7537  \ncomponents in a pipeline to increase the adversary cost of lateral movement through 7538  \nthe CDS.  7539  \nMPCR-11 [~*/HB, ~*/CCOTS] MPC  implementations shall  provide a standardized test harness 7540  \ncapable of  externally (to the CDS)  testing all modular  components  to be used in the CDS 7541  \nsystem.  The harness may use different software to interface with MPCs of different 7542  \nclasses (e.g. , filters, protocol adapters).  7543  \nClarification : This test harness will be provided to the LBSA lab to support testing of 7544  \nthe CDS and to support Modular Pipeline Component Testing (MPCT). It may also 7545  \nbe provided  to customers to support testing of their modular pipeline component s. 7546  \nMPCR -12 [~*/HB, ~*/CCOTS] MPC  implementations shall  provide a standardized test harness 7547  \ncapable of simulating  the host side of t he MPC  interface.  The harness m ay use di fferent 7548  \nsoftware to interface with MPCs of different classes (e.g. , filters, protocol adapters).  7549  \nMPCR -13 [~*/HB, ~*/CCOTS] MPC  implementation s shall provide a mechanism to start and 7550  \nstop execution  of modular components . 7551  \nMPCR -14 [~*/HB, ~*/CCOTS] MPC  implementations  shall be capable of sending alerts to  the 7552  \nhost in th", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}560{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "559", "chunk": "e event of  component  failure, component error conditions, and component 7553  \nrecovery  (if restarted by the host) . 7554  \n Clarification:  The EM/PE subsystem can be used to restart components.  7555  \nT&W: CWE -778, WRTB -00085, CAPEC -28, CAPEC -125, TRTB -00064  7556  \nMPCR -15 [~*/HB, ~*/CCOTS] MPC  shall have their system clocks and time  zone synchronized 7557  \nwith the clocks of the host. 7558  \nT&W: WRTB -00032, TRTB -00015  7559  \nMPCR -16 [~*/HB, ~*/CCOTS] MPC  implementations  shall have the ability to restrict  system 7560  \nresources to only those required by the component  to operate . This includes file system 7561  \naccess and  IPC mechanisms capability.  7562UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 266 of 397 T&W:  CWE -250, CWE -653, CAPEC -234, TRTB -00001  7563  \nMPCR -16.1 [~*/HB, ~*/CCOTS] On Linux \u00ae systems, namespaces shall  be used to enforce 7564  \nthese restrictions.  7565  \nMPCR -17 [~*/HB, ~* /CCOTS] MPC  implementations  shall  make use of  operating system 7566  \nprovide d capabilit ies (e.g., Linux\u00ae  control group s) to limit the amount of system 7567  \nresources ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}561{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "560", "chunk": "(e.g., CPU time, system memory, network bandwidth ) used by a modular 7568  \ncomponent . 7569  \nT&W:  CWE -770, CAPEC -130 7570  \nMPCR -18 Deleted . 7571  \nMPCR -19 Deleted . 7572  \nMPCR -20 [~*/HB, ~*/CCOTS]  Communications processes  used by modular components  to 7573  \ncommunicate outside of the container  shall  run with different MAC and DAC constructs  7574  \nthan the other processes in the container. This is to protect the module\u2019s communications 7575  \ninterface from internal modular component  processes.  7576  \nClarification: For Linux systems, SELinux modular policy can be used t o address the 7577  \nMAC portion of this requirement.  7578  \nT&W:  CWE -653, WRTB -00090, CAPEC -180, TRTB -00021, TRTB -00065  7579  \nMPCR -21 [~*/HB, ~*/CCOTS] MPC  implementations  shall make use of system call filter ing 7580  \n(e.g., SECCOMP on Linux \u00ae) to block  unnecessary system call usage  by modular 7581  \ncomponents . 7582  \nClarification:  Podman  can be used to enable SECCOMP  policy  for containers instead of 7583  \nsystemd . 7584  \nT&W:  WRTB -00007, CAPEC -234 7585  \nMPCR -22 [~*/HB, ~*/CCOTS] Modular Filters shall not have any external  network access. All 7586  \nnetwork ing access must be internal to the host (e.g., loopback through the operating 7587  \nsystem kernel) . 758", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}562{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "561", "chunk": "8  \nT&W:  WRTB -00025, TRTB -00034  7589  \nMPCR -22.1 [~*/HB, ~*/CCOTS] On Linux\u00ae systems, unique network namespaces shall be 7590  \nused to confine network access to the MPC . 7591  \nT&W:  CWE -653, WRTB -00025, TRTB -00002, TRTB -00034  7592  \nMPCR -23 [~*/HB, ~*/CCOTS] Modular components  must be monitored by the system integrity 7593  \nmonitoring subsystem of the host system.  7594  \nT&W: WRTB -00041, CAPEC -165, CAPEC -176, CAPEC -184, CAPEC -75 7595  \nMPCR -24 [~*/HB, ~*/CCOTS] MPC implementations  should allow for the use of additional or 7596  \nupdated MPC without the need to recompile the host\u2019s evaluated MAC policy.  7597UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 267 of 397 MPCR -25 [~*/HB, ~*/CCOTS] MPC  implementations  shall ensure that the root filesystem of 7598  \neach MPC  is independent from both the host and other modular components . 7599  \nT&W: WRTB -00074, CAPEC -180, TRTB -00006, TRTB -00065  7600  \nMPCR -25.1 Deleted. Not necessary due to OCI Requirements.  7601  \nMPCR -25.2 [~*/HB, ~*/CCOTS]  MPC shall not contain any applications, libraries, binaries , or 7602  \nother files that", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}563{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "562", "chunk": " are not required for the component to operate . 7603  \nRationale:  These extra files  increase the potential attack surface  of the MPC and give the 7604  \nattacker additional tools to further exploit the CDS.  7605  \nT&W: CWE -284, WRTB -00005, CAPEC -122, CAPEC -175 7606  \nMPCR -26 [~*/HB, ~*/CCOTS] MPC  shall make use of a minimal rootfs containing only the 7607  \nnecessary libraries or binaries for operation  of the filter . 7608  \nT&W: CWE -284, WRTB -00005, CAPEC -122, CAPEC -175 7609  \nMPCR -27 [~*/HB, ~*/CCOTS] MPC  shall  be stateless (between restarts) and t hus always start 7610  \nin a known good state.  7611  \nT&W: CWE -459, CWE -665, CWE -732, CAPEC -176, CAPEC -263, CAPEC -37, 7612  \nCAPEC -642 7613  \nMPCR -28 [~*/HB, ~*/CCOTS] Linux -based CDS that are using containers should  comply with 7614  \nthe NIST document Security Assurance Requirements for Linux\u00ae  Application Container 7615  \nDeployment ( NISTIR 8176 )244. 7616  \nMPCR -29 [~*/HB, ~*/CCOTS]  MPC may contain multiple processes and those processes may 7617  \ncommunicate internally within  the MPC using an IPC (e.g. , sockets) . 7618  \nClarification:  For example, if an MPC is implementing an Antivirus  filter and that A/V 7619  \nfilter uses a 3rd party A/V engine that communicates with the A/V filter via TCP", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}564{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "563", "chunk": "/IP 7620  \nsockets, then both processes can be installed in the same container and they can 7621  \ncommunicate over a n IPC. 7622  \nMPCR -30 [~*/HB, ~*/CCOTS]  MPC shall  be compiled against the same  major version of the 7623  \noperating system as the CDS.  7624  \n Clarification:  For example, is the CDS running Red Hat Enterprise Liunx 7.9 then the 7625  \nMPC must be compiled  for Red Hat Linux 7. If the major version of the operating system 7626  \nchanges (e.g., RHEL 7 t o RHEL 8) then the MPC must be recompiled. The CDS vendor 7627  \nmay require recompiles for operating system point revisions if there is any changes (e.g., 7628  \na kernel update) that could cause a potential security issue (e.g., with SECCOMP) . 7629  \nRationale: Compil ing security critical software against a different kernel image or base 7630  \n \n244 https://csrc.nist.gov/publications/detail/nistir/8176/finalUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 268 of 397 operating system  image increase s the likelihood of compatibility and security 7631  \nproblems. For example, SECCOMP is tied to a specific OS kernel version and CPU 7632 ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}565{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "564", "chunk": " \narchitecture.  7633  \nT&W: CWE -474, CA PEC-212 7634  \nMPCR -31 [~*/HB, ~*/CCOTS]  MPC shall use  the same version of the operating system as the 7635  \nCDS.  7636  \nRationale: Compiled security critical software against a different kernel image or base 7637  \nOS images increase the likelihood of compatibili ty and security problems. For 7638  \nexample, SECCOMP is tied to a specific OS kernel version and CPU architecture.  7639  \nT&W: CWE -474, CAPEC -212 7640  \nMPCR -32 [~*/HB, ~*/CCOTS] No process within an MPC shall run as root. Capabilities or 7641  \nprivileges may be granted to processes within an MPC only when necessar y and removed 7642  \nwhen no longer needed.  7643  \nRationale:  There is no operational requirement to run filters or P As as root , regardless if 7644  \nin a container or not. Linux Capabilities resolve the sole reason P As need root (bind 7645  \nto ports less than 1024). A compromise of a process running as root puts the entire 7646  \nsystem at risk.  7647  \nT&W: CWE -250, CWE -272, CWE -286, CAPEC -234, TRTB -00037  7648  \nMPCR -33 [~*/HB, ~*/CCOTS] User and group IDs used within the MPC shall be separate from 7649  \nthose used by the host and other MPCs used in  other pipelines.  7650  \nT&W:  CWE -284, CWE -668, CAPEC -122, CAPEC -180, CAPEC -216 7651  ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}566{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "565", "chunk": "\nMPCR -33.1 [~*/HB, ~*/CCOTS] On Linux \u00ae systems,  user namespaces shall be used to map  7652  \ndifferent individual UIDs and GIDs for each MPC.  7653  \nMPCR -33.2 [~*/HB, ~*/CCOTS] Only the minimum necessary UIDs and GIDs for the MPC to 7654  \noperate shall be mapped into each MPC . 7655  \nMPCR -33.3 [~*/HB, ~*/CCOTS]  The UID 0 and GID 0 of the host shall not be mapped into an 7656  \nMPC \u2019s user namespace . 7657  \nMPCR -34 [~*/HB, ~*/CCOTS] Server -model container engines (e.g., Docker \u00ae, Kubernetes \u00ae) 7658  \nthat use controlling daemons shall not be used.  7659  \nRationale:  The daemons of such engines are a security risk. They can be used for 7660  \nprivilege escalation, as they accept commands over a socket which may be issued by 7661  \na less privileged client. Server -model container engines also interfere with auditing, 7662  \nas the actions taken in managing the containers are performed by the daemon and not 7663  \nthe user or processes responsible for issuing the command.  7664  \nT&W:  CWE -15, CWE -223, CAPEC -69, TRTB -00037  7665  \nMPCR -35 [~*/HB, ~*/CCOTS] Containers shall not include their own c opies of operating 7666UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}567{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "566", "chunk": "REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 269 of 397 system libraries however the container may include a newer version of a n operating 7667  \nsystem library but only if it addresses specific security issues (not address ed in the 7668  \noperating system version) or provides additional required functiona lity. 7669  \nClarification:  The CDS should bind mount only the  required  operating system libraries 7670  \ninto the container.  7671  \nRationale:  Patching of systems has long been a problem with operating systems and 7672  \nCDS. Using the operating system provided libraries to the grea test extent possible 7673  \nreduces the likelihood of a developer failing to patch embedded libraries within the 7674  \ncontainer.  7675  \nT&W:  WRTB -00022, CAPEC -69, CAPEC -310 7676  \nMPCR -35.1 If multiple containers are using the same library and that library is not part of the 7677  \noperating system, then the CDS developer shall install the common library in the base 7678  \noperating system  so that it can be patch ed once instead of n number of times.  7679  \nT&W:  WRTB -00022, CAPEC -69, CAPEC -310 7680  \nMPCR -36 [~*/HB, ~*/CCOTS] When  a MPC is updated , the CDS  Developer  shall ensure that 7681  \nany included binaries and libraries are also updated ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}568{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "567", "chunk": " to a supported patch ed version.  7682  \nT&W:  WRTB -00022, CAPEC -69, CAPEC -310 7683  \nMPCR -37 [~*/HB, ~*/CCOTS] Customer developed containers are not allowed to be installed 7684  \non a CDS unless they have complete d NCDSMO Modular Pipeline Component Testing.  7685  \nMPCR -38 [~*/HB, ~*/CCOTS] If the CDS has local on -box administration tools, then the CDS 7686  \ndeveloper shall implement an API for MPCs to load configuration panels and supporting 7687  \nmodules into the CDS developer\u2019s local on -box CDS administration tools system so that 7688  \nthey can be used to configure policies for the MPCs. This includes implementation of 7689  \nappropriate RBAC requirements for PA and filter configuration and audit event 7690  \nregistration.  7691  \nMPCR -39 [~*/HB, ~*/CCOTS] If the CDS has a remote management sy stem, then the CDS 7692  \ndeveloper shall implement an API for MPCs to load configuration panels and supporting 7693  \nmodules into the CDS developer\u2019s remote management system so that they can be used to 7694  \nconfigure policies for the MPCs.  7695  \nClarification:  This includes im plementation of appropriate RBAC requirements for PA 7696  \nand filter configuration and audit event registration.  7697  \nMPCR -40 [~*/HB, ~*/CCOTS] The CD S developer shall provide a mechan", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}569{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "568", "chunk": "ism for the MPC 7698  \ndeveloper to register MPC specific events that would be sent by the CALD to the EM/PE 7699  \nsubsystem for processing.   7700  \nMPCR -41 [~*/HB, ~*/CCOTS] The CDS developer shall ensure that C3R relevant reporting 7701  \ninformation is also gathered and reported for customer developed and installed MPCs.  7702UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 270 of 397 MPCR -42 [~*/HB, ~*/CCOTS] The CDS developer shall implement an MPC configuration 7703  \nloading API for the MPC to find and load its configuration.  7704  \nMPCR -43 [~*/HB, ~*/CCOTS] The CDS developer shall implement a n API or similar 7705  \nmechanism for protocol adapter MPC administration tool components to be able to 7706  \nupdate the firewall configuration for a PA to properly function.  7707  \n11.5 Customer Developed Modular Pipeline Components Requirements 7708  \n(CDMPCR)  7709  \nThis section provides the security requirements for the implementation of customer developed 7710  \nmodular pipeline components  and includes requirements for the CDS developer and the customer 7711  \ndeveloping the modular pipeline compon", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}570{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "569", "chunk": "ents.  While the preferred solution for the de velopment 7712  \nof new modular pipeline components is for the CDS developer to implement them, there are 7713  \nsome unique situations within the government due to mission sensitivity, criticality, or urgency 7714  \nrequirements that necessitate the in -house development and t esting of modular pipeline 7715  \ncomponents.  7716  \nThe implementation of a customer develop ed MPC capability is optional for CDS developers to 7717  \nimplement and it will not impact their RTB status if not implemented. However , if CDS 7718  \ndevelopers intend to provide a mechani sm for customers to develop and deploy customer 7719  \ndeveloped filters, protocols adapters, and other modular pipeline components then the 7720  \nrequirements in this section shall be implemented.  7721  \nThese requirements are intended to ensure that all customer developed MPC s interact with the 7722  \nCDS in the same manner as all CDS developer provided MPCs. This includes (but is not limited 7723  \nto): MPC audit, logging, and journaling; error reporting; EM/PE interactions; administration tool 7724  \nsupport; installation, patching and remova l; C3R reporting; OS auditing; integrity management; 7725  \nprocess isolation; firewall management; configuration file/policy loadi", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}571{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "570", "chunk": "ng; RBAC; development 7726  \nlanguages; and software development and testing environment.  7727  \nThis section has requirements that apply to the C DS developer AND the customer. If the 7728  \ncustomer fails to implement their portion of the requirements in this section then the NCDSMO 7729  \nwill consider their CDS installation as not RTB compliant under NSM -8 Reporting requirements.  7730  \nCDMPCR -1 [~*/HB, ~*/CCOTS] Customer developed modular pipeline components shall only 7731  \nbe supported on CDS that implement the MPCR requirements stated in Section 11.4 7732  \n(MPCR).  7733  \nCDMPCR -2 [~*/HB, ~*/CCOTS] The modular pipeline components that implement protocol 7734  \nadapters shall implement the Protocol Adapters requirement s in Section 10.15  (PAR).  7735  \nCDMPCR -3 [~*/HB, ~*/CCOTS] CDS customers that implement CDMPC -based filters shall 7736  \ncomply with the RAIN principle by implementing two independently developed and 7737  \nredundant filters.  See GAR -1 and GAR -1.1. 7738  \n Clarification: The same personnel cannot  write both independent redundant filters.  7739UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, S", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}572{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "571", "chunk": "AU, SWE, QAT  \nPage 271 of 397 CDMPCR -3.1 [~*/HB, ~*/CCOTS] The customer must be able to provide evidence that the 7740  \nfilters are independently implemented by different developers . 7741  \nCDMPCR -4 [~*/HB, ~*/CCOTS] The modular pipeline components that implement filters shall 7742  \ncomply with the applicable requirements in Sections 11.1 (GDFR), 11.2 (GXFFPR) and  7743  \n11.3 (MMFFR).  7744  \nCDMPCR -5 [~*/HB, ~*/CCOTS] All software developed shall comply with the protocol 7745  \nadapter and filter software development requirements in this document including  the use 7746  \nof languages that are compiled, type -safe, and memory -safe. 7747  \nCDMPCR -6 [~*/HB, ~*/CCOTS] All customer develope d MPCs shall be digitally signed by a 7748  \ncertificate issued by the CDS developer  to the customer . 7749  \nCDMPCR -6.1 [~*/HB, ~*/CCOTS] The CDS developer shall provide a digitally signed  7750  \ninstallable module (through the normal patch installation process) that contains and 7751  \ninstalls the certificate issued to the customer for signing customer develop ed MPCs.  7752  \nRationale: Normally, only CDS developer signed software can be installed on a CDS. 7753  \nHowever, if the CDS  developer  issues a PKI certificate to the Customer for signing 7754  \nMPCs then there must be a", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}573{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "572", "chunk": " way to load that specific key onto the device. This 7755  \nrequirement provides that mechanism.  7756  \nCDMPCR -6.2 [~*/HB, ~*/CCOTS] The CDS software  shall ensure that the certificates 7757  \nprovided to customers shall only be authorized for the installation and updating of  7758  \ncustomer develo ped MPCs.  7759  \nCDMPCR -7 [~*/HB, ~*/CCOTS] The customer shall use the CALD/CJ D API for reporting all 7760  \naudit/log event and journaling data (if applicable for the CDS) in their MPC.  7761  \nCDMPCR -8 [~*/HB, ~*/CCOTS] The customer shall use the EM/PE API in their MPC  and 7762  \nshall register the relevant MPC events with the EM/PE subsystem.  See MPCR -41 and 7763  \nMPCR -41.1.  7764  \nCDMPCR -9 [~*/HB, ~*/CCOTS] The customer shall use the MPC configuration  (e.g., data 7765  \nflow policy ) loading API in their MPC.  7766  \nCDMPCR -10 [~*/HB, ~*/CCOTS] If the CDS has local on -box administration tools, then the 7767  \nCDS customer must use the CDS developer\u2019s APIs to provide configuration panels for 7768  \ntheir MPCs.  7769  \nClarification:  If the CDS c ustomer\u2019s MPC does not require any configuration then this 7770  \nrequirement does not apply.  If the customer\u2019s site only uses the CDS \u2019 remote 7771  \nmanagement system for controlling the CDS, then CDMPCR -11 can be imple", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}574{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "573", "chunk": "mented 7772  \ninstead of this requirement.  7773  \nCDMPCR -11 [~*/HB, ~*/CCOTS] If the CDS has a remote management system, then the CDS 7774  \ncustomer must use the CDS developer\u2019s APIs to provide configuration panels for their 7775  \nMPCs.  7776UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 272 of 397 Clarification:  If the CDS customer\u2019s MPC does not require any configu ration then this 7777  \nrequirement does not apply.  If the customer\u2019s site does not use CDS\u2019  remote 7778  \nmanagement system for controlling the CDS, then CDMPCR -10 can be implemented 7779  \ninstead of this requirement.  7780  \nCDMPCR -11.1 [~*/HB, ~*/CCOTS] The customer shall implement and use the CDS 7781  \ndeveloper\u2019s API for integrating with CDS developers on -box and remote management 7782  \nadministration systems.  7783  \nCDMPCR -12 [~*/HB, ~*/CCOTS] The customer shall implement SECCOMP and Li nux 7784  \nCapabilities requirements in this document for all their MPCs.  See OSSR -9.1 and OSSR - 7785  \n23.  7786  \nCDMPCR -13 [~*/HB, ~*/CCOTS] The CDS developer shall implement a mechanism to ensure 7787  \nall customer developed MPCs  o", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}575{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "574", "chunk": "perate with at least a base SECCOMP policy created by 7788  \nthe CDS developer that restricts access for system calls not allowed for any protocol 7789  \nadapter or filter (including those created by the CDS developer).  7790  \nCDMPCR -14 [~*/HB, ~*/CCOTS] The CDS developer shall develop and implement MAC 7791  \npolicy sufficient for constraining arbitrary customer developed MPC s 7792  \nCDMPCR -14.1 [~*/HB, ~*/CCOTS] The CDS developer  shall implement a mechanism to 7793  \nprevent the MAC policy from being changed by the CDS customer.  7794  \nCDMPCR -15 [~*/HB, ~*/CCOTS] The CDS developer shall provide the list of all 7795  \nprogramming  languages  supported by the CDS developer for the creation of  customer 7796  \ndeveloped MPCs.  7797  \nCDMPCR -15.1 [~*/HB, ~*/CCOTS] The customer shall only use the development languages 7798  \nsupported  by the CDS developer  for the creation of customer developed MPCs.  7799  \nCDMPCR -16 [~*/HB, ~*/CCOTS] The CDS developer should provide an MPC integrated 7800  \ndevelopmen t environment (IDE) to support consistent repeatable development and testing 7801  \nof customer MPCs.  7802  \nClarification:  This IDE could be an extension to an open source (e.g., VS  Code \u00ae, 7803  \nNetBeans \u00ae) or commercial IDE created to support development of MPCs for ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}576{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "575", "chunk": "the 7804  \nCDS.  7805  \nCDMPCR -16.1 [~*/HB, ~*/CCOTS] The MPC integrated development environment shall 7806  \nprovide a mechanism to support testing of the MPC.   7807  \nCDMPCR -16.2 [~*/HB, ~*/CCOTS] The custom er should  use the CDS developer authorized 7808  \nMPC development  and testing  environment.  7809  \nCDMPCR -16.3 [~*/HB, ~*/CCOTS] The IDE shall provide a mechanism to  package and sign 7810  \nCDMPCs.  7811  \nCDMPCR -16.4  [~*/HB, ~*/CCOTS] The IDE shall provide  a mechanism to simulate the 7812  \nenvironment the MPC will be placed into on the CDS including  the IPC, EM/PE, 7813UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 273 of 397 CALD/CJD and other API s. 7814  \nCDMPCR -17 [~*/HB, ~*/CCOTS] If the CDS developer does not implement an  MPC IDE for 7815  \nCDMPC develop ment , then it shall provide a n application  to package, validate , and sign 7816  \nCDMPCs.   7817  \nCDMPCR -18 [~*/HB, ~*/CCOTS] The customer shall use the vendor provid ed tool to package, 7818  \nvalidate, and sign their CDMPCs.  7819  \n12 Requirements for CDS Virtualization  (VIRT ) 7820  \nThis section  describes the requirem", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}577{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "576", "chunk": "ents for Virtualized CDS and Virtualization used in a CDS 7821  \n(e.g., Access CDS). The rationale for the requirements is described  in the NCDSMO Best 7822  \nPractices Guide for Operating a Cross Domain Solution in a Virtualized Environment  7823  \n(NCDSMO Doc ID: NCDSMO -G-00042 -001_02) documen t, however this document supersedes  7824  \nit. 7825  \nVIRT -1 [~*/HB] Each guest operating system BIOS /UEFI\u00ae  Firmware  shall be configured to 7826  \nonly boot from the intended boot device ( e.g., hard disk, SAN, DVD).  7827  \nT&W: CWE -284, CWE -693, TRTB -00039  7828  \nVIRT -2 [~*/HB] Each guest operating system BIOS /UEFI\u00ae  Firm ware shall require a passw ord 7829  \nfor changes.  7830  \nT&W: CWE -284, CAPEC -176, TRTB -00070  7831  \nVIRT -3 [~*/HB] The virtualization system  (hypervisors) should be evaluated under Common 7832  \nCriteria/NIAP Protection Profile for Server Virtualization Version 1.1 (or higher ) or a 7833  \nprocess specified in CNSSP -11 \u201cNational Policy Governing The Acquisition Of 7834  \nInformation Assurance (IA) And IA -Enabled In formation Technology Products \u201d Section 7835  \nIV.7.  7836  \nVIRT -4 [~*/HB]  The virtualization system may be managed by a hypervisor management 7837  \nconsole (HMC).  7838  \nVIRT -4.1 [~*/HB]  The HMC shall communicate with its  cli", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}578{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "577", "chunk": "ent hypervisors over a network 7839  \nconnection that is operating at the highest security level supported by the CDS.  This 7840  \nnetwork connection can be a CSfC approved  VPN connection ( e.g., usually  an IPSEC or 7841  \nMACSEC tunnel ). 7842  \nT&W: CWE -668, WRTB -00001, CAPEC -69 7843  \nVIRT -4.2 [~*/HB]  HMC Client to HMC Server and HMC Server to Hypervisor 7844  \ncommunications shall be protected using standards -based security protocols ( e.g., TLS, 7845  \nIPSec) using FIPS -certified cryptography.  7846  \nT&W: CWE -311, C APEC -157, CAPEC -94 7847UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 274 of 397 VIRT -4.3 [~*/HB]  The hypervisor and HMC shall log security and change -related events to 7848  \nboth local and remote audit/log repositories.  7849  \nT&W: CWE -778, TRTB -00037, TRTB -00071  7850  \nVIRT -4.4 [~*/HB]  The HMC shall  operate over a dedicated, physically separate management 7851  \nnetwork  or in single NIC system over a NIAP -approved IPSEC or MACSEC tunnel.  7852  \nT&W: CWE -668, WRTB -00025, CAPEC -69 7853  \nVIRT -4.5 Deleted . 7854  \nVIRT -4.6 [~*/HB]  The HMC client and server ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}579{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "578", "chunk": "software shal l not be run on servers hosting  guest 7855  \nvirtual machines.  7856  \nT&W:  CWE -668, WRTB -00100, CAPEC -69, CAPEC -480 7857  \nVIRT -4.7 [~*/HB]  Role -based access control (RBAC) shall  be used for the separation of  7858  \nadministrative duties on the HMC . 7859  \nT&W:  CWE -268, CWE -269, WRTB -00072, CAPEC -180 7860  \nVIRT -4.8 [~*/HB]  TKPC  should be used for all change actions to either the hypervisor or a 7861  \nVM\u2019s configuration.  7862  \nT&W:  CWE -285, WRTB -00071, CAPEC -180 7863  \nVIRT -5 [~*/HB]  A hypervisor shall only span two adjacent security domains ( e.g., S-to-TS but 7864  \nnot U -to-TS). 7865  \nVIRT -5.1  [~*/HB]  A hypervisor may be used to separate releasable domains at the same 7866  \nclassification level (e.g., S//REL USA, ABC and S//REL USA , DEF)  7867  \nVIRT -6 [~*/HB]  All CDSs running on a single hypervisor shall connect to the same security 7868  \ndomains or CO I\u2019s.  For example, if a CDS interconnects TS and S security domains, then 7869  \nall other CDSs on the hypervisor must also connect TS to S and no others.  7870  \nVIRT -7 [~*/HB]  To reduce operational and attack risks, systems should only use the same g uest 7871  \noperating system on a single instantiation  of the hypervisor server on the same physical 7872  \nhardware.  78", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}580{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "579", "chunk": "73  \nClarification:  All the guest VMs should use the same operating system.  7874  \nVIRT -7.1 [~*/HB] Hypervisor man agement VMs and support VMs (e.g., network device 7875  \nisolation, device emulation, virtual TPM managers, introspection, cryptographic layering, 7876  \netc.) may be a different operating system from the  guest VMs . 7877  \nVIRT -8 [~*/HB , ^TCDS ] To reduce operational and attack risks, if a transfer CDS is operating 7878  \non a hypervisor, then only the CDS VMs and related support VMs ( e.g., introspection, 7879  \ndriver domain) shall be run as guest VMs.  7880  \nT&W:  CWE -655, CWE -1125, CAPEC -480, TRTB -00033, TRTB -00040  7881UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 275 of 397 VIRT -8.1 [~*/HB] A virtualized transfer CDS shall not operate with email servers, database 7882  \nservers, web servers, directory servers or non -CDS support VMs on top of a single 7883  \nhypervisor on the same hardware.  7884  \nT&W: CWE-655, CWE -1125, CAPEC -480, TRTB -00033, TRTB -00040  7885  \nVIRT -8.2 [~*/HB , TCDS] A transfer CDS may run on a n Access CDS and have non -CDS guest 7886  \nVMs. Howeve", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}581{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "580", "chunk": "r, the guest VMs must be custom mission speci fic application VMs 7887  \nspecifically built  to support the tactical system. General purpose VMs would not be 7888  \nallowed per VIRT -8.1. The configuration and maintenance of the guest VMs as well as 7889  \nthe CDS VM would be included in the overall system upgrade and maintenan ce cycle . 7890  \nVIRT -8.3 [~*/HB] If a transfer CDS is NOT operating on the Access CDS , then the Access 7891  \nCDS  may host non-CDS guest VMs  with each guest VM operating a t a single level only.  7892  \nClarification:  This requirement is intended to support a Server -variant of a VM based 7893  \nAccess CDS operating multiple  instance s of an application or an IT environment 7894  \n(e.g., typical set of Microsoft\u00ae servers and client) . Each instance of the application or 7895  \nIT environment w ould be operating at a specific level  (e.g., Secret Releasable ABC 7896  \nand Secret Releasable XYZ).  7897  \nVIRT -9 [~*/HB]  Only hardware systems certified by the hypervisor vendor shall be used to host 7898  \nthe hypervisor.  7899  \nT&W:  CWE -758, WRTB -00096, TRTB -00049  7900  \nVIRT -10 [~*/HB]  Only hardware systems with virtualization processor hardware ( e.g., Intel 7901  \nVT-x\u00ae/AMD -V\u00ae) including chipset based I/O virtualization ( e.g., Intel VT -", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}582{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "581", "chunk": "d\u00ae/AMD - 7902  \nVi\u00ae) and EPT/NPT support shall be used  and must be enabled.  7903  \nT&W:  CWE -653, CAPEC -480 7904  \nVIRT -10.1 [~*/HB]  Single -Root I/O Virtualization245 (SR-IOV) shall not  be used . 7905  \nRationale: SR-IOV is a performance enhancement capability. The security of the 7906  \nseparatio n mechanism resides in the device being used (e.g., A NIC). This simply 7907  \nputs too much trust in the devices.  7908  \nT&W:  CWE -405, CWE -653, CAPEC -125, CAPEC -157, CAPEC -194, CAPEC -212 7909  \nVIRT -11 [~*/HB]  Access CDS (server variant) hosting non-CDS VM s that are operating at 7910  \ndifferent security levels shall use virtual switches , VPNs,  and virtual firewalls  to provide 7911  \nadditional boundary protection for guest VMs . 7912  \nT&W:  CWE -653, TRTB -00077  7913  \n \n245 https://www.usenix.org/system/files/conference/usenixsecurity15/sec15 -paper -smolyar.pdf  and \nhttps://faculty.sites.uci.edu/zhouli/files/2018/09/codaspy17.pdfUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 276 of 397 VIRT -11.1 [~*/H B] Virtual switches , VPNs,  and virtual firewalls shall be used to provide 7914  \na", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}583{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "582", "chunk": "dditional network isolation between guest VMs.  7915  \nT&W:  CWE -653, TRTB -00077  7916  \nVIRT -11.2 Deleted.  7917  \nVIRT -11.3 [~*/HB]  Virtual switches , routers, and firewalls shall not be connected to  multiple 7918  \nphysical interfaces.  7919  \nT&W:  CWE -653, TRTB -00077    7920  \nVIRT -11.3.1  [~*/HB]  Separate in stances of virtual switches, routers and firewall shall be used 7921  \nwith each individual physical interface that is in a different security domain. Servers with 7922  \nmultiple physical interface s in the same security domain can use the same virtual 7923  \nswitches, routers , and firewalls.  7924  \nT&W:  CWE -653, TRTB -00077  7925  \nVIRT -11.4 [~*/HB]  Physical and virtual intrusion detection and prevention systems shall be 7926  \nused to protect the hypervisor and guest VMs.  7927  \nT&W:  CWE -693, WRTB -00104, CAPEC -118, CAPEC -152, CAPEC -156, CAPEC -172, 7928  \nCAPEC -210, CAPEC -223, CAPEC -225, CAPEC -255, CAPEC -262 7929  \nVIRT -11.5 [~*/HB]  Only NSA approved CSf C solutions shall be used for separating 7930  \ncommunications of different security domains (including those at different releasability 7931  \nand handling caveats) within the hypervisor cluster.  7932  \nT&W:  CWE -326, CWE -668, CAPEC -20, CAPEC -97, TRTB -00077  7933  \nVIRT -12 [~*/HB", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}584{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "583", "chunk": "]  For a CDS running on a hypervisor, a ded icated directly attached physical 7934  \nstorage device should be used.  7935  \nT&W:  CWE -653, CAPEC -37 7936  \nVIRT -12.1 [~*/HB]  If a CDS running on a hypervisor uses a SAN, then the SAN shall operate 7937  \nat the same security level as the h igh side of the CDS.  7938  \nT&W:  CWE -668, TRTB -00077  7939  \nVIRT -12.2 [~*/HB]  If a Multi -Level Secure (MLS) CDS running on a hypervisor uses SAN 7940  \nstorage, a physically separate SAN shall be used for each security domain serviced by the 7941  \nCDS  to ensure strong separation unless a CSfC approved DAR  solution is used to 7942  \ncryptographically separate the data on the SAN.  7943  \nT&W:  CWE -668, TRTB -00077  7944  \nVIRT -12.3  [~*/HB]  If a SAN is used, the SAN Management interface shall be system high.  7945  \nT&W: CWE -653, CAPEC -69 7946  \nVIRT -12.4  [~*/HB]  If a SAN is used, the SAN Management interface shall not operate on any 7947UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 277 of 397 Guest VM attached networks.  7948  \nT&W: CWE -668, TRTB -00077  7949  \nVIRT -12.5  [~*/HB]  When using a singl", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}585{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "584", "chunk": "e S AN for storage of Guest VMs, the Guest VMs shall 7950  \nuse software based Full Disk Encryption (FDE) to reduce the security risks of multiple 7951  \nhypervisors with VMs in multiple security domains.  7952  \nClarification:  The FDE for Guest VMs can be implemented in the VM or by the 7953  \nhypervisor.  7954  \nT&W:  CWE -311, CWE -653, CAPEC -37 7955  \nVIRT -12.6  [~*/HB]  If a SAN is used, the SAN technology used shall be certified by the 7956  \nhypervisor vendor for compatibility with the hypervisor software.  7957  \nT&W: CWE -758, CAPEC -116, CAPEC -37 7958  \nVIRT -13 [~*/HB]  Failover systems shall be directly connected to one another via a dedicated 7959  \nnetwork or encrypted using FIPS -certified cryptography over a system high network.  7960  \nFailover systems include those t hat provide high availability, hot standby, or live 7961  \nmigration including SAN storage.  7962  \nT&W:  CWE -311, CAPEC -157, CAPEC -94 7963  \nVIRT -14 [~*/HB]  All physical servers being used for high availability/fault tolerance, hot 7964  \nstandby, or live migration for a specified hypervisor shall be identically configured using 7965  \nidentical hardware components and software.  7966  \nVIRT -15 [~*/HB]  Snapshots shall be strictly controlled and managed via HMC RBAC 7967  \npermission to e", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}586{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "585", "chunk": "nsure that a virtualized CDS is n ot rolled back to an insecure state.  7968  \nT&W:  WRTB -00072, CAPEC -180 7969  \nVIRT -16 [~*/HB]  Unless specifically required, restarted snapshot CDS VMs shall not be 7970  \nconnected to the network until existing jobs/data are cleaned from the CDS queues. This  7971  \nassumes the network interface configuration has not changed.  7972  \nT&W:  WRTB -00101, TRTB -00078  7973  \nVIRT -17 [~*/HB]  A CDS VM snapshot shall not be used if the network interface configuration 7974  \nhas changed since the snapshot was created.  7975  \nT&W:  WRTB -00081, CAPEC -117, TRTB -00050  7976  \nVIRT -18 [~*/HB]  Snapshot and cloning should be used for applying changes to VMs.   7977  \nVIRT -18.1 [~*/HB]  When snapshot or clones are used for applying system chang es and perform 7978  \nfunctional testing the VM should not be connected to a production network  7979  \nVIRT -18.2 [~*/HB]  If a clone is used to add identical copies of a CDS for high availability or 7980  \nload balancing, the system\u2019s ho stname and IP addresses shall be changed so that audit 7981  \nrecords will accurately reflect the origination of the audit data.  7982UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}587{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "586", "chunk": " USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 278 of 397 T&W:  WRTB -00081, TRTB -00037, TRTB -00040  7983  \nVIRT -18.3 [~*/HB]  If using Network Address Translatio n (NAT) to minimize reconfiguration 7984  \nof clones, then the hostname shall be changed.  7985  \nT&W: WRTB -00081, TRTB -00037  7986  \nVIRT -19 [~*/HB]  Introspection capabilities, if available, should be used to monitor the state of 7987  \neach guest OS.  7988  \nT&W: WRTB -00103, CAPEC -552 7989  \nVIRT -19.1 [~*/HB]  Introspection of a guest OS shall be performed by software operating in an 7990  \nisolated and dedicated monitoring VM, not directly by the hypervisor.  7991  \nT&W:  CWE -653, CAPEC -480 7992  \nVIRT -19.2 [~*/HB ] A separate monitoring VM shall be used for each monitored VM and shall 7993  \noperate at the same security level as the monitored VM.  7994  \nT&W:  CWE -653, TRTB -00077  7995  \nVIRT -19.3 [~*/HB ] To reduce the likelihood of a cascade attack against the guest OS, the 7996  \nmonitoring VM shall be physically or cryptographically isolated from all user networks.  7997  \nT&W:  CWE -653, CAPEC -113 7998  \nVIRT -19.4 [~*/HB ] Merged  with VIRT -19.1 7999  \nVIRT -20 [~*/HB]  Dynamic IP addresses assigned by the hypervisor\u2019s DHCP servers should be 8000  \nconsi", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}588{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "587", "chunk": "dered as an alternative to hard -coding IP addresses in CDS images that are going to 8001  \nbe cl oned.  8002  \nT&W:  WRTB -00081, CAPEC -194 8003  \nVIRT -20.1 [~*/HB]  If DHCP is used, a different DHCP server must be used for each security 8004  \ndomain (network)  hosted on the hypervisor . 8005  \nT&W:  CWE -653, TRTB -00077  8006  \nVIRT -21 [~*/HB]  Hypervisors should use isolated, non -privileged driver VMs  for all virtualized 8007  \nhardware.  8008  \nT&W:  CWE -653, CAPEC -69, CAPEC -124, CAPEC -452 8009  \nVIRT -21.1 [~*/HB]  Driver VMs  should be dedicated to a single CDS VM.  8010  \nT&W: CWE -653, CAPEC -124 8011  \nVIRT -22 [~*/HB]  Hypervisors shall use MAC  to control VM -to-VM, VM -to-hypervisor, VM - 8012  \nto-hardware interactions and communications.  8013  \nT&W: CWE -653, WRTB -00099, CAPEC -180, CAPEC -554, TRTB -00077  8014  \nVIRT -23 [~*/HB]  Hypervisors that have an administrative VM ( e.g., dom0 in Xen Server\u00ae ) 8015UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 279 of 397 shall use MAC inside the administrative VM to contain potential compromises/breakouts . 8016  \nT&W: CWE -250, CWE -653", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}589{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "588", "chunk": ", CAPEC -176, CAPEC -180, TRTB -00074  8017  \nVIRT -24 [~*/HB]  Multiple VMs running on a hypervisor shall not be allowed to communicate 8018  \nwith each other unless they are operating in the same security domain.  8019  \nT&W: CWE -653, TRTB -00077  8020  \nVIRT -25 [~*/HB]  By default, inter -VM and VM -to-Hypervisor communication mechanisms 8021  \nsuch as file sharing, clipboard, etc. shall be disabled.  8022  \nT&W: CWE -250, CAPEC -150, TRTB -00012, TRTB -00065  8023  \nVIRT -26 [~*/HB]  The hypervisor shall use Secure and Trusted Boot to ensure the integrity (load 8024  \ntime and runtime) of the hardware, hypervisor, and guest VMs.  8025  \nT&W: CWE -353, WRTB -00050, CAPEC -523, CAPEC -552, TRTB -00039  8026  \nVIRT -27 [~*/HB]  Trusted Network Connect (TNC) should be used prevent a compromise d 8027  \nhypervisor and its VMs from accessing network resources.  8028  \nT&W: CWE -402, CWE -668, WRTB -00098, CAPEC -22, CAPEC -94, CAPEC -151, 8029  \nCAPEC -555, TRTB -00002  8030  \nVIRT -28 [~*/HB]  Virtual TPM (vTPM), its associated measured virtual BIOS /UEFI\u00ae  8031  \nFirmware , and trusted boot loader should be used to improve the integrity of VMs.  8032  \nT&W:  CWE -269, CWE -693, CAPEC -1, CAPEC -180 8033  \nVIRT -29 [~*/HB]  The Hypervisor shall assign uniqu e MAC addresses for e", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}590{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "589", "chunk": "ach of a VM\u2019s 8034  \nvirtual interface s. 8035  \nT&W:  CWE -223, CWE -694, CAPEC -194, TRTB -00037  8036  \nVIRT -30 [~*/HB]  The same instance of a network encryption VM cannot be shared between 8037  \nguest VMs  unless the guest VMs are operating at exactly the same security marking.  8038  \nClarification:  If dual layer tunnels are used as part of the CSfC solution then the outer 8039  \ntunnel can be shared but the inner tunnel must be a separate instance if the guest VMs 8040  \nare a t different security markings.  8041  \nT&W: CWE -200, CWE -653, CAPEC -94, TRTB -00077  8042  \nVIRT -31 [~*/HB]  The hypervisor shall ensure that any memory allocated to a guest VM is 8043  \nzeroized prior to allocation to the VM.  8044  \nT&W: CWE -226, CWE -665, CAPEC -37, CA PEC-74, CAPEC -554 8045  \n13 Requirements for use of Separation Kernels  (SK) 8046  \nThis section describes the requirements for operating a TSB CDS on a Separation Kernel (SK) 8047  \nand the use of a Separation Kernel in implementing a CDS.  8048UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 280 of 397 SK-1 [~*/HB, ~*/CCO TS] If the SK uses a statical", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}591{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "590", "chunk": "ly defined layout for allocating hardware 8049  \nresources246 to the partitions, the SK vendor must provide an application that identifies 8050  \nany conflicting or overlapping resources.  8051  \nSK-1.1 [~*/HB, ~*/CCOTS]  The SK vendor should provide a tool that provides a visualization 8052  \nof how the partitions are connected to each other and to  any assigned  devices.  8053  \nSK-2 [~*/HB, ~*/CCOTS]  CDS that are implemented directly on a SK  shall  enforce process  8054  \nseparation by using separate  partitions for each protocol adapter and f ilter. 8055  \nSK-3 [~*/HB, ~*/CCOTS]  The SK must be compliant with DO-178C, Software Considerations 8056  \nin Airborne Systems and Equipment Certification  Design Assurance Level (DAL)  A. 8057  \nSK-4 [~*/HB, ~*/CCOTS]  The SK must provide the following  minimum  Inter -Partition 8058  \nCommunications mechanisms: bidirectional  communications capable of supporting 8059  \nInternet Protocol, blocking  unidirectional FIFO, and non-blocking  unidirectional FIFO.  8060  \nSK-5 [~*/HB, ~*/CCOTS]  The SK shall ensure that memory assigned to a partition is zeroized 8061  \nprior to allocation to the partition.  8062  \n14 Requirements for Multi -Level Security CDS (MLS)  8063  \nThis section includes additional requirements that are unique to MLS", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}592{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "591", "chunk": " systems. Any system that 8064  \nis concurre ntly storing and/or proces sing dat a at multiple levels is an MLS system. In a sense, a 8065  \nmultiple domain CDS is an MLS system since it would be connected to multiple domains and 8066  \nthus transferring (processing) data that is at multiple levels. However, the subtle difference here 8067  \nis that a transfer CDS is only concerned ab out security labels and security domains for two core 8068  \nreasons: checking for security markings to make sure the data is releasable to the destination 8069  \ndomain and ensuring the filter policy being used is appropriate for the security domain 8070  \ncombination and dir ection of flows ( e.g., NIPR ->SIPR, JWICS ->CENTRIXS ISAF) . The 8071  \nTransfer CDS does not store data (except for quarantine and logging purposes). In an MLS CDS, 8072  \nthe core functions of the CDS are to store data at different sensitivity levels, maintain separation , 8073  \nand control access based on sensitivity label dominance.  These  requirement s also apply to Cloud 8074  \nplatforms that implement Platform -as-a-Service (PaaS), Software -as-a-Service (SaaS), and 8075  \nInfrastructure -as-a-Service  (IaaS)  that intend to support connections  from  different security 8076  \ndomains , store  data at different secur", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}593{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "592", "chunk": "ity levels, and process data at different security levels.  8077  \nIn an MLS CDS  or MLS Database , object regrading , read -down, read -up, write -down, and 8078  \nwrite -up are each consider ed a cross domain trans fer and  a transfer CDS mechanism must 8079  \nbe used to filter the data prior to transferring it ( i.e., regrading it) to the destination label.  8080  \nMLS -1  [~*/HB, ~CCOTS]  MLS systems  shall  implement MAC  enforced label ing on  all system 8081  \nobjects  including processes, IPCs, files , and internal networking ( e.g., TCP/UDP 8082  \n \n246 Hardware resources include processor cores, processor sockets, memory, interrupts, PCI slots, devices, etc.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 281 of 397 connections within the CDS, usually via loopback interface).  8083  \nT&W: CWE -284, CAPEC -180 8084  \nMLS -2  [~*/HB, ~CCOTS]  MLS remote management and monitoring communications over a 8085  \ndedicated management interface do not require labelled networking. Use of s upport 8086  \nnetwork protocols  like DNS, PTP, NTP, and ARP do not require labelled networking.  8087  \nMLS -3  [~*/HB, ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}594{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "593", "chunk": "~CCO TS] MLS systems shall use the operating system\u2019s MAC system to 8088  \nrestrict an subject\u2019s interaction with objects to only those in which its label is equal to or 8089  \ndominates the label of the other object . 8090  \nT&W: CWE -653, WRTB -00001, TRTB -00023, TRTB -00077  8091  \nMLS -4  [~*/HB, ~CCOTS]  MLS systems shall restrict the ability of processes to change the 8092  \nlabels ( e.g., regrade) on objects to only those processes explicitly allowed to do so . 8093  \nT&W: CWE -267, CWE -653, CWE -707, CAPEC -122, TRTB -00061, TRTB -00077  8094  \nMLS -5  [~*/HB, ~CC OTS] MLS systems shall restrict processes that need to run at multiple 8095  \nlevels from regrading data. These process es must maintain the original label on the data.   8096  \nClarification: A domain router in an MLS system that is located at the end of filtering 8097  \npipeli ne is exempt from this requirement.  8098  \nT&W: CWE -267, CWE -653, CWE -707, CAPEC -122, TRTB -00061, TRTB -00077  8099  \nMLS -5.1 [~*/HB, ~ CCOTS] The regrading  operation  shall be performed  at the end of a filter 8100  \npipeline.  8101  \nT&W: CWE -707, TRTB -00061, TRTB -00065  8102  \nMLS -6  [~*/HB, ~CCOTS]  MLS systems shall use an external transfer CDS or internally 8103  \nimplement a transfer CDS function for all files that a", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}595{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "594", "chunk": "re  to be  relabeled.  8104  \nT&W: CWE -707, TRTB -00061  8105  \nMLS -7  [~*/HB, ~CCOTS]  MLS systems shall use an external transfer CDS or internally 8106  \nimplement a transfer CDS function for all read down , read up, write down,  or write up 8107  \naction s on objects.  8108  \nT&W: CWE -707, TRTB -00061  8109  \nMLS -8 [~*/HB, ~CCOTS]  MLS  systems  shall implement a mechanism to assess and  enforce 8110  \ndominance calculations for access and regrade operations . 8111  \nMLS -9 [~*/HB, ~ CCOTS] MLS systems shall provide a mechanism to map internal oper ating 8112  \nsystem security labels to Office of the Director National Intelligence (ODNI) Security 8113  \nMarking Program security label in the Information Security Marking (ISM) Metadata and 8114  \nCountry  format s. 8115  \nMLS -10 [~*/HB, ~ CCOTS] MLS systems should  use dedicated physical communications  8116  \ninterfaces to connect to networks (i.e. , security domains) that a re operating a t different 8117UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 282 of 397 security levels . 8118  \nT&W: CWE -653, WRTB -00031, CAPEC -554, TRTB -00061  8119  \nMLS ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}596{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "595", "chunk": "-11 [~*/HB, ~ CCOTS] MLS systems shall support labeled networking and implement one 8120  \nor more of the following rules:  8121  \nMLS -11.1 [~*/HB, ~ CCOTS] MLS systems shall label inbound data originating from  a 8122  \ncommunications  interface  for a network that does not support labeled data  with the 8123  \nappropriate label and only permit communications outbound to the communications 8124  \ninterfaces based MAC policy . 8125  \nT&W: CWE -653, WRTB -00001, WRTB -00035, WRTB -00112, CAPEC -153, TRTB - 8126  \n00023, TRTB -00077  8127  \nMLS -11.2 [~*/HB, ~ CCOTS] MLS systems shall reject inbound unlabeled data on a 8128  \ncommunications interface if that network is supposed to  have only labeled data and only 8129  \npermit communications outbound to the communications interfaces based MAC  policy.  8130  \nThis event shall be  audited  is the same way that filters audit message failures (see  8131  \nJALSR -2.5).  8132  \nT&W: CWE -653, WRTB -00001, WRTB -00035, WRTB -00112, CAPEC -153, TRTB - 8133  \n00023, TRTB -00077  8134  \nMLS -11.3 [~*/HB, ~ CCOTS] MLS systems shall reject inbound labeled data on a 8135  \ncommunications interface if the label for the data is wrong  and the network is intended to 8136  \nhave labeled data  and only permit communications outbound to the communi", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}597{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "596", "chunk": "cations 8137  \ninterfaces based MAC policy . This should be audited in the same way that filters audit 8138  \nmessage failures (see  JALSR -2.5). 8139  \nT&W: CWE -653, WRTB -00001, WRTB -00035, WRTB -00112, CAPEC -153, TRTB - 8140  \n00023, TRTB -00077  8141  \nMLS -12 [~*/HB, ~ CCOTS] MLS systems shall use \u201cRFC5570: Common Architecture Label 8142  \nIpv6 Security Option (CALIPSO) \u201d for Ipv6 and the Commercial IP Security Option 8143  \n(CIPSO)247 for Ipv4 to label network packets within the MLS environment. Labe led 8144  \nIPSEC248 may also be used.  8145  \nMLS -12.1 [~*/HB, ~ CCOTS] MLS  shall use IPSEC Authentication Header (AH)  with Galois 8146  \nMessage Authentication Code (GMAC)  to ensure integrity of CIPSO  and CALIPSO  8147  \n \n247 See \u201cFIPS -188:Standard Security Label for Information Transfer \u201d, \nhttps://csrc.nist.gov/csrc/media/publications/fips/188/archive/1994 -09-06/documents/fips188.pdf , and IETF CI PSO \nWorking Group draft of \u201c Commercial I PSecurity Option (CIPSO 2.2) \u201d, https://tools.ietf.org/html/draft -ietf-cipso -\nipsecurity -01, and \u201cRFC -1038 : U.S. Department of Defense Security Options for the Internet Protocol\u201d, \nhttps://tools.ietf.org/html/rfc1108  \n248 https://tools.ietf.org/html/draft -ietf-ipsecme -labeled -ipsec -02UNCLASSIFIED//FOR OFFICI AL USE ONL", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}598{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "597", "chunk": "Y//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 283 of 397 labels (see RFC 4543249, RFC 4302250, NIST SP 800-38D251). 8148  \n15 Transfer CDS Class/ CDS Implementation Model 8149  \nRequirements  8150  \nThis section  contains the architectural design pattern and implementation  requirements for 8151  \ndifferent combinations of Transfer CDS Classes and CDS Implementation Models .  8152  \nThe design patterns shown bel ow are a representation of the architectural characteristics of the 8153  \nhow the dataflow  should be implemented. The design patterns are missing many aspects of a 8154  \nCDS including audit subsystems and C2/ metadata communications. The  design patterns  are not 8155  \nintende d to represent a complete CDS architecture.  8156  \nUnderstanding the Design Pat terns:  8157  \n\u2022 Blue boxes are individual running process es; 8158  \n\u2022 Light brown cylinders are one -way inter -process communications mechanisms (in 8159  \nsoftware); and  8160  \n\u2022 A purple triangle is a diode.  8161  \n15.1  DCCDS -FF/TSB  Architecture Design Pattern  and Requirements  8162  \n(DCFFTSB ) 8163  \nDCFFTSB -ADPR -1 The CDS shall implement  an assured pipeline de", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}599{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "598", "chunk": "sign pattern for the CDS 8164  \ndataflow  for dataflow s processing fixed format  data. 8165  \nDCFFTSB -ADPR -2 The CDS shall implement the following assured pipeline design pattern for  8166  \na CDS connecting two or more security domain s. 8167  \n \n249 IETF RFC 4543, \u201c The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH \u201d \nhttps://tools.ietf.org/html/rfc4543  \n250 IETF RFC 4302, \u201c IP Authentication Header \u201d, https://tools.ietf.org/html/rfc4302  \n251 NIST SP 800 -38D, \" Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and \nGMAC \u201d, November 2007, https://csrc.nist.gov/publications/detail/sp/800 -38d/finalUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 284 of 397  8168  \nFigure 41 \u2013 DCCDS -FF/TSB Multiple Domain Assured Pipeline Design Pattern  8169  \n 8170  \n15.2 DCCDS -FF/CCOTS  Architecture Design Pattern  and Requirements  8171  \n(DCFFCOTS ) 8172  \nCCOTS based CDS are no longer considered acceptable , by itself,  for USG CDS deployment s 8173  \nprotecting USG Classified National Security Systems. They can be used as part of a solution 8174  \nprotecting USG", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}600{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "599", "chunk": " NSS  if a RTB compliant CDS is used on the high side . They are useful in 8175  \nsituation s where the low side system must be 100% COTS. This architectural approach is 8176  \nuseful in  foreign government situations where a USG CDS cannot be sold.   8177  \n15.2.1  Design Patterns  (DCFFCOTS -P) 8178  \nDCFFCOTS -P-1 The CDS shall implement the following assured pipeline design pattern for a 8179  \nCDS implementing a  unidirectional  dataflow  processing fixed format data. 8180  \n 8181UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 285 of 397  8182  \nFigure 42 \u2013 Composed COTS Unidirectional CDS Design Pattern  8183  \nDCFFCOTS -P-2 The CDS shall implement the following assured pipeline design pattern for a 8184  \nCDS implementing a bidirectional  dataflow  processing fixed format data. 8185  \n 8186  \nFigure 43 \u2013 Composed COTS Bi -Directional CDS Design Pattern  8187  \n15.2.2  Unique Requirements  (DCFFCOTS -R) 8188  \nDCFFCOTS -R-1 For a unidirectional  dataflow  the CDS shall employ a composed COTS 8189  \narchitecture incorporating two independent COTS XML Filtering Firewalls ( COTS 8190  \nFiltering #1, #2, )", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}601{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "600", "chunk": " separated by a one-way transfer mechanism (usually a diode) , which  8191  \nprovides a hardware -enforced unidirectional  dataflow . 8192  \nDCFFCOTS -R-1.1 The Pitcher and Catcher shall  individ ually implement RAIN principles . 8193UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 286 of 397 DCFFCOTS -R-1.2 The Catcher shall  implement redundant and independent ( e.g., different) 8194  \nfilters from those used on the Pitcher . 8195  \nDCFFCOTS -R-1.3 In environments in which one-way devices are used extensively for Low -to- 8196  \nHigh and High -to-Low flows , the pitchers/catchers on the high side shall  use the same 8197  \nfilter implementations and the pitchers/catchers on the low side shall  use a different 8198  \nimplementation than the high side pitchers/catchers . 8199  \nDCFFCOTS -R-2 For a bidirectional  dataflow  the CDS shall employ a composed COTS 8200  \narchitecture incorporating three independent  COTS XML Filtering Firewalls ( COTS 8201  \nFiltering #1, #2,  #3) separated by two one-way transfer mechanism s. 8202  \nDCFFCOTS -R-3 The CDS shall be extensible  through the addition of Protocol Adapte", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}602{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "601", "chunk": "rs (PA) 8203  \nplaced on the origin and destination  sides . 8204  \nDCFFCOTS -R-4 The CDS shall validate , after transfer through the diode , that the received data 8205  \nis properly formatted in XML  and compliant with approved schemas . 8206  \nDCFFCOTS -R-5 The CDS shall not operate Pitchers and Catchers on the same physical host or 8207  \nin the same hypervisor instance.  8208  \nDCFFCOTS -R-6 Pitcher Interface Requirements  8209  \nDCFFCOTS -R-6.1 The Pitcher functionality shall be separated logically (i.e., run under a 8210  \ndifferent virtual machine or process ) or physically (i.e., run on separate hardware) from 8211  \nthe XML Filtering Firewall s. 8212  \nDCFFCOTS -R-6.2 The Pitcher functionality shall communicate with the XML Filtering 8213  \nFirewall via mutually authenticated HTTPS v1.1  or higher . 8214  \nDCFFCOTS -R-6.3 The Pitcher shall employ PKI and IP allowlist ing to authenticate the XML 8215  \nFiltering Firewall connection . The use of statically assigned or locally generated 8216  \ncertificates is allowed as long as both systems are mutually authenticated.  8217  \nDCFFCOTS -R-6.4 The Pitcher shall d rop or reject client -initiated sessions and associated data  8218  \nthat do not pass session authentication.  8219  \nDCFFCOTS -R-6.5 The Pitcher shall receive mess", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}603{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "602", "chunk": "ages from its associated XML Filtering 8220  \nFirewall s and encapsulate them in the protocol required for transmission across the 8221  \nDiode.  8222  \nDCFFCOTS -R-6.6 The Pitcher shall  transmit encapsulated messages , via a Diode , to a Catcher 8223  \nin accordance  with the routing metadata  incorporated into each message and shall only do 8224  \nso after validatin g the content against the supp lied dataflow  filter policy ID .  8225  \nDCFFCOTS -R-6.7 Each Pitcher should  support transmitting to multiple catchers  within 8226  \ndifferent security enclaves.  8227  \nDCFFCOTS -R-6.8 The Pitcher  should  maintain destination domain routing to determine which 8228  \nCatcher receives a particular message.  8229UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 287 of 397 DCFFCOTS -R-6.9 The high -side Pitcher (in a high -to-low dataflow ) shall enforce at least two 8230  \nauthentication factors for local operating system authentication . 8231  \nDCFFCOTS -R-6.10 The low -side Pitcher (in a low -to-high dataflow ) shall enforce at least two 8232  \nauthentication factors for local op erating system authentication. ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}604{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "603", "chunk": " 8233  \nDCFFCOTS -R-6.11 The Pitcher shall store audit log data locally using a periodic or size -based 8234  \nroll and retain model.  8235  \nDCFFCOTS -R-6.12 The Pitcher shall retain locally -stored audit log data for a period not less  8236  \nthan 30 calendar days . 8237  \nDCFFCOTS -R-7 Catcher Interface Requirements  8238  \nDCFFCOTS -R-7.1 Each Catcher should  support receiving data from multiple Pitchers 8239  \nrespectively sending messages  from different security enclaves.  8240  \nDCFFCOTS -R-7.2 The Catcher shall remove the encapsulation associated with the Diode from 8241  \neach message received from th e Pitcher and forward it to its associated XML Filtering 8242  \nFirewall after validating the content against the supplied dataflow filter policy ID.  8243  \nDCFFCOTS -R-7.3 The Catcher shall store audit log data locally using a periodic or size -based 8244  \nroll and retain model.  8245  \nDCFFCOTS -R-7.4 Deleted. Covered in DCFFCOTS -R-7.5 and 7.6.  8246  \nDCFFCOTS -R-7.5 The high -side Catcher (in a low -to-high dataflow ) shall retain locally stored 8247  \naudit log  data for a minimum period of 30  calendar days . 8248  \nDCFFCOTS -R-7.6 The low -side Catcher  (in a high -to-low dataflow ) shall retain locally stored 8249  \naudit log data for a minimum period of 30 cale", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}605{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "604", "chunk": "ndar days . 8250  \nDCFFCOTS -R-7.7 The high -side Catcher (in a low -to-high dataflow ) shall enforce at least two - 8251  \nfactor authentication for local operating system authentication . 8252  \nDCFFCOTS -R-7.8 The low -side Catcher (in a high -to-low dataflow ) shall enforce at least two - 8253  \nfactor authentication for local operating system authentication.  8254  \nDCFFCOTS -R-8 XML Firewall Requirements  8255  \nDCFFCOTS -R-8.1 The XML Filtering Firewall s shall each utilize different  operating systems  8256  \n(e.g., RHEL\u00ae  vs. BSD vs Microsoft  Windows \u00ae is ok , but not RHEL\u00ae  vs Ubunt u\u00ae vs 8257  \nDebian \u00ae is not ). 8258  \nDCFFCOTS -R-8.2 The high -side XML Filtering Firewall shall enforce at least two -factor  8259  \nauthentication for local operating system authentication.  8260  \nDCFFCOTS -R-8.3 The low -side XML Filtering Firewall shall enforce at least two -factor  8261  \nauthentication for local operating system authentication.  8262  \nDCFFCOTS -R-8.4 The low -side XML Filtering Firewall should enforce at least two -factor  8263  \nauthentication for application -level user account authentication.  8264UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, B", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}606{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "605", "chunk": "HR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 288 of 397 DCFFCOTS -R-8.5 The high -side XML Filtering Firewall should enforce at least two -factor  8265  \nauthentication for application -level user account authentication.  8266  \nDCFFCOTS -R-8.6 The XML Filtering  Firewalls shall each utilize different  XML filtering 8267  \nbinaries and libraries.  8268  \nDCFFCOTS -R-8.7 The XML Filtering Firewall should  use URI paths as part of content upload 8269  \nto the firewall to determine which dataflow  filtering policy to use . 8270  \nDCFFCOTS -R-8.8 The XML Filtering Firewall shall drop or reject messages not explicitly 8271  \npermitted via configured policy.  8272  \nDCFFCOTS -R-8.9 The XML Filtering Firewall shall initially validat e each message received 8273  \nagainst the authorized XML schema for the identified message type.  8274  \nDCFFCOTS -R-8.10 The XML Filtering Firewall shall drop or reject messages that fail initial 8275  \nschema validation.  8276  \nDCFFCOTS -R-8.11 The XML Filtering Firewall shall perform post-sanitization message 8277  \nvalidation prior to forwarding the message through the one-way transfer mechanism . 8278  \nDCFFCOTS -R-8.12 The XML Filtering Firewall shall drop or reject messages  that fail post - 8279  \nsanitization and post -filtering valida", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}607{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "606", "chunk": "tion.  8280  \nDCFFCOTS -R-8.13 The XML Filtering Firewall shall apply and enforce all loaded data 8281  \nsanitization policies after initial validation is complete.  8282  \nDCFFCOTS -R-8.14 The XML Filtering Firewall  shall store audit log data locally using a 8283  \nperiodic or size -based roll and retain model.  8284  \nDCFFCOTS -R-8.15 The XML Filtering Firewall shall  have the ability to perform  Unicode - 8285  \nbased  dirty word/clean word252 searching of XML files. 8286  \nDCFFCOTS -R-8.16 The XML Filtering Firewall shall be able to support at least 64 concurrent 8287  \nXML dataflow s installed and enabled.  8288  \nDCFFCOTS -R-9 Protocol Adapter  Subs ystem  (PAS) Requirements  8289  \nDCFFCOTS -R-9.1 The CDS shall incorporate a PAS in each domain to which the CDS is 8290  \nconnected . 8291  \nDCFFCOTS -R-9.2 The CDS PAS shall be installed inline between the security domain and the 8292  \nXML Filtering Firewall . 8293  \nDCFFCOTS -R-9.3 The CDS PAS shall be extensible  through the addition of multiple  Protocol 8294  \nAdapters . 8295  \n \n252 Dirty words are words or phrases that are not allowed to appear in the content and are an indication the content is \nlikely not releasable to the destination domain. Clean words are words that contai n a dirty word but are allowed to \nappea", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}608{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "607", "chunk": "r in the content (e.g., if secret was a dirty word, then secretary could be a clean word).UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 289 of 397 DCFFCOTS -R-9.4 The CDS may operate multiple instances of the same or different protocol 8296  \nadapters on the PAS . 8297  \nDCFFCOTS -R-9.5 The PA application software should  not be the same within both the high 8298  \nand low security domains.  8299  \nDCFFCOTS -R-9.6 The PAS operating system should  not be the same in both the high and low 8300  \nsecurity domains.  8301  \nDCFFCOTS -R-9.7 Deleted . 8302  \nDCFFCOTS -R-9.8 The PA S shall provide  protocol adapters that implement the HTTPS  and 8303  \nSFTP  protocol s. 8304  \nDCFFCOTS -R-9.9 The PA shall drop or reject client -initiated sessions and associated data  that 8305  \ndo not pass session authentication.  8306  \nDCFFCOTS -R-9.10 Each PA shall be instantiated  as a separate process . 8307  \nDCFFCOTS -R-9.11 The high -side PAS shall retain locally stored audit log data for a minimum 8308  \nperiod of 30 calendar days . 8309  \nDCFFCOTS -R-9.12 The low -side PAS shall retain locally stored audit log data for ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}609{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "608", "chunk": "a minimum 8310  \nperiod of 30 calendar days . 8311  \nDCFFCOTS -R-9.13 The PA S shall store audit data locally using a periodic or size -based roll 8312  \nand retain model.  8313  \nDCFFCOTS -R-9.14 The PA S shall implement the data normalization function to convert fixed 8314  \nformat data into XML . 8315  \nDCFFCOTS -R-9.15 The PA S shall implement the data denormalization function to converted 8316  \nXML data into fixed format . 8317  \nDCFFCOTS -R-9.16 The PA S shall reject incoming messages from external entities  that do not 8318  \npass protocol specific authentication . 8319  \nDCFFCOTS -R-9.17 The PAS shall be able to support at least 64 concurrent XML dataflow s. 8320  \nDCFFCOTS -R-9.18 The high -side PAS shall enforce at least two-factor  authentication for local 8321  \noperating system authentication.  8322  \nDCFFCOTS -R-9.19 The low -side PAS shall enforce at least two-factor authentication for local 8323  \noperating system authentication.  8324  \nDCFFCOTS -R-10 The CDS components shall use  UDP -based SYSLOG to transfer logs off the 8325  \ncomponent . 8326  \nDCFFCOTS -R-11 The CDS shall use a passive one -way transfer (OWT) mechanism to transfer 8327  \ncomponent SYSLOG messages to the Defensive Cyberspace Operations enclave . 8328  \nDCFFCOTS -R-12 The CDS shall use the Cy", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}610{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "609", "chunk": "ber One -Way Taps Technical Requirements  8329  \ndocument DoD  for the implement ation  of the OWT . 8330UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 290 of 397 15.3 DCCDS -CD/TSB  Architecture Design Pattern  and Requirements  8331  \n(DCCDTSB ) 8332  \n15.3.1  Design Patterns  (DCCDTSB -P) 8333  \nDCCDTSB -P-1 The CDS shall implement one of the three Acceptable Design Patterns for 8334  \nrecursive decomposition engines: ADP -3, ADP -4, or ADP -5. 8335  \nDCCDTSB -P-2 The CDS shall implement an assured pipeline design  (ADP -2) for dataflow s 8336  \nprocessing complex data that use high-through put low-latency data types that do not 8337  \nrequire r ecursive decomposition. T hese dataflow s include video, audio, and images.  8338  \n15.3.2  Unique Requirements  (DCCDTSB -R) 8339  \nDCCDTSB -R-1 The Results Processor and Filter Report Validator process shall be  8340  \nindep endently implemented process es that do not share a common code base . 8341  \nDCCDTSB -R-2 In multi -domain CDS that implement  the ADP -3 or ADP -5, the CDS shall 8342  \nplace an independent  Filter Report Validator in the pipeline after t", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}611{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "610", "chunk": "he Domain Router to 8343  \nensure that each receiving domain  only receives con tent for which it is authorized,  that 8344  \nthe content  passed filtering, and that the correct filter policy was used.  8345  \n15.4 THA Architecture Design Patterns and Requirements  (THA)  8346  \nThis section has been merged with HWR to created HWCR.  8347  \n15.5 THA and HB Requirements  (HWR) 8348  \nThis section has been merged with THA to create HWCR.  8349  \n15.6 Connections between Unclassified /High Threat Network  and 8350  \nClassified  Networks  Requirem ents (CUCR) 8351  \nThis section  covers the requirements for Connections between U nclassified networks (including 8352  \nInternet and NIPRNet ) and other HTNs  and USG Classified Networks . 8353  \nCUCR -1 A single box software based CDS shall not be used for unidirectional  or bidirectional  8354  \nconnections between U nclassified and other HTNs  and USG Classified Networks.  8355  \nCUCR -2 The use of two CDS of the same lineage in series or two diverse CDS  in series shall 8356  \nnot be used in  series  for unidirectional  or bidirectional  connections between U nclassified  8357  \nand other High Threat Networks and USG Classified Networks  without the use of 8358  \nhardware -based  separation .  8359  \nClarification: Placing firewalls, ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}612{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "611", "chunk": "applicat ion gateways, or similar appliances between the 8360  \ntwo CDS does not alleviate this restriction.  8361UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 291 of 397 CUCR -3 The allowed CDS configurations for HTN to USG Classified networks in preferred 8362  \norder are:  8363  \nCUCR -3.1 Hardware -enforced separation mechanisms ( e.g., diode) with robust independent , 8364  \nredundant  filtering on both sides. This is a unidirectional  flow.  8365  \nCUCR -3.2 Two hardware -enforced separation m echanism s (e.g., diodes) with robust 8366  \nindependent, redundant filtering on low, high -receive, and high -transmit  shall be 8367  \nimplemented for bidirectional  flows . This means that there would be at minimum  three 8368  \nindependent redundant filters . 8369  \nCUCR -3.3 For hardware -enforced filtering and separation ( e.g., FPGA, but NOT software 8370  \nrunning on an FPGA, filtering would need to be in the VHDL code loaded on the FPGA) 8371  \nwith secondary software  filtering on high and low sides. This would support a 8372  \nbidirectional  flow.  8373  \nRationale:  These configurations are intended", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}613{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "612", "chunk": " to red uce the possibility that a single 8374  \nvulnerability could cause a fail -open condition that would effectively result in a direct 8375  \nconnection between a n HTN and a USG classified network.  8376  \nCUCR -4 The use of two diverse CDS in series  may be used if the unclassified  network is a 8377  \nGovernment  controlled  network and is a physically isolated  network ( e.g., no connection 8378  \ndirect/indirect to any other network including NIPRNet  or the Internet , 8379  \nVLAN /VXLAN253 and Virtual Routing and Forwarding (VRF)  is not sufficient  8380  \nseparation , IPSEC/MACSEC separation is not sufficient ).  8381  \nClarification: Diverse CDS means diversity in filters, orchestration,  operating system, 8382  \nand hardware. From a practical perspective , this is not achievable in most situations  8383  \ndue to the transition of USG operated CDS from  other operating systems to  Red Hat\u00ae  8384  \nEnterprise Linux\u00ae . Different versions of Red Hat\u00ae  Enterprise Linux\u00ae  do not count 8385  \nas different operating systems.  8386  \nCUCR -4.1 Use of hardware -based  separation for this environment is strongly encouraged.  8387  \nCUCR -5  In low -to-high configurations, t he Catcher must terminate the low -to-high transport 8388  \nprotocol (typically UDP/IP) and reconstruct ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}614{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "613", "chunk": "it to reduce protocol level attacks against the 8389  \nmulti -domain CDS.  8390  \n16 Testing  Requirements (DTR)  8391  \n16.1 Vendor Testing  Requirements  (VTR)  8392  \nVTR -1 The CDS  developer  shall perform  security control -based  testing  on the CDS  prior to 8393  \nsubmitting the CDS  for Independent Verification and Validation (I V&V ) testing or a 8394  \n \n253 VLAN (Virtual Local Area Network), VXLAN ( Virtual Extensible LA N)UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 292 of 397 Lab-Based Security Assessment . 8395  \nVTR -2 The CDS  developer  shall perform penetration  testing on the CDS prior to submitting the 8396  \nCDS for Independent Verification and Validation (IV&V) testing , MIL -STD 8397  \nconformance testing,  or a Lab-Based Security Assessment .  8398  \nClarification: Fuzzing the inputs for all protocol adapt ers, filters, and IPCs is strongly 8399  \nrecommended.  Pentration testing is also called adversarial emulation testing.  8400  \nVTR -3 The CDS developer shall perform functional and performance testing on the CDS prior 8401  \nto submitting the CDS for  IV&V tes ting or a Lab-B", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}615{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "614", "chunk": "ased Security Assessment . 8402  \nVTR -4 The CDS should undergo IV&V  testing prior to being submitted for MIL-STD 8403  \nconformance testing (if applicable) and for Lab-Based Security Assessment.  8404  \nRationale:  All environmental, physical, health, safety, MIL -STD/MIL -SPEC  8405  \nconformance , and C4ISR interoperability testing should be performed prior to any 8406  \nLBSA testing as they may result in changes to the CDS software that would 8407  \ninvalidate the  LBSA testing. In some c ases, LBSA testing might change the CDS 8408  \nsoftware such that previous functional tests may need to be rerun.  8409  \nVTR -5 If the developer desires for their test evidence to be considered for inclusion in 8410  \nsubsequent analyses (e.g., IV&V, LBSA, SB SA), the developer  shall provide  their test 8411  \nevidence to the CDS testing lab showing that the CDS was properly designed, 8412  \nimplemented and integrated . 8413  \nVTR -5.1 The body of test evidence shall, minimally, include confi gured instances of the system 8414  \n(and mock system environments), system components, build systems, etc. against which 8415  \nthe developer\u2019s test cases , positive and negative test data,  and test objectives were 8416  \nverified.   8417  \n16.2 Lab-Based Security Assessment (LBSA)  Require ments (", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}616{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "615", "chunk": "LBSAR)  8418  \nLBSAR -1 The CDS developer shall provide the necessary documentation and technical data 8419  \nrequired by the current NCDSMO  Security Assessment of Cross Domain Solutions 8420  \n(CDS): Process and Requirements  (NCDSMO -R-00002 -004_00), formerly the Lab- 8421  \nBased Security Assessment of Cross Domain Solution Process and Requirements  8422  \ndocument . 8423  \nLBSAR -2 Deleted , Duplicate of LBSAR -1. 8424  \nLBSAR -3 The CDS developer shall release the source code of the CDS to the NCDSMO - 8425  \napproved CDS testing laboratory for static analysis of the code and assessment of 8426  \nsoftware development and secure coding best practices . 8427  \nLBSAR -4 The CDS developer s hall provide s upport for installation of the CDS at the testing lab 8428  \nand training of the lab personnel on the CDS . 8429  \nLBSAR -5 The CDS developer shall attend the Security Design Review (SDR), Security Test ing 8430UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 293 of 397 Preparation Review (STPR), Test R eadiness Review  (TRR), and the Security  Assessment  8431  \nOutbrief  (SAO) . 8432  \nLBSAR -6 [~*/HB ]", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}617{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "616", "chunk": " If the CDS is software based, the  CDS developer  shall ensure that the 8433  \nsoftware CDS  can run on Red Hat\u00ae  8 KVM  to support LBSA testing . 8434  \nClarification:  If changes are required to enable virtualizing of the CDS for the test 8435  \nenvironment they must be documented clearly so the lab will understand the 8436  \ndifferences from the production configuration. However, it is strongl y encouraged 8437  \nthat CDS developers support production deployments of their CDS on virtualized 8438  \nenvironments including KVM.  8439  \nLBSAR -7 [~*/HB ] The CDS developer shall provide to the LBSA test lab a version of the CDS 8440  \nwith MAC policy disabled an d remote shell access to facilitate internal CDS testing. SSH 8441  \nis allowed to be installed on the CDS to support this testing.  8442  \nLBSAR -7.1  [~*/HB ] The CDS developer shall document all changes to the CDS to support the 8443  \ntesting of the MAC policy being disabled.  8444  \nLBSAR -7.2 [~*/HB ] If the CDS is based on Linux \u00ae, then SE Linux  should be placed in 8445  \npermissive mode and the process implementing OSSR -31.2 should be changed to check 8446  \nfor permissive mode (instead of enforcing) to enable the test lab to verify the OSSR -31.2 8447  \nprocess functionality.  8448  \nLBSAR -7.3 [~*/HB ] The CDS ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}618{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "617", "chunk": "developer must provide , in source and binary form , a tool that 8449  \ncan be used on the unlocked  version of the CDS to send any data (with no filtering or 8450  \nprocessing  of the test data performed  by the tool) to any IPC used by the CDS to transfer 8451  \ninformation ( e.g., CDS audit, CDS log, d ataflow data, etc.) inside the CDS.  8452  \nClarification: Unlocked version of a CDS is defined as an instance of a CDS with the 8453  \nMAC enforcement disabled (but possibly still in permissive mode254), integrity 8454  \nchecking disabled , and possibly other components that wou ld interfere with the 8455  \ntesting. All items that are disabled must be documented including how the disabling 8456  \nwas done.  8457  \nLBSAR -8 The CDS developer shall provide a direct point of contact in the CDS development 8458  \nand engineering team that can answer technical questions.  8459  \n16.3 Site-Based Security Assessment  (SBSA ) Requirements (SBSAR)  8460  \nSBSAR -1 The CDS developer shall  have the ability to  support the SBSA process at customer 8461  \ninstallation sites. 8462  \nSBSAR -2 The CDS devel oper shall develop a SBSA  Plan and Procedures (SBSAPP)  document 8463  \n \n254 https://access.redhat.com/documentation/en -us/red_hat_en terprise_linux/4/html/reference_guide/s2 -selinux -", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}619{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "618", "chunk": "files-\netcUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 294 of 397 to verify the CDS is installed and configured according to the documentation  and that the 8464  \nsite-related security controls i n the CDS Overlay are addressed . 8465  \nSBSAR -3  The CDS developer shall develop procedures for the SBSAPP to verify any 8466  \nAuthorizing Official required mitigations including  the Target of Risk Ass essment 8467  \n(TORA) constraints are implemented and operating correctly.  8468  \nSBSAR -3.1 For any issues found during LBSA that must be fixed or mitigated during the SBSA , 8469  \nthe CDS developer shall provide to the LBSA lab and the customer the positive and 8470  \nnegative test data and test procedures to verify the chang es that were made  to resolve the 8471  \nLBSA findings.  8472  \nSBSAR -4 The CDS developer shall develop procedures for the SBSAPP to verify the CDS is in 8473  \nits authorized state. This portion of the SBSAPP will be used by the Command Cyber 8474  \nReadiness Inspec tion (CCRI) process.  8475  \n17 Multi -Level Database Requirements (MLDBR)  8476  \nThis section covers the requirement", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}620{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "619", "chunk": "s for  the implement ation  of a multi -level database on a CDS 8477  \nor development of CDS that is a multi -level database.  This section assumes  the reader has read 8478  \nSection 14: Requirements for Multi -Level Security CDS (MLS) . 8479  \nMLDBR -1 [~*/HB, ~*/CCOTS]  ML Database systems shall comply with the requirements in 8480  \nSection 14: Requirements for Multi -Level Security CDS (MLS) . 8481  \nMLDBR -2 [~*/HB, ~*/CCOTS]  The Multi -Level  Database ( MLDB) MAC labels must map to  8482  \nand be bound to  the Operating System \u2019s MAC labels . 8483  \nMLDBR -2.1 [~*/HB, ~*/CCOTS]  If the MAC  labels are composed (e.g., the table has a label, 8484  \nand the row has a different label) the most restrictive label shall be used for on -disk file 8485  \nlabeling . 8486  \nMLDBR -2.2 [~*/HB, ~*/CCOTS]  The ML DB shall not store data directly on block devices 8487  \nwithout OS labeling and MAC . 8488  \nMLDBR -3 [~*/HB, ~*/CCOTS]  The ML DB processes directly responsible for storing  data, 8489  \nmodifying data, retrieving  data, and managing the database shall not bind directly  to 8490  \nphysical network interfaces . This is sometimes called background processes.  8491  \nMLDBR -3.1 [~*/HB, ~*/CCOTS]  Protocol adapter proces ses shall be used between the network 8492  \ninterface and", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}621{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "620", "chunk": " the MLDB process es. 8493  \nMLDBR -3.2 [~*/HB, ~*/CCOTS]  The protocol adapter  shall decode the protocol, verify the 8494  \nprotocol messages , and retransmit them to the MLDB . 8495  \nMLDBR -3.3 [~*/HB, ~*/CCOTS]  An inline filter  between the protocol adapter and database 8496  \nshall enforce the grammar and syntax of the DB query languag e. 8497  \nMLDBR -3.4 [~*/HB, ~*/CCOTS]  The protocol adapter shall run as a different DAC user and 8498UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 295 of 397 MAC role than the MLDB . 8499  \nMLDBR -3.5 [~*/HB, ~*/CCOTS]  The protocol adapter shall decrypt the network traffic 8500  \ndestined to the MLDB  so that it can be filtered . 8501  \nMLDBR -3.6 [~*/HB, ~*/CCOTS]  The database logging subsystem  shall have the ability to  8502  \nredact string literals embedded in database queries from being sent to log/audit . 8503  \nRationale:  This is necessary to prevent  sensitive strings ( e.g., plaintext passwords ) from 8504  \nbeing stored in log files . 8505  \nMLDBR -3.7 [~*/HB, ~*/CCOTS]  The inline query grammar and syntax filter shall be an 8506  \nindepen dent implemen", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}622{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "621", "chunk": "tation from the MLDB  query grammar and syntax validation 8507  \nroutines.  8508  \nMLDBR -4 [~*/HB, ~*/CCOTS]  The MLDB  role and levels shall be bound to an OS MAC role 8509  \nand label . 8510  \nMLDBR -4.1 [~*/HB, ~*/CCOTS]  The DB role and levels M AC model shall be mirrored by the 8511  \nOS MAC . 8512  \nRationale:  If the database server enforces that a user logged in at a particular level may 8513  \nnot see a piece of data, the OS must also enforce that the user logged in at that level 8514  \nmay not bypass the database server and see the data . 8515  \nMLDBR -4.2 [~*/HB, ~*/CCOTS]  DB processes that are connected to  clients shall be labeled 8516  \nthe same as that  client\u2019s role and levels . 8517  \nMLDBR -4.2.1 [~*/HB, ~*/CCOTS]  The client -associated process shall not be ranged unless the 8518  \nuser and network label are specifically permitted to be ranged . 8519  \nMLDBR -4.2.2 [~*/HB, ~*/CCOTS]  The ranged client -associated process  shall  only operate at 8520  \none level at a time . 8521  \nMLDBR -4.3 [~*/HB, ~*/CCOTS]  The OS MAC shall be used to enforce  access between the  8522  \ndatabas e client\u2019s backend  processes and on -disk database files  to ensure a database 8523  \nclient\u2019s backend cannot access on -disk database files for which it does not have the right 852", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}623{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "622", "chunk": "4  \nlevels.  8525  \nMLDBR -5 [~*/HB, ~*/CCOTS]  The MLDB  shall use single -level NICs with labels set by the 8526  \nOS MAC and with client levels on that NIC enforced by the OS MAC. For example, if a 8527  \nNIC is labeled green, any client logging in over that NIC shall not get a label other than 8528  \ngreen . 8529  \nMLDBR -5.1 [~*/HB, ~*/CCOTS]  In cases of a trusted MLS network , ranged N ICs must use 8530  \nCIPSO  (for I pv4), CALIPSO  (for I pv6), Labeled IPSec , or the Technical Standard for 8531UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 296 of 397 SOSA \u2122 Reference Architecture  Edition 2.0255, version 2, sections 12.3.1  (for layer 2 8532  \nlabelling) . The OS shall enforce the configured range per NIC . 8533  \nMLDBR -6 [~*/HB, ~*/CCOTS]  Database worker processes256 shall only be ranged if the 8534  \nfollowing criteria are met:  8535  \nMLDBR -6.1 [~*/HB, ~*/CCOTS]  The minimum range must be used to accomplish the required 8536  \ntask. 8537  \nMLDBR -6.2 [~*/HB, ~*/CCOTS]  Database worker processes shall not  directly interact with  8538  \nusers.  8539  \nMLDBR -6.3 [~*/HB, ~*/CCOTS]  Database wor", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}624{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "623", "chunk": "ker processes shall not bind to network 8540  \ninterfaces . 8541  \nMLDBR -6.3.1 [~*/HB, ~*/CCOTS]  The management NIC may be used by ranged workers for 8542  \nmanagement functions such as statistics, logging, alerts, etc.  8543  \nMLDBR -6.3.2 [~*/HB, ~*/CCOTS]  A ranged replication worker can use a dedicated NIC that is 8544  \nsolely used for replication to another MLDB . 8545  \nMLDBR -7 [~*/HB, ~*/CCOTS]  MLDB  clients shall only be able to query data at their  current 8546  \nlevel (read equality) or lower (read down). Read down shall only be allowed under the 8547  \nfollowing conditions:  8548  \nMLDBR -7.1 [~*/HB, ~*/CCOTS]  If the data is considered known good, which is satisfied by 8549  \nany one of the following : 8550  \nMLDBR -7.1.1 [~*/HB, ~*/CCOTS]  The data has been filtered by an NCDSMO evaluate d CDS  8551  \n(using an appropriate low -to-high dataflow policy)  prior to storage in the database or  has 8552  \nbeen filtered via an NCDSMO evaluated  filtering system  (e.g., sidecar)  that is connected 8553  \nto the MLDB . 8554  \nMLDBR -7.1.2 [~*/HB, ~*/CCOTS]  The data is initialization data, written by application 8555  \ninstallers or configuration tools before production data is inserted into the MLDB . 8556  \nMLDBR -7.1.3 [~*/HB, ~*/CCOTS]  Data is labeled as f iltered ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}625{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "624", "chunk": "and was produced by a known 8557  \nhigh integrity system and ingested into the database specifically through a high integrity 8558  \ndata channel . 8559  \nClarification:  A high integrity system is defined as a system that only 8560  \ngenerates/provides known good data.  High i ntegrity data is defined as data that is 8561  \nknown to be good.  8562  \nMLDBR -7.1.4 [~*/HB, ~*/CCOTS]  Data is highly constrained by the database schema and 8563  \n \n255 Specifically, sections 12.3.1.3.4.6 and 12.3.1.3.5.1 . SOSA does include support for CALIPSO and CIPSO. But \nthey are explicitly included here to avoid confusion with previous version of the RTB.  \n256 Database workers are generally considered background database processes.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 297 of 397 consists of only fixed format data types (e.g., int/float, Boolean, date/timestamp, 8564  \ngeometric, and geographic) and not freeform data types (e.g., text, varchar, byte array, 8565  \nchar longer than 32 bytes).  8566  \nMLDBR -7.2 [~*/HB, ~*/CCOTS]  The level that is initiatin g the read down completely and 8567  \nunequivocally dominat", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}626{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "625", "chunk": "e s the lower domains.  8568  \nClarification:  If a process running at Secret USA reads down to Secret REL Coal ition A 8569  \n(which USA is a member)  then that would be allowed subject to the other 8570  \nrequirements above. However , a process runni ng at Top Secret REL USA, ABC  and 8571  \nABC  is not a member of Coalition A then that process cannot read down into the 8572  \nSecret REL Coalition A.  8573  \nMLDBR -8  [~*/HB, ~*/CCOTS]  Data that is ingested as low or unknown integrity may be 8574  \nrelabeled to high integrity  if it has been  filtered by an NCDSMO evaluated  CDS (using 8575  \nan appropriate low -to-high dataflow policy) prior to storage in the datab ase or has been 8576  \nfiltered via an NCDSMO  evaluated  filtering system (e.g., sidecar) that is connected to the 8577  \nMLDB . 8578  \nMLDBR -9 [~*/HB, ~*/CCOTS]  MLDB  clients shall not be able to write up or write down 8579  \n(write equality) . 8580  \nMLDBR -9.1 [~*/HB, ~*/CCOTS]  If the MLDB  client is MLS aware, permitted to connect over 8581  \na ranged, labeled network connection, and logged in as a role with ranged permission , it 8582  \nmay write data at multiple levels by changing its session label before inserting data. This 8583  \npermission only applies to MLS aware environments where all components pr", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}627{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "626", "chunk": "oducing 8584  \nMLS data are at the same integrity level and perm itted to produce data within their range . 8585  \nMLDBR -10 [~*/HB, ~*/CCOTS]  The MLDB  may provide trusted facilities (e.g., trusted stored 8586  \nprocedures) that can write down configuration data that must be labeled System Low for 8587  \ncorrect functionali ty. 8588  \nRationale:  Some data stored in databases is used as app configuration data, user profile 8589  \ndata, or miscellaneous support data, and must be available to all users regardless of 8590  \nlevel. This data cannot be classified and therefore must be filtered as a hig h to low 8591  \ntransfer to ensure that data is not leaked. Moreover, since even something innocuous 8592  \nas user preference for light or dark mode can be used as a back -channel , trusted 8593  \nfacilities should take data rate into account.  8594  \nMLDBR -10.1 [~*/HB, ~*/CCOTS]  The trusted facilities shall  filter data as high -to-low (see 8595  \nMLDBR -7 requirements ). 8596  \nMLDBR -10.2 [~*/HB, ~*/CCOTS]  The trus ted facilities shall be part of the target of eval uation 8597  \nduring at LBSA . 8598  \nMLDBR -10.3 [~*/HB, ~*/CCOTS]  The trusted facilities shall  audit all invocations . 8599  \nMLDBR -11 [~*/HB, ~*/CCOTS]  Database objects which act as containers and not data, su", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}628{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "627", "chunk": "ch as 8600  \nschemas, databases, tables, and columns shall have labels that dominate any possible data 8601UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 298 of 397 stored within them . 8602  \nMLDBR -12 [~*/HB, ~*/CCOTS]  The filtering CDS or filtering Sideca r shall be connected to 8603  \nthe MLDB  via a dedicated NIC that only allows communication between the MLDB  and 8604  \nthe CDS.  8605  \nMLDBR -13 [~*/HB, ~*/CCOTS]  MLDB should support the NC DSMO\u2019s  Filter Sidecar 8606  \nProtocol (FSP )257 to communicate with a filtering sidecar.  8607  \nMLDBR -14 [~*/HB, ~*/CCOTS]  The data being filtered shall be locked such that no changes 8608  \ncan be made to that data while the data is being filtered.  8609  \nMLDBR -15 [~*/HB, ~*/CCOTS]  Relabeling decisions, including filtering reports (e.g., 8610  \nNCD SMO\u2019s VIS Report s), shall be stored until the Log Admin archives and deletes 8611  \nthem.  8612  \nMLDBR -16 [~*/HB, ~*/CCOTS]  All of the data being relabeled shall be sent to the filtering 8613  \nCDS or filtering Sidecar , not a subset (e.g., only sending the contents of a data column 8614  \nwhen there are o", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}629{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "628", "chunk": "ther metadata columns present) . 8615  \nMLDBR -17 [~*/HB, ~*/CCOTS]  Clients sh all not be able to log directly in to the database as a 8616  \ndatabase administrator  and a role transition must be done once the user has logged in 8617  \nwithout privileges.  8618  \nMLDBR -18 [~*/HB, ~*/CCOTS]  All database administrator operations  (e.g., commands and 8619  \nqueries ) shall be audited.  8620  \nMLDBR -19 [~*/HB, ~*/CCOTS]  The database shall enforce TKPC for changes to database 8621  \naudit levels . 8622  \nMLDBR -20 [~*/HB, ~*/CCOTS]  The database role that creates database objects (e.g., 8623  \ndatabases, tables, and schemas) shall not provide initial security labels . 8624  \nMLDBR -20.1 [~*/HB, ~*/CCOTS]  A different user in a separate role (e.g., secadm or 8625  \ndbsecadm) shall specify initial database object labels . 8626  \nMLDBR -20.2 [~*/HB, ~*/CCOTS]  Data Definition Language258 (DDL) modifications that 8627  \naffect labeling or security (e.g., adding columns, changing column data types, altering 8628  \nfunctions, etc .) shall  be approved by a different user in a separate role ( e.g., secadm or 8629  \ndbsecadm ) role. 8630  \nMLDBR -21 [~*/HB, ~*/CCOTS]  The role that creates database users shall not assign security 8631  \nroles or levels . 8632  \nMLDBR -21.1 [~*/HB, ~*/CCO", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}630{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "629", "chunk": "TS]  A separate role ( e.g., secadm or dbsecadm ) must approve 8633  \n \n257 Filter Sidecar Protocol (FSP) Specification , NCDSMO Doc ID: NCDSMO -S-00002 -001_06 , Version 1.0.6 or \nhigher  \n258 https://en.wikipedia.org/wiki/Data_definition_languageUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 299 of 397 user additions and set the level and role, which must then be approved by another admin . 8634  \nMLDBR -22  [~*/HB, ~*/CCOTS]  A database instance operating at different security 8635  \nclassification  levels  and relea sabilities shall use partitioned tables with separate files for 8636  \neach combination of security classification level  (e.g., unclassified, restricted, 8637  \nconfidential, secret, and top secret)  and rele asability (e.g., NO FORN, REL FVEY, REL 8638  \nNATO, REL JPN ). 8639  \nMLDBR -23 [~*/HB, ~*/CCOTS]  A database instance operating at different security 8640  \nclassification and different handling caveats (e.g., FOUO, LES, PROPIN, ORCON) , 8641  \nSAPs, or SCI Compartments may share the same partition and files for each security 8642  \nclassification level.  8643  \n18 Multi -Level Switc", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}631{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "630", "chunk": "h and NIC Requirements (MLS WNR) 8644  \nThis section covers requir ements for multi -level switches and multi -level network interface cards 8645  \n(NIC) . A multi -level switch is a  network switch (e.g. , Ethernet switch)  that is capable of 8646  \nenforcing sepa ration of network data within the network switch based on labels appl ied to 8647  \nnetwork packets. Some multi -level  (ML)  switches also have the ability to apply label s to packets 8648  \non specific switch ports \u2013 usually because the device attached to that does not have the ability to 8649  \nlabel packets or is not trusted sufficiently to do  so securely.  MLS switches implement the la bel 8650  \nprocessing in hardware . A ML  NIC is a device t hat uses hardware to apply labels to  outbound  8651  \npackets based on a de fined set of cr iteria.  8652  \nMLSW NR-1 [~*/CCOTS]  Multi -level swi tches and ML NICs must implement all security label 8653  \nchecking and assign ment in hardware.  8654  \nMLSW NR-1.1 [~*/CCOTS]  VHDL based FPGA logic or a custom Application -Specific 8655  \nIntegrated Circuit  (ASIC ) are allowed  hardware enforcement mech anisms . 8656  \nMLSW NR-1.2 [~*/CCOTS]  Software running on a soft core CPU  on an FPGA  for the purposes 8657  \nof enforcing or assigning security lab els is not allowed. ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}632{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "631", "chunk": " 8658  \nMLSW NR-2 [~*/CCOTS]  Multi -level switch es or multi -level NICs shall not allow any 8659  \nunlabeled packets to transit the switch  or NIC  except for IETF RFC 826 Address 8660  \nResolution Protocol  (ARP) , IEEE 1588 -2008 Precision  Time Protocol (PTP) or higher ,  8661  \nIETF RFC 3376 Internet Group Management Protocol , Version 3 (IGMPv3)259, and IETF 8662  \nRFC 3810  Multicast Listener Discovery Version 2 (MLDv2) for I pv6. 8663  \nClarification: For Multicast packets, MLS labeling of the actual multicast packets is still 8664  \nrequired.  8665  \nMLSWNR -2.1 [~*/CCOTS]  If ARP , PTP, IGMP, and MLD  are used, then the packets must be 8666  \n \n259 Includes  IETF RFC 4604 Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast \nListener Discovery Protocol Version 2 (MLDv2) for Source -Specific MulticastUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 300 of 397 syntactically and semantically filtered by the ML Switch  before delivery to any devices.  8667  \nMLSW NR-2.2 [~*/CCOTS]  IEEE -1588 -2002 PTP v1 shall not be used.  8668  \nMLSW NR-3 [~*/CCOTS]  Multi -level switches may us", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}633{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "632", "chunk": "e commercial FPGA or ASIC switching 8669  \nlogic . 8670  \nMLSW NR-3.1 [~*/CCOTS]  If commercial switching logic is used then all label assignment, 8671  \nvalidation, and constraint enforcement check s must be implemented in hardware - 8672  \nenforced logic separate from the commercial switching logic . 8673  \nClarification:  The label assignment, validation and constraint en forcement logic can be 8674  \non the same FPGA as the commercial switching logic .  8675  \nMLSW NR-4 [~*/CCOTS]  Multi -level switches and ML NICs shall allow their security 8676  \nconfiguration to be managed either via an out -of-band interface and not over the primary 8677  \ndata network channel, or in -band over the primary network channel but with a 8678  \ncryptographic authentication/integrity mechanism applied to the configuration and then 8679  \nverified by the MLS Switch/NIC.  8680  \nMLSWNR -4.1  If an in -band interface is used to manage security configuration, the root of trust 8681  \nfor the cryptographic authentication/integrity verification shall be configured on the MLS 8682  \nSwitch/NIC via an out -of-band path that is not the primary network channel . 8683  \nMLSW NR-5 [~*/CCOTS]  Multi -level switches and ML NICs shall use  for IPv6 Layer 3 labeled 8684  \nnetwork packets , CIPSO for IPv4 for L", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}634{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "633", "chunk": "ayer 3 labeled network packets , or the Technical 8685  \nStandard for SOSA \u2122 Reference Architecture  Edition 2.0260, version 2, sections 12.3.1  for 8686  \nLayer 2 labeling  network packets.  8687  \nMLSWNR -6 [~*/CCOTS]  If a COTS swit ch is used then only ML  NICs shall be used with 8688  \nlabeled data and the ML NICs shall implement a cryptographic based integrity check for 8689  \nthe MLS data to prevent alteration of the labels in the COTS switch.  8690  \nMLSWNR -6.1 [~*/CCOTS]  The ML  NIC shall either digitally sign the MLS label or use either 8691  \na HMAC or a GMAC of the MLS label with a shared secret between ML NICs  to prevent 8692  \nundetected alteration of the MLS label by the COTS switch.  8693  \nMLSWNR -7 Deleted . 8694  \nMLSWNR -8 [~*/CCOTS]  The default state for a ML NIC and ML  Switch shall be to  deny all 8695  \n(e.g., not transfer data)  traffic until it has  initialized  (e.g., booted)  to a point where labels 8696  \ncan be applied  and verified.   8697  \nMLSWNR -9 [~*/CCOTS]  Multi -level switches and ML NICs shall not  regrade /relabel  data or 8698  \nallow data (e.g. , network packets) to be read-up, read -down, write -up, or write -down.  8699  \n \n260 Specifically,  sections 12.3.1.3.4.6 and 12.3.1.3.5.1 . SOSA does include support for CALIPSO and CIPSO. ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}635{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "634", "chunk": "But \nthey are explicitly included here to avoid confusion with previous version of the RTB.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 301 of 397 Clarification:  Because regr ading/relabeling is not allowed this means that an ML Switch 8700  \nor ML NIC are not considered a Transfer CDS but instead similar to a n MLS 8701  \nRepository.   If relabeling, read -up, read -down, write -up, or write -down functions are 8702  \nrequired then the MLS Switch should be integrated with a Transfer CDS.  8703  \nMLSWNR -10 A ML NIC shall  only allow  inbound (from the network) packets that are labelled 8704  \nwith label s appropriate for the system containing the ML NIC . 8705  \nClarification : This does not apply to protocols lis ted in MLSWNR -2. 8706  \nMLSWNR -11 A ML NIC shall appear as multiple (based on the number of configured levels in 8707  \nthe NIC) independent single level NICs to the operating system containing the ML NIC.  8708  \nMLSWNR -11.1 Systems using ML NICs shall use MAC to apply labels to single level NIC 8709  \ndevices exposed by the ML NIC and it shall enforce access to the single level NICs with ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}636{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "635", "chunk": "8710  \nMAC.  8711  \nMLSWNR -12 ML switches and ML NICs shall ensure  integrity of labels using standards -based 8712  \nGalois Message Authentication Code (GMAC)261 authentication  mechanisms such as 8713  \nIPSEC Authentication Header (AH)  (see RFC 4543262, RFC 4302 ) or MAC sec263. 8714  \n19 CDS Management System Requirements (CMSR)  8715  \nThis section covers the security requirements for CDS Management Systems  (CMS)  used in 8716  \nEnterprise, Point -to-Point, and Tactical CDS deployments.  Because CMS are able to change the 8717  \nstate and configuration of the CDS  remote ly and in some instances, generate new CDS dataflow  8718  \npolicy , they must  adhere to the same core security requirements as the CDS.  This section does 8719  \nnot apply to CDS monitoring systems  that are receiving data from the CDS and not controlling 8720  \nthe CDS . The types of functions provided by a CMS  include but are not limited to:  8721  \n1. Creation , editing , and approval (automating the process) of CDS dataflow  policy files  8722  \n2. Distrib uting  CDS dataflow  policy files to a CDS  8723  \n3. Enabling, disabl ing, retiring, delet ing, startin g, and sto pping dataflows on a CDS  8724  \n4. Pushing software , patches , antivirus definition s, or analytics264 to a CDS for installation ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}637{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "636", "chunk": " 8725  \n5. Request ing SCAP scans and C3R reports  8726  \n6. Shutting down  and reboot ing a CDS  8727  \n \n261 NIST SP 800 -38D, \" Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and \nGMAC \u201d, Novem ber 2007, https://csrc.nist.gov/publications/detail/sp/800 -38d/final  \n262 IETF RFC 4543, \u201c The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH \u201d \nhttps://tools.ietf.org/html/rfc4543  \n263 802.1AE: Media Access Control (MAC)  Security (MACsec) , https://1.ieee802.org/security/802 -1ae \n264 Analytics in this case primarily applies to analytics running in the EM/PE portion of the JAL subsystem and are \nused for CDS self -defense.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 302 of 397 7. Changing performance and tuning parameters on a CDS  8728  \n8. Modifying user accounts on a CDS  8729  \n9. Modifying network configuration settings on a CDS  8730  \n10. Updating PKI Certificates on a CDS  8731  \n11. Push ing new or updated Virtual Machines to a n Access CDS  8732  \n12. Providing remote  network boot  services (P XE or UEFI HTTP Boot) to support over -the- 8733  \n", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}638{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "637", "chunk": "network CDS software installation  8734  \n13. Receiving  JAL data from the  CDS  and including via SYSLOG and JALoP  8735  \nCreation of policies off a CDS, perhaps on a Microsoft  Windows \u2122 or Linux workstat ion, that 8736  \nare delivered to the CDS via removable media is now considered a CMS.  In the past, the 8737  \nconfiguration workstation was outside the TOE and was not assessed  during LBSA .  That will no 8738  \nlonger be the case.  The use of a configuration management workstati on requires conformance 8739  \nwith these requirements.  8740  \nThe CMS is an implementation of the privileged access workstation (PAW)265 concept widely 8741  \nused in commercial information technology and cloud computing environments.  8742  \n 8743  \nThere are two categories of CMS:  8744  \n1) CMS Application  (CMS -A) that runs on a user\u2019s workstation to generate and approve a 8745  \nconfiguration for the CDS. The configuration is then transferred to the CDS via 8746  \nremovable media  (e.g., CD, DVD, or Dongle. See SASR -5) 8747  \n2) CMS Server (CMS -S) that is a secured locked down system that configures and manages 8748  \nthe CDS via a network connection . 8749  \nIn the CMS requirements below CMS -A, CMS -S, and CMS -Both  designate the applicability of a 8750  \nrequirement.  8751  \n 8752  \n", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}639{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "638", "chunk": "CMSR -1  CMS shall implement the requirements in following sections : 8753  \nCMSR -1.1 CMS -S: NRR, SCR, GAR, C2R, OSSR, SASR, DPMR, SIHCR, PIR, RBAC R, 8754  \nEDSR, SIR, JALSR, RMANR, RMONR , VTR,  LBSAR, and SBSAR.  8755  \nClarification: Due to the  uniqueness of CMS, please contact the NCDSMO for tailoring 8756  \nguidance on the individual requirements to implement for each of the requirements 8757  \nsections.  8758  \nCMSR -1.2 CMS -A: RBACR, EDSR , JALSR (subset)  8759  \nCMSR -2 A CMS -S may operate on a hypervisor;  however,  the hypervisor must be dedicated to 8760  \n \n265 https://thycotic.com/glossary/privileged -access -workst ations -paws  and https://docs.microsoft.com/en -\nus/security/compass/privileged -access -devicesUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 303 of 397 the CMS function . 8761  \nClarification:  A CMS -A could technically be virtualized if the client operating system 8762  \nis operating on a hypervisor  (e.g., a thin client connecting  to VMware \u2122 ESXi  hosted 8763  \nWindows 10 \u2122 instance ). 8764  \nCMSR -3 A CMS -S should support remote installation of the CDS software from ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}640{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "639", "chunk": "the CMS . 8765  \nCMSR -3.1 A CMS -S may be the PXE installation server for CDS that are using PXE for over- 8766  \nthe-network installation of CDS software . 8767  \nCMSR -3.2 A CMS -S should be the UEFI HTTP Boot server for CDS that are using UEFI HTTP 8768  \nBoot for over -the-network installation of CDS software . 8769  \nCMSR -4 A CMS -S shall only be connected to the CDS management OOB  network . 8770  \nCMSR -4.1 The CDS m anagement  network  may be distributed across multiple sites ; however , an 8771  \nNSA certified Type -1 cryptographic  device must be used  to protect the site -to-site 8772  \ncommunications . 8773  \nCMSR -4.1.1  If the CDS management network and system high user network are t he same 8774  \nclassification and the CDS management network needs to be tunnel ed over the user 8775  \nnetwork , then a single layer CSfC  compliant IPSEC or MACSEC tunnel shall be used to 8776  \nseparate the CDS management network from the user network .  8777  \nClarification:  Operating the CDS management network over the system high user 8778  \nnetwork is strongly discouraged and should only be used in cases where the re is no 8779  \nother option. For example, the CDS is located in a remote facility and the only remote 8780  \naccess i s via the system high user network.  8781  \nCM", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}641{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "640", "chunk": "SR -4.2 The clustering of CMS servers within the Management network may be 8782  \nimplemented.  8783  \nCMSR -4.2.1 CMS clustering communications shall  be encrypted  and in accordance with EDSR 8784  \nrequirements.   8785  \nCMSR -4.3 The management network should have a local Certificate Authority that support s 8786  \nCertif icate Revocation Lists (CRL) . 8787  \nRationale:  This is primarily used to support validation of the revocation status  of 8788  \ncertificates used by signers of configuration content (e.g., dataflow configuration) 8789  \nbeing sent to the CDS. It could also be used to  validate the certificates of other IT 8790  \nassets on the management OOB that the CDS might be communicating with.  8791  \nCMSR -4.3.1 The CDS shall validate t he revocation status of certificates used to sign 8792  \nconfiguration content originating from a CMS.  8793  \nCMSR -5 CMS -Both  software  shall not have the ability to digitally sign CDS configuration  files 8794  \nwithout first requiring  the CDS administrators to provide a passphrase (s) to unlock  their 8795  \nsigning certificates.  8796UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}642{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "641", "chunk": ", NOR, SAU, SWE, QAT  \nPage 304 of 397 CMSR -6 The CMS -S should use the GRMP to remote ly manage the CDS.  8797  \nCMSR -7 If the CMS -S supports log retrieval from the CDS, the CMS shall support JALoP.  8798  \nCMSR -8 If the CMS -S supports log retrieval from the CDS, the CMS should support SYSLOG 8799  \n(see section RMONR -3 for specific SYSLOG requirements ). 8800  \nCMSR -9  The CMS -S may be a portable device (e.g., a laptop).  8801  \nCMSR -9.1 If the CMS -S is a portable device, it shall implement a CSfC approved DAR 8802  \nsolution . 8803  \nCMSR -9.2 If the CMS -S is a portable device,  it shall implement two factor authentication with a 8804  \nhardware token or card.  8805  \nCMSR -10 If GRMP is used to manage a CDS, the CMS -S shall be the remote controller for 8806  \nGRMP.  8807  \nCMSR -11 The CMS -S should  support the addition of USG provided insider threat monitoring 8808  \nsystem ; however , that must be done in coordination with the CDS vendor to ensure 8809  \nproper MAC, DAC, SECCOMP, SIC/CIC, and other platform security requirements are 8810  \nimplemented to prevent ex ploitation of the CMS via the insider threat monitoring system . 8811  \nCMSR -12 The CMS -Both shall support the creation, editing, verification, and approval of CDS 8812  \nsystem and dataflow config", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}643{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "642", "chunk": "uration.  8813  \nCMSR -13 The CDS  must generate a public/private key pair that is used to encrypt the 8814  \nconfiguration in the CMS -A for that specific CDS instance . 8815  \nCMSR -13.1The CDS public key shall be used by the CMS -A to encrypt the CDS configuration 8816  \ndata.  8817  \nCMSR -14 The CMS -A must use the following sequence for signing and encrypting the CDS 8818  \nconfiguration bundle: sign unencrypted configuration bundle with a user certificate in 8819  \nrole making the changes, encrypt the confi guration with the public key of the CDS, and 8820  \nsign the encrypted configuration bundle with user in an approval role.  8821  \nCMSR -15 The CMS-A must have ability to import certificates for users assigned to roles .  8822  \nCMSR -16 The CMS -A must implement TKPC and one of the RBACR -2 approaches.  8823  \nClarification: RBACR -2.1 is the recommended TKPC approach for a CMS -A.  8824  \nCMSR -17 The CMS -A must have the ability to have multiple users per role . 8825  \nCMSR -18 The C MS-A must have the ability to generate certificates that are assigned to users in 8826  \na specific role.  8827  \nCMSR -19 The CDS must have the ability to import CMS -A user certificates.  8828  \nCMSR -20 The CMS -A shall have a mechanism  ensure that only users in the correct role can ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}644{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "643", "chunk": "8829  \nperform the functions and signing associated with that role.  8830UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 305 of 397 CMSR -21 The CDS shall have a mechanism ensure that only users in the correct role can 8831  \nperform the functions and signing associat ed with that role.  8832  \nCMSR -22 The CMS -A must log all change and approval actions to the native operating system  8833  \naudit/logging system on which it is running . 8834  \nClarification:  Examples of the native operating system audit/logging would be journald 8835  \non Linux or Windows \u2122 Event Log.   8836  \nCMSR -23 The CMS -A must be a graphical user interface . 8837  \n 8838  \n20 Access CDS Specific Requirements (ACDSR)  8839  \nThis section covers the Access CDS specific requirements. This augments but does not replace 8840  \nother requirements in this document. See Appendix C \u2013 RTB Requirements Mapping for Access 8841  \nCDS  for a table that identifies the  requirements sections in RTB that apply to Access CDS.  As a 8842  \nreminder , the OWT section (of particular note: OWT -8 and OWT -17/17.1)  applies to Access 8843  \nCDS.  8844  \n", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}645{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "644", "chunk": "ACDSR -1 Access CDS shall require multi -factor user authentication  to the Access CDS 8845  \nsoftware prior to allowing the user access to or knowledge of any security domains 8846  \nhosted on (e.g., via VMs) or provided to (e.g ., via VDI) the device.  8847  \nACDSR -2 Access CDS shall  not provide access to (e.g., potential ability to log into the VM or 8848  \nVDI session) or knowledge of security domain s to which the  user is not entitle d to login . 8849  \nACDSR -3 Access CDS implementing a CSfC remote access solution  (e.g., Mobile Access 8850  \nCapability Package)  shall not start the VPN tunnels until a user has authenticated with 8851  \neither the Access CDS software  or DAR solution.  8852  \nACDSR -3.1 Access CDS implementing a CSfC remote access solution shall provide a 8853  \nmechanism to enter the passphrase to unlock each of the VPN encryption keys . 8854  \nACDSR -3.2 Access CDS, implementing a CSfC remote access solution, shall not automatically 8855  \nstart the VPN  tunnels  without requiring entry of the passphrase to unlock the VPN 8856  \nencryption keys.  8857  \nACDSR -4 Access CDS, shall provide a mechanism to enforce hardware -based two factor 8858  \nauthentication to the Access CDS software.  8859  \nACDSR -4.1 Deleted.  8860  \nACDSR -5 Access CDS shall imple", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}646{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "645", "chunk": "ment a CSfC approved DIT solution when used in a CSfC 8861  \nconfiguration to access classified networks while operating outside of a facility 8862  \nauthorized for open storage of classified material . 8863  \nACDSR -6 Access CDS shall implement a CSfC approved DAR solution when used to process 8864UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 306 of 397 classified information or access  classified networks while operating outside of a facility 8865  \nauthorized for open storage of classified material . 8866  \nACDSR -7 Access CDS when used outside of a facility authorized for open storage of classified 8867  \nmaterial shall not boot until a passphrase266 is entered to decrypt the boot device.  8868  \nACDSR -8 The Access CDS vendor shall be responsible for  developing and maintaining 8869  \n(providing software updates and patches) any CSfC VPN virtual machines  operating on 8870  \ntheir Access CDS.  8871  \nClarification:  The development of CSfC VPN VMs should be done in close coordination 8872  \nwith a CSfC Trusted Integrator267 to ensure compliance with CSfC guidance and 8873  \npolicy documents.  The cont", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}647{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "646", "chunk": "ents of CSfC VPN VMs are not part of the LBSA 8874  \nevaluation of the CDS but they are part of any SBSA. It is recommended that if the 8875  \nAccess CDS is being used as part of the CSfC solution that the VPN VMs be 8876  \nprovided to properly validate the DAC/MAC isolation and flow enforcement  from  the 8877  \nguest VM s through the two VPN VMs down to the NIC. Failure to provide the VPN 8878  \nVMs may increase the time necessary to validate the secure operation of the system.  8879  \nACDSR -8.1 The Access CDS CSfC  VPN shall only use VPN clients that have been evaluated 8880  \nby NIST and NIAP  in accordance with NSA\u2019s CSfC policies related to VPN clients.  8881  \nACDSR -8.2 The Access CDS shall ensure that the VPN VMs are read -only during operation and 8882  \nthat logs are transferred to the host Access CDS for transfer off the system  during the 8883  \noperation of the VPN VMs.  8884  \nACDSR -8.3 The Access CDS shall filter logs from the VPN VM to prevent a compromi se of the 8885  \nAccess CDS JAL subsystem  8886  \nACDSR -8.4 The Access CDS vendor shall only deploy VPN clients on operating systems for 8887  \nwhich it has been evaluated by the VPN vendor, NIST, and NIAP.  8888  \nACDSR -8.5 The Access CDS vendor shall provide a mechanism to \u201cside -load\u201d the networking 8889  ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}648{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "647", "chunk": "\nand VPN client configuration including the certificates into the VPN VMs from the host 8890  \nAccess CDS.  8891  \nACDS R-8.6 The Access CDS VPN VM operating system shall be locked down in accordance 8892  \nwith the DISA STIGs.  8893  \nACDS R-8.7 The Access CDS VPN VM shall use a  minimal size operating system image with 8894  \nonly enough  applications and libraries necessary to support the VPN VM functions and 8895  \nthe necessary support functions (e.g., sending logs to the Access CDS host, updating its 8896  \nconfiguration from the Access CDS host).  8897  \n \n266 A passphrase could be a token with PIN, smartcard with PIN, or similar mechanism.  \n267 https://www.nsa.gov/Resources/Commercial -Solutions -for-Classified -Program/Tru sted-Integrator -ListUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 307 of 397 ACDS R-9 The Access CDS shall only  connect to HTNs via an approved HCFD that is capable 8898  \nof filtering the VDI traffic between the Access CDS and the HTN VDI system.   8899  \nClarification:  This applies to both Access CDS VM and VDI variants.  The Access CDS 8900  \nVM type would use a VDI clien", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}649{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "648", "chunk": "t running in a VM to connect via the  HCFD to the 8901  \nHTN.  For VDI traffic syntactic and semantic filtering of the protocol is not sufficient 8902  \nas the image  and audio  data ha ve to be filtered. The raw images from the 8903  \nnormalization process would be syntactically and semantically filtered and the image 8904  \nwould be recompressed lossy in the hardware. If audio is being transferred it would 8905  \nalso be normalized, filtered syntactically and semantically, and recompressed lossy in 8906  \nthe hardware. The filtering applies to both inbound and outbound VDI channels. For 8907  \nUSB passthrough (e.g., smartcards) the USB protocol data must be syntactically and 8908  \nsemantically filtered . 8909  \nACDSR -10 Access CDS shall only allow connection s from USB device that are explicitly 8910  \nauthorized  via an administrator controlled allowlist .  8911  \nACDSR -10.1 By default, Access CDS shall configure the allowlist/denylist capability to block 8912  \nall USB devices except keyboard and mouse/trackpad.  8913  \n21 Reliable Human Review Requirements (RHRR)  8914  \nThis section applies to RHR systems built into a CDS or deployed into the operational 8915  \nenvironment.  While RHR is normally used for high -to-low situations there some unique 8916  \nsituations whe re", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}650{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "649", "chunk": " RHR would be applicable from low -to-high. For example, transferring  files 8917  \nfrom SIPRnet to  a top secret network that is releasable  to 15 countries would require RHR since 8918  \nSIPRnet contains a lot of data that is not releasable  to a TS REL 15 country networ k (e.g., no 8919  \nforeign data, export controlled data, nuclear data, etc.) . RHR systems have reviewers that are 8920  \nresponsible for reviewing and approving the content to be transferred via the CDS .  8921  \nFor an RHR system to be effective in preventing  classified (or ot her sensitive information)  data 8922  \nspills, the RHR reviewer must either  be a subject matter expert (SME)  in the content being 8923  \nreview ed or have access to SMEs that can assist in a thorough review of the documents. RHR 8924  \nreviewers that  are merely focus ing on validating the content is properly marked with out 8925  \nunderstanding the content are not performing an adequate review.  8926  \nRHRR -1 [DCCDS ] CDS that support Complex Document Data shall implement support for 8927  \nRHR.  8928  \nRHRR -1.1 RHR shall either  be a CDS -hosted remotely accessible (via a web interface) RHR 8929  \nsystem or  an external RHR system that provides digitally signed RHR manifest  that are 8930  \nvalidated in the CDS.  8931  \nRHRR -2 ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}651{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "650", "chunk": "[DCCDS ] CDS that implement Fixed Format should have the ability to support RHR 8932  \nof the content . 8933UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 308 of 397 RHRR -3 [DCCDS ] The RHR system shall implement the following requirements:  8934  \nRHRR -3.1 The RHR system shall  use web-based  interfaces for remote access to the RHR 8935  \nsystem . 8936  \nRHRR -3.2 The RHR system s hall use two factor authentication for all users of the RHR system  8937  \nRHRR -3.2.1 One of the two factor s must use  the user\u2019s  PKI certificate as part of the 8938  \nauthentication to the system . 8939  \nRHRR -3.3 The CDS shall be capable of implementing RHR for all dataflow  interfaces for the 8940  \nCDS . 8941  \nRHRR -3.4 CDS shall have the ability to filter the data with a RHR filter policy as part of the 8942  \nRHR process.   8943  \nRHRR -3.4.1 The RHR filter policy shall address  data hiding and data disclosure issues  in the 8944  \nuser provided content (See NSA\u2019s Inspection and Sani tization Guidance Documents)  and 8945  \nshould not be the same as the actual transfer policy  (if the RHR  is hosted off the CDS).  89", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}652{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "651", "chunk": "46  \nRationale : The use of the CDS\u2019s actual filtering policy would increase the risk of an 8947  \nadversary or an insider threat using the RHR system to understand how to defeat the 8948  \nCDS filtering.  The policy filtering policy should focus on those data hiding and 8949  \ndisclosure issues  most likely to cause  failures in the CDS and are likely to reasonably 8950  \noccur in an operational environment.  8951  \nRHRR -3.4.2 The RHR system  should include dirty  and clean word filtering of the textual 8952  \ncontent . 8953  \nRHRR -3.4.3 The RHR system  should include detection of security markings  in the content . 8954  \nRHRR -3.4.4 The RHR system shall provide a human readable version of the filter reports to the 8955  \nreviewers.  8956  \nRHRR -3.4.5 The reviewer shall be able to review both original and filter ed content . 8957  \nRHRR -3.4.6 The RHR system shall provide a n ability for the reviewer to override the results of 8958  \nthe RHR filter and allow the file to continue to the CDS (or CDS processing if RHR is 8959  \nonboard the CDS).  8960  \nClarification: This does not impl y that the review er can override the CDS dataflow 8961  \nfiltering.  If a dataflow with a less strict filtering policy  is needed to transfer the 8962  \ncontent , then the file should be submit", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}653{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "652", "chunk": "ted to the CDS by an individual authorized to 8963  \nuse that filtering policy.  This requires the CDS to support multiple filter policies and 8964  \nthe ability to assigned them to individuals or groups.  8965  \nRHRR -3.5 The RHR system shall be able to support  requiring multiple  reviewers  to review and 8966  \napprov e the content  for each dataflow policy  with a minimum of one reviewer  excluding 8967  \nthe submitte r. 8968  \nClarification:  Requiring at least two reviewers per dataflow is strongly recommended.  8969UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 309 of 397 RHRR -3.6 If the RHR system is operating off the CDS, it will generate a digitally signed 8970  \nmanifest of the files that were review ed and authorized for transfer.  8971  \nRHRR -3.6.1 The manifest shall be signed by all reviewer s.  8972  \nRHR R-3.6.2 The manifest shall contain, at minimum, the following information:  8973  \n\u2022 Full name, username , and email268 of the submitter of the content and each 8974  \nreviewer  8975  \n\u2022 The date  and time of each revi ewer\u2019s approval of each stream/file/piece of content 8976  \nand comment", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}654{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "653", "chunk": "s that they provide d (if any)  8977  \n\u2022 The filter  report for each content  (if applicable)  8978  \n\u2022 Security Marking for the content  8979  \n\u2022 Domain/Interface on wh ich the content  was submitted and the destination 8980  \ndomain (s) for the  content  8981  \n\u2022 SHA -384 or higher hash of the original content and the hash of the content being  8982  \ntransferred  8983  \n\u2022 Dataflow ID  8984  \nClarification:  The manifest only contains content approved by the RHR Reviewer(s) for 8985  \ntransfer . RHR Reviewer approved content is still subject to filtering  inside the CDS . 8986  \nRHRR -3.6.3 The CDS shall audit the RHR manifests using the same process and mechanism as 8987  \nfilter reports are audited and transferred off the CDS.  8988  \nRHRR-3.6.4 The CDS shall validate the contents of the manifest match t he payload and the 8989  \nreviewer signatures are valid and are approved reviewers.  8990  \nRHRR -3.7 The RHR system shall audit all RHR action s performed on the content and the 8991  \nresults of those actions.  8992  \nClarification:  Auditing is required regardless of when the RHR is performed. The CDS 8993  \nwill audit any files that have been through off -box RHR.   8994  \nRHRR -3.7.1 The RHR system shall audit the sam e information found in the RHRR -3.6 manifest 8995  \n", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}655{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "654", "chunk": "for all content whether it is approved or denied.  8996  \nClarification:  For denied content , the RHR system will audit the RHR review ers\u2019 8997  \nreason s and comments for denial instead of the approval comments.  8998  \nRHRR -3.8 If the RHR system is operating on the CDS, account creation  and manipulation  for 8999  \nRHR users shall use the RBAC TKPC process (see RBACR -3.2.7 and RBA CR-3.4.5)  9000  \n \n268 For the network in which the content originated.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 310 of 397 RHRR -3.9 If the RHR system is operating on the CDS , RHR Reviewers do not have operating 9001  \nsystem accounts. RHR  Reviewer  accounts only exist within the RHR system.  9002  \nRHRR -3.10 The RHR systems (on or off the CDS)  should support the ability to have different 9003  \nreviewers for different dataflow filtering policies.  9004  \nRHRR -3.10.1 If per dataflow reviewers are implemented then reviewer shall be associated with 9005  \none or more dataflow IDs and the CDS shall enforce that each manifest  has a dataflow ID 9006  \nand the reviewers are authorized for that dataflow ID.   9007  \nR", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}656{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "655", "chunk": "HRR-3.11 The RHR system shall provide  a mechanism to allow the reviewer to individually 9008  \napprove or deny specific files that are part of a single transfer.  9009  \nRHRR -3.12 The RHR sy stem shall provide a mechanism for the RHR reviewer to explain why a 9010  \nfile is denied  and require that it be filled out.  9011  \nRHRR -4 An RHR system on the CDS may implement an ability to override (e.g., bypass) t he 9012  \nfiltering policy for the transfer of a file.  9013  \nClar ification:  This mechanism only applies to file transfer CDS (e.g., Microsoft Office, 9014  \nImages, PDF , XML ). This capability does not apply streaming (e.g., VTC, VOIP, Full 9015  \nMotion Video) CDS.  9016  \nRationale:  The im plementation of a n override capability in a file transfer CDS is to 9017  \ntransfer files that cannot be successfully filtered by the CDS (or perhaps any CDS) 9018  \nyet still must be transferred to meet operational requirements. Sending a file through a 9019  \nCDS is generally safer than using alternative mechanisms like USB, CDROM/DVD, 9020  \nor other removable media. However, t here must be substantial burde ns and limit s on 9021  \nthis capability to prevent it from be ing over used and putting the destination domains 9022  \nat risk.   9023  \nRHRR -4.1 An RHR capability  tha", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}657{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "656", "chunk": "t is external to the CDS  shall not be used to override the filter 9024  \npolicy. 9025  \nRHRR -4.2 If an override capability i s implement ed, it shall require TKPC to override  the filter 9026  \npolicy . 9027  \nRHRR -4.3  The CDS shall provide a mechanism to limit which and how many people can be 9028  \napprovers for overrides.  9029  \n Clarification: The recommended max imum  number of override approvers is six (i.e., 2 9030  \nper 8  hour shift).  9031  \nRHRR -4.4 Both TKPC individuals must provide a non -zero length explanation s for the override . 9032  \nRHRR -4.5 Over rides can only be applied to individual files being transferred . 9033  \nRHRR -4.5.1 Overrides should not be used with archive (e.g., zip, tar) files.  9034  \nRHRR -4.6 If an override capability is implemented , the following , at minimum,  must be logged : 9035  \n\u2022 filename  9036UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 311 of 397 \u2022 SHA -384 (or higher)  hash of the file  9037  \n\u2022 source and destination domains and systems  9038  \n\u2022 sender (if known)  9039  \n\u2022 recipient (if known)  9040  \n\u2022 the full name and username of the two TKPC", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}658{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "657", "chunk": " individuals  9041  \n\u2022 date and time of file submission and filter override  9042  \n\u2022 the explanations from the TKPC individual for the override  9043  \nRHRR -4.7 The overridden  file shall be SFTF wrapped and journaled.  9044  \nRHRR -4.8 An override capability cannot  override anti -virus scanning  of the file, filename 9045  \nlength check (i.e., GDFR -27), and filename malicious checks  (i.e., GDFR -29). It can only 9046  \noverride the content specific filters.  9047  \nRHRR -4.9 The RHR system  shall implement a configurable limit  on the number of overrides 9048  \nper day per TKPC approve r. 9049  \nRationale:  This reduce s the impact of compromised TKPC approvers being used to send 9050  \nlarge amount s of malicious or exfiltrated files . 9051  \n 9052  \n22 Filter Sidecar Requirements (FSR)  9053  \nThis section covers the security requirements for filter sidecars used by CDS  and how a CDS 9054  \nintegrates  securely with a sidecar.  Because filter sidecars  are performing filtering,  they must 9055  \nadhere to the same core security requirements as the CDS  to prevent a compromise of the filter 9056  \nsidecar . The types of functions provide d by a filter sid ecar include but are not limited to:  9057  \n1. Content normalization and denormalization (e.g., converting from a mis", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}659{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "658", "chunk": "sion specific 9058  \nbinary data format to XML)  9059  \n2. Filtering of content including using software and hardware -based  filtering techniques  to 9060  \naddress data attack and data loss prevention issues.  9061  \nFilter sidecars  are primarily intended to be used with file-based  content (e.g., XML, Microsoft 9062  \nOffice, PDF, images, audio/video files). Filter sidecars potentially can be used with  streaming 9063  \ncontent (e.g. , low latency/high throughput XML/JSON web services, military messaging, full 9064  \nmotion video) but implementors should consider the extra  latency that a sidecar will introduce.  9065  \nSidecar s must implement one of the ADP s appropriate for the data being processed by the CDS . 9066  \nIf the CDS is tested to properly implement the Filter Sidecar Protocol, users should be able to 9067  \nadd new content types without having to completely recertify the CDS sinc e the filter sidecar 9068  \nwould be separately certified.  9069  \nThe CDS/sidecar deployment relationship can be described in the following scenarios:  9070UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 312 of 3", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}660{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "659", "chunk": "97  9071  \n\u2022 Single CDS  to single sidecar  9072  \n\u2022 Multiple CDS  to a single sidecar  9073  \n\u2022 Single CDS  to multiple sidecars  9074  \n\u2022 Multiple CDS  to multiple sidecars  9075  \n 9076  \nUse of the word \u201cmultiple\u201d above refers not only to number but to variety.  9077  \n 9078  \nIn order to reduce the attack risks to the CDS , the sidecar does not initiate channel connections to 9079  \nthe CDS . The CDS  connect s to the sidecar. Due to the as ynchronous nature of filter sidecars, 9080  \nonce a bi -directional channel is established, both the CDS  and sidecar may initiate transmission 9081  \nof commands.  The sidecars are expected to have  four communications channels:  9082  \n 9083  \n1. The management  channel  is used for session  and job control, health and status 9084  \nmonitoring, filter policy changes including loading new policies, and time sync;  9085  \n2. The job control channel  is used for job control and health and status monitoring;  9086  \n3. The send  channel  is used for sending jobs to the sidecar;  and 9087  \n4. The receive  channel  is used to receive notifications from the sidecar as new jobs are 9088  \nready for retrieval, to retrieve jobs from the sidecar, and to retrieve job VIS reports from 9089  \nthe sidecar.  9090  \n 9091  \nA filter sidecar shall imple", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}661{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "660", "chunk": "ment the send and receive chan nels but should implement the job 9092  \ncontrol and management channels. Implementation of the job control and management channels 9093  \nis strongly encouraged.  9094  \n 9095  \nThe job control, send and receive channels usually use the same network interface on the sidecar. 9096  \nIt is strongly recommended (though not required) that the management channel be on separate 9097  \nphysical dedicated management network or a cryptographically separated ( e.g., via IPSEC VPN) 9098  \nnetwork from the other channels.  9099  \n 9100  \nA sidecar may support processing of data fr om multiple domains on the CDS, but each of those 9101  \ndomains are required to have separate job management, send, and receive channels  to the 9102  \nsidecar.  9103  \n 9104  \nOn the CDS, only job metadata is sent from  the sidecar  controller  sending process to the sidecar 9105  \ncontroller receiving process. Metadata filters are required to prevent  the metadata chan nel from 9106  \nbeing used to send content  thus bypassing the sidecar.  9107  \n 9108  \nThe sidecar sends the VIS report along with the filtered content to the CDS. The CDS verifies 9109  \nthe content received from the sidecar matches  the file metada ta in the VIS report.  9110UNCLASSIFIED//FOR OFFICI AL USE ONLY//", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}662{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "661", "chunk": "REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 313 of 397  9111  \n 9112  \nFSR -1  Filter Sidecars shall implement the requirements in sections NRR, SCR, GAR, C2R, 9113  \nOSSR, SASR, DPMR, SIHCR, PIR, RBACR, EDSR, SIR, JALSR, RMANR, RMONR, 9114  \nVTR, PAR, DRR, FRVR, JSR, RPR, DCOR , GDFR, GXFFPR, MMFFR, LBASR, and 9115  \nSBSAR  9116  \nClarification : Due to the uniqueness of filter sidecars , please contact the NCDSMO for 9117  \ntailoring guidance for this requirement.  Other requirements like VIRT, THA, HWR, 9118  \nRHRR, MLSWNR may be applicable depending on the how the filter sidecar is 9119  \nimplemented.  9120  \nRationale:  If the filter sidecar is  compromised because of poor platform security then the 9121  \nresults of the filtering cannot  be trusted.  9122  \nFSR -1.1 Filter sidecars should implement the requirements in section MPCR and CDMPCR . 9123  \nFSR -2 Filter sidecars shall implement RAIN for their filter pipelines.  9124  \nFSR -2.1 Filter sidecar s shall implement one of the acceptable design patterns described in 9125  \nSection 8.3.1  that is appropriate for the data being processed.  9126  \nFSR -3 Filter sidecars shall be teste", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}663{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "662", "chunk": "d in the NCDSMO LBSA process.  9127  \nFSR -4 CDS being used as filter sidecars by other CDS must comply with these requirements.  9128  \nFSR -5 Filter sidecars  should support being load balanced by TCP/IP based load balancers.  9129  \nClarification:  Filter sidecars may use NRR -9 requirements for load balancing . Due to 9130  \ndramatically  reduce d attack and discovery risks , traditional TCP/IP load balancers 9131  \ncan be used.  9132  \nFSR -6 The filter  sidecar environment shall be physically isolated from mission networks.  9133  \nFSR -7 A filter sidecar should support remote installation of the filter sidecar software from the 9134  \nCDS CMS.  9135  \nFSR -7.1 A CDS CMS may be the PXE installation server for a filter sidecar that is using PXE 9136  \nfor over -the-network installation of DFS software.  9137  \nFSR -7.2 A CDS CMS should be the UEFI HTTP Boot server for a filter sidecar that is using 9138  \nUEFI HTTP Boot for over -the-network installation of DFS software  9139  \nFSR -8 The filter sidecar should implement the NCDSMO Filter Sidecar Protocol (FSP)  9140  \nSpecific ation  v1.0.6 or higher.  9141  \nFSR -9 The f ilter sideca r\u2019s communication protocol s with the CDS shall meet following 9142  \nrequirements:  9143  \nFSR -9.1 The sidecar protocol shall use separate n", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}664{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "663", "chunk": "etwork channels  for job control, sidecar 9144  \nmanagement and filter policy loading, job submission  (i.e., send) , and job retrieval  (i.e., 9145UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 314 of 397 receive)  9146  \nRationale: The separate channels are required to meet POLF and POLP in the protocol 9147  \nadapters on the CDS and filter sidec ar and for submission  and retrieval  channels to 9148  \nhelp enforce linear flow through the filter  pipeline  and prevent bypasses.  9149  \nFSR -9.2 The job retrieval channel shall return a filter report for each content that is filtered 9150  \nregardless of the result of the filtering.  9151  \nFSR -9.3 The job retrieval channel shall not return any content that failed due to confirmed or 9152  \nsuspected maliciousness.  9153  \nFSR -9.4 The job retrieval channel may return content that failed solely for data loss prevention 9154  \nissues to support RHR review.  9155  \nFSR -9.4.1 Jobs that fail due to data loss prevention must be wrapped with SFTF using AES or 9156  \nXOR  (with nonce) prior to transmission back to the CDS and only the RHR subsystem 9157  \nhas th", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}665{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "664", "chunk": "e key /nonce  necessary to  deobfuscate the data.  9158  \nRationale : This prevents any failed con tent from being delivered in a usable decoded 9159  \nform to the destination environment.  9160  \nFSR -9.5 Each channel is a separate bi -directional TCP/TLS -based mutually PKI authenticated 9161  \nconnection between the CDS and filter sidecar.  9162  \nFSR -10 The CDS shall only transfer content that passed filtering in the filter  sidecar.  9163  \nFSR -11 A filter sidecar  may operate on a hypervisor;  however,  the hypervisor must be dedicated 9164  \nto the filter sidecar  function.  9165  \nFSR -12 A filter sidecar  supporting file processing (e.g., Microsoft Office \u2122, images, PDF , XML 9166  \nfiles, archive files ) shall use the NCDSMO Verification, Inspection, and Sanitization 9167  \n(VIS) Report Specification  v2.0 or higher specification for the filter report s. 9168  \nClarification: The filter sidecar supporting streaming data (e.g., streaming video/audio, 9169  \nstreaming XML/JSON web services) are not required to use the VIS Report specification.  9170  \nFSR -13 The CDS shall perform, at a minimum, the following validations on receipt of VIS 9171  \nReport  and content from a filter sidecar:  9172  \nFSR -13.1 Verifies the VIS Report  complies with its XML schema prior to pe", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}666{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "665", "chunk": "rform ing any 9173  \nactions on the VIS Report  9174  \nFSR -13.2 Verif ies the PASS, PASS WITH CHANGE, FAIL, or ERROR status of the VIS 9175  \nReport  9176  \nFSR -13.3 Verifies the correct policy was used to filter  the data  9177  \nFSR -13.4 Verifies the validity of the sidecar signature against an approved sidecar signers list  9178  \nFSR -13.5 Verifies the integrity of VIS Report  9179  \nFSR -13.6 Verifies that if PASS or PASS WITH CHANGE was the result, then the  final hash, 9180UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 315 of 397 file size , and filename in the report are the same as the actual data received  from the filter 9181  \nsidecar.  9182  \nFSR -13.7 Verifies that if PASS WITH CHANGE was the result,  then the original file hash and 9183  \nthe filtered file hash must differ  and the VIS report m ust con tain both hashes.  9184  \nFSR -13.8 Verifies that if PASS was the result, then the original file hash and filtered  file hash 9185  \nmust be the same  and the VIS report must contain both hashes.  9186  \nFSR -13.9 Verifies that the job  received  from the sidecar was submitted by the CDS .  ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}667{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "666", "chunk": "9187  \nClarification:  This can be accomplished  by comparing the original hash and filename of 9188  \nthe job submission with the filename  and hashes  in the VIS Report . 9189  \nFSR -14 If a CDS  with an invalid or expired certificate attempts to connect , the filter sidecar will 9190  \nrefuse connections from that device . 9191  \nFSR -15 A filter sidecar may support  simultaneous connections from multiple CDS.  9192  \nFSR -16 The CDS  or filter sidecar should immediately shutdown the  channel if any parsing 9193  \nerrors occur during reading of a message on that channel. This event is audited.  9194  \nFSR -17 The CDS  shall perform independent validat ion the VIS Report  in a process different 9195  \nfrom the one that submitted the job to the sidecar controller domain to avoid a potential 9196  \nbypass condition.  9197  \nRationale: If the submitting process is also the receiving and VIS Report  validation 9198  \nprocess then a logic mistake or comprom ise of the submitting process could result in 9199  \nbypassing the filter sidecar.  9200  \nFSR -18 The filter sidecar process sending VIS Report s and filtered content to the CDS shall not  9201  \nhave access to unfiltered origin content (data).  9202  \nFSR -19 The CDS process receiving VIS Report s and filtered content from the ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}668{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "667", "chunk": "filter sidecar shall 9203  \nnot have access to unfiltered origin content (data).  9204  \nFSR -20 Communications to the sidecar management interface should occu r over a separate 9205  \nphysical connection than the job send, job receive, and job control channels.  9206  \nRationale:  Ideally, this would be the same network as the CDS remote management 9207  \nconnection since  this will enable the management systems to simultaneously cont rol 9208  \nthe filter policies on both the CDS and the sidecar.  9209  \nFSR -21 If the filter sidecar is  on a single private network connection attached to the CDS, then 9210  \nthe sidecar domain shall  be considered as operating at system high  of the CDS.  9211  \nFSR -22 The CDS shall not  communicate directly with a sidecar from a data ( e.g., user) doma in. 9212  \nFSR -23 On the CDS d ifferent processes shall  be used for the job send channel, job receive 9213  \nchannel, job control channel, and the sidecar management channel.  9214  \nFSR -24 The CDS process sending jobs to the filter sidecar may send job metadata to the CDS 9215UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}669{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "668", "chunk": "Page 316 of 397 process receiving jobs from the fil ter sidecar.  9216  \nFSR -24.1 The metadata should contain the filename (if applicable), hash of the original 9217  \nfile/content, policy ID used to the filter the data, job ID, and original size of the 9218  \nfile/content .  9219  \nFSR -24.2 The metadata transfer must follow C2R requirements for metadata transfer.  9220  \nFSR -24.3 The metadata transfer must be via DAC and MAC enforce d one-way transfer 9221  \nmechanism.  9222  \nFSR -25 The sidecar must be capable of sending operating system logs, sidecar component logs 9223  \n(e.g., protocol adapter, filters, orchestration components), filter reports, and all JAL data 9224  \nincluding quarantined files to the DCO of CDS OOB.  9225  \nFSR -25.1 The filter sidecar should use JALoP to transfer audit, logs, journal ed, and quaran tined 9226  \ndata to the DCO of CDS OOB.  9227  \nFSR -25.2 The filter sidecar may use SYSLOG to transfer audit  and log  data to the DCO of CDS 9228  \nOOB.  9229  \nFSR -26 Filter sidecar s can be deployed in one of the following acceptable design  patterns:  9230  \nClarification:  The below design patterns are not a complete implementation of a CDS . 9231  \nThey  are solely intended to show how the communications  between the CDS and the 9232  \nfilter  sid", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}670{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "669", "chunk": "ecar must be done in order to prevent bypass conditions.  All of the acceptable 9233  \ndesign patterns assume use of FSP.  9234  \n1. FSR-ADP-1: A single isolated filter sidecar environment connected to a CDS . The 9235  \nsidecar management interface is not shown.  9236  \n 9237  \nFigure 44 \u2013 FSR-ADP-1 A Single Isolated Filter Sidecar Environment  9238  \n2. FSR-ADP-2: Multiple isolated filter sidecar environments connected to the CDS, one 9239UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 317 of 397 environment  for each domain connected to the CDS.  The sidecar management interface is 9240  \nnot shown.  9241  \n 9242  \n 9243  \nFigure 45 \u2013 FSR-ADP-2 Multiple Isolated Filter Sidecar Environments  9244  \nFSR -27 The following are unacceptable design patterns  for filter sidecar deployments :  9245  \n1. FSP-UDP -1: A single sidecar controller is used on the CDS. This UDP has multiple 9246  \nissues including commingling data from multiple domains (within the CDS)  in a single 9247  \nprocess and  commingling of the data sent to  and received from  the sidecar . This approach 9248  \nessentially makes the sidecar con", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}671{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "670", "chunk": "troller a multi -domain router , violates POLK and POLP, 9249  \nand does not implement a linear assured pipeline thus a trivial software mistake  (or an 9250  \nattac k) could result in a bypass o f the side car.  9251  \n 9252  \nFigure 46 \u2013 FSP-UDP-1 Single  Sidecar C ontroller on the CDS  9253  \n2. FSP-UDP -2: Multiple single process sidecar controllers are used on the CDS. While a 9254  \nslight improvement over FSP -UDP -1, it still suffers from the bypass of the sidecar 9255  \ncondition. Linear data flow is not enforced. In this example, there is also a single process 9256UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 318 of 397 in each domain that communicat es with the sidecar controller which introduces another 9257  \nbypass potential.  The sidecar controllers are not split  into separate sending and receiving 9258  \nprocess which create another potential bypass.  9259  \n 9260  \nFigure 47 \u2013 FSP-UDP-2 Single Process per Domain & Combined Sidecar Controller per Domain  9261  \n3. FSP-UDP -3: A single process in each domain that communic ates with the sidecar  9262  \ncontrollers . While the communication  ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}672{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "671", "chunk": "with the sidecar is correct for each domain, in each 9263  \ndomain has only a single process communicating with the sidecar controller 9264  \ninfrastructure. A mistake in that single process could result in a potential bypass of the 9265  \nsidecar.  9266  \n 9267  \nFigure 48 \u2013 FSP-UDP-3 - Single Process per Domain Communicating with Sidecar  Controllers  9268  \n 9269  \nFSR -28 A filter sidecar  must have unique  and separate  PKI keys per CDS  per domain  for its 9270  \nTLS connections and signing VIS Report s. 9271  \nClarification:  Protecting the TLS keys for all the CDS sidecar proces ses is critical to 9272  \nmaintaining the separation between the CDS sidecar processes and the filter 9273  \nsidecar(s)  9274  \nFSR -29 The CDS shall implement firewal l rules to ensure CDS sidecar processes can only 9275UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 319 of 397 communicate with the filter sidecars.  9276  \nClarification: For example, the CDS job send process must be prevent ed from 9277  \nconnecting to ports other than the job send port on the filter sidecar.  9278  \nFSR -30 The CDS shall implement MAC polic", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}673{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "672", "chunk": "y to ensure CDS sidecar processes can only 9279  \ncommunicate with the filter sidecars.  9280  \nFSR -31 A filter sidecar may run on hypervisor if the VIR T requirements are implement ed 9281  \nhowever only filter  sidecar  VMs may operate on the hypervisor.  9282  \n 9283  \n23 Distributed Filtering System Requirements (DFSR)  9284  \nThis section covers the security requirements for CDS distributing filtering system (DFS) used in 9285  \nEnterprise Cross Domain deployments to improve throughput in the CDS infrastructure. Because 9286  \nDFS are performing the security critical functions they must adhe re to the same core security 9287  \nrequirements as the CDS. The types of functions provided by a DFS include but are not limited 9288  \nto: 9289  \n1. Content normalization and denormalization (e.g., converting from a mission specific 9290  \nbinary data format to XML)  9291  \n2. Mission specific p rotocol termination  9292  \n3. Filtering of content including using software and hardware -based  filtering techniques  9293  \nDFS are primarily intended to be used with file-based  content (e.g., XML, Microsoft Office, 9294  \nPDF, images, audio/video files). DFS can be with streaming  content (e.g., low latency/high 9295  \nthroughput XML/JSON web services, military messaging, full motion vide", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}674{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "673", "chunk": "o) but it is not 9296  \nrecommended due the added complexity and latency of the DFS components. The use of DFS is 9297  \nnot recommended due to the much higher develop ment, testing, assurance complexity, and 9298  \noperational costs. Most modern CDS can work with TCP/IP load balancers to achieve the similar  9299  \nperformance and scalability  of DFS but at less complexity.  9300  \nDFS systems are similar to filter sidecars but they differ  in the transport protocols , the ability to 9301  \nbe used before and after the CDS  versus in a private network (e.g., for filter sidecars) , and in 9302  \nDFS system s not all DFS nodes have  all filters or an orchestration engine.  In a DFS architectu re 9303  \nthe primary job of th e CDS is to provide domain separation, validate the filter report, and ensure 9304  \nthe content being transferred has an associated valid filter report. CDS may also provide normal 9305  \ncontent filtering functions.  9306  \nDFS nodes can run on separate hardware or as virtual  machines on a single server or a cluster of 9307  \nvirtualization servers.   9308  \nThis section includes a number of design patterns. A single CDS is shown in the design patterns 9309  \nto make the drawings easier  to understand . However multiple CDS could be used and they cou ld 9310", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}675{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "674", "chunk": "  \nbe wrapped by load balancers.  9311UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 320 of 397  9312  \nDFSR -1  DFS components shall implement the requirements in sections NRR, SCR, GAR, C2R, 9313  \nOSSR, SASR, DPMR, SIHCR, PIR, RBACR, EDSR, SIR, JALSR, RMANR, RMONR, 9314  \nVTR, LBSAR, PAR, DRR, FRVR, RHR R, JSR, RPR, DCOR , GDFR, G XFFPR, 9315  \nMMFFR, LBASR, and SBSAR.  9316  \nClarification: Due to the uniqueness of DFS, please contact the NCDSMO for 9317  \ntailoring guidance for this requirement.  Other requirements like VIRT, MPCR, 9318  \nCDMPCR, THA, HWR,  MLSWNR may be applicable depen ding on the how the 9319  \nDFS is implemented.  The use of one -way transfers from the DFS components to the 9320  \nOrchestration capability is not required.  9321  \nRationale:  If the DFS components are compromised because of poor platform security 9322  \nthen the results of the filteri ng cannot  be trusted.  9323  \nDFSR -1.1 DFS components  that leverage container s shall  implement the requirements in the 9324  \nMPCR  section.  9325  \nClarification: MPCR -22 does not apply to Container based MPC s. 9326  \nDFSR -1.1", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}676{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "675", "chunk": ".1 DFS components that implement MPCR may use container orchestration engine s to 9327  \ncontrol which filter containers are active on specific systems.  9328  \nClarification: MPCR -9 does not apply to DFSR . MPCR -4 does not apply to DFS 9329  \ncomponent  communications with filter orchestration components.  9330  \nDFSR -1.1.2 DFS components that implement MPCR shall not use container orchestration 9331  \nengine s that communicate with the container images or install orchestration specific 9332  \nlibraries in the container images.  9333  \nClarification: If a DFS based MPC needs to provide health and status information to the 9334  \norchestration system, then it shall send that information to host operating system 9335  \ncontainer monitoring application via a one -way IPC. The host container monitoring 9336  \napplication will send that to the orchestration engine  9337  \nDFSR -1.1.3 Container images used in DFS shall be installed on the DFS specific system or a 9338  \ncontainer registry, if using container orchestration, consistent with MPCR installation 9339  \nrequirements .  9340  \nDFSR -1.1.4 DFS using container orchestration must include an explicit policy defining which 9341  \nDFS nodes/systems specific container images can be run on.  9342  \nDFSR -1.1.5 DFS comp onents that", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}677{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "676", "chunk": " implement MPCR shall not use container orchestration 9343  \nengines to install containers images on specific systems.  9344  \nDFSR -1.1.6 Container images must be digitally signed and include a  software bill of materials 9345  \nthat can be validated prior to installation.  9346  \nDFSR -1.1.7 Container images used in a DFS must be digitally signed by the CDS/DFS 9347UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 321 of 397 vendor/developer within th eir lab -based CI/Build system.  9348  \nDFSR -1.1.8 DFS using container orchestration must implement a validating admission controller 9349  \nto validate digital signatures and attestations on container imag es prior to allowing them 9350  \nto be provisioned within the DFS.  9351  \nDFSR -1.1.9 DFSs using container orchestration must disable mutating admission controllers.  9352  \nRationale: Mutating admission controller s can add or modify  the content of objects they 9353  \nadmit269. 9354  \nDFSR -2 The DFS shall ensure that all content is filtered with redundant and independent filters.  9355  \nDFSR -3 DFS Components should support being load balanc ed by TCP/", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}678{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "677", "chunk": "IP based load balancers.  9356  \nDFSR -4 DFS Components shall be tested in the LBSA process.  9357  \nDFSR -5 A DFS can be deployed in one of the following design patterns:  9358  \n1. DFSR-ADP-1: A single physically isolated DFS environment connected to a CDS . 9359  \n 9360  \nFigure 49 \u2013 DFSR-ADP-1 Single Physically Isolated DFS Environment  9361  \n2. DFSR-ADP-2: Multiple  physically  isolated DFS environments connected to the CDS, 9362  \none DFS environment for each domain connected to the CDS.  9363  \nClarification:  The drawing for this design pattern is similar to the DFSR-ADP-1 but 9364  \nwith a separate physical isolated DFS  (the systems in the grey rounded box) for each 9365  \ndomain.  9366  \n3. DFSR-ADP-3: For each security domain connected to the CDS, a separate DFS is 9367  \n \n269 https://kubernetes.io/docs/reference/access -authn -authz/admission -controllersUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 322 of 397 connected physically inline between the CDS and the security domain connected to the 9368  \nCDS.  9369  \n 9370  \nFigure 50 \u2013 DFSR-ADP-3 Per Domain DFS Environment  9371  \nDFSR -6 DFS s", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}679{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "678", "chunk": "ystems shall be isolated from HTNs  via a PFD (for one -way transfer only ) or an 9372  \nHCFD  (if bi -directional data flow is required) . 9373  \nRationale:  This substantially reduces the ability of the adversary to compromise  and take 9374  \ncontrol of  the DFS.  9375  \n 9376  \nFigure 51 \u2013 Use of Pitcher/Diode/Catcher to Isolate a DFS from an HTN  9377  \nDFSR -6.1 OWTDP -3: Diode Sandwich Pattern  should be used when connecting a DFS to HTN.  9378  \nClarification: If OWTDP -3 is used then Diode B can be replaced with a software CDS.  9379UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 323 of 397 DFSR -7 DFS systems shall  be isolated from all mission networks  (e.g., SIPRn et, JWICS)  via 9380  \nfirewalls . 9381  \nDFSR -8 In the DSFR -ADP-3 design pattern, the design and implementation of the DFS shall 9382  \nensure that all data transits through the DFS components going to or from the CDS.  9383  \nDFSR -9 In the DSFR -ADP-1 design pattern , the DFS environment shall operate at the system 9384  \nhigh level of the CDS  or at the system high no foreign level if all the networks connected 9385  \nto the CDS ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}680{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "679", "chunk": "are releasable networ ks. 9386  \nDFSR -10 If the DFS is used in a sidecar environment, then each sidecar environment is 9387  \nphysically isolated from other sidecar environments and mission networks.  9388  \nDFSR -11 If the DFS is used as a sidecar (see DSFR -ADP -3) environment then the DFS 9389  \ncomponent should implement the NCDSMO Filter Sidecar Protocol (FSP)  Specification  9390  \nv1.0.6 or higher.  9391  \nDFSR -12 If the DFS is used in a sidecar environment and the DFS components do not 9392  \nimplement the NCDSMO FSP  v1.0.6 or higher , then the protocol must meet the 9393  \nfollowing requirements:  9394  \nDFSR -12.1 Separate network channels including protocol adapters  for job control, DFS 9395  \ncomponent management, job submission, and job retrieval.  9396  \nClarification:  A channel is defined a separate TLS -based mutually authenticated 9397  \nconnection between the CDS and the DFS component.  9398  \nRationale: The separate channels are required to  meet  POLF and POLP in the protocol 9399  \nadapters on  the DFS components and for submission and retrieval channels to help 9400  \nenforce linear flow through the filter  pipeline  and prevent bypasses.  9401  \nDFSR -12.2 The job retrieval channel shall return a filter report for each c ontent that is filtered 9402  \n", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}681{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "680", "chunk": "regardless of the result of the filtering.  9403  \nDFSR -12.3 The job retrieval channel shall not return any content that failed due to  confirmed or 9404  \nsuspected maliciousness.  9405  \nDFSR -12.4 The job retrieval channel may return content that failed solely for data loss 9406  \nprevention issues to support RHR  review . 9407  \nDFSR -12.4.1 Jobs that fail due to data loss prevention must be obfuscated (e.g., AES encryption, 9408  \nnonced XOR) prior to transmission back to the orchestration system  and only the RHR 9409  \nsubsystem has the key necessary to deobfuscate the data.  9410  \nRationale:  This prevents any failed content from being delivered in a usable decoded 9411  \nform to  the destination environment.  9412  \nDFSR -13 If the CDS is used with a DFS in  a sidecar environment, the CDS shall only transfer 9413  \ncontent that passed filtering in the DFS sidecar and returned to the CDS.  9414  \nDFSR -14 A DFS nodes may operate on separate hardware or as virtual machines on a single 9415UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 324 of 397 server or a cluster of  virtualization servers  howev", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}682{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "681", "chunk": "er the physical servers or virtualization 9416  \nservers must be dedicated to the DFS function.  9417  \nDFSR -15 A DFS CMS should support remote installation of the DFS software from the DFS 9418  \nCMS.  9419  \nDFSR -15.1 A DFS CMS may be the PXE installation server for DFS components that are using 9420  \nPXE for over -the-network installation of DFS software.  9421  \nDFSR -15.2 A DFS CMS should be the  UEFI HTTP Boot server for DFS components that are 9422  \nusing UEFI HTTP Boot for over -the-network installation of DFS software.  9423  \nDFSR -16 DFS CMS software shall not have the ability to digitally sign DFS component 9424  \nconfiguration files without fi rst requiring the CDS administrators to provide a 9425  \npassphrase(s) to unlock the signing certificates.  9426  \nDFSR -17 The DFS CMS should use the GRMP to remotely manage the DFS components.  9427  \nDFSR -18 If the DFS CMS supports log retrieval from the DFS components, the DFS CMS shall 9428  \nsupport JALoP.  9429  \nDFSR -19 If the DFS CMS supports log retrieval from the DFS components, the DFS CMS 9430  \nshould support SYSLOG (see section RMONR -3 for specific SYSLOG requirements).  9431  \nDFSR -20 GRMP should be used to manage the configuration of the DFS component systems . 9432  \nDFSR -20.1 If GRMP if used to manag", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}683{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "682", "chunk": "e the DFS , the DFS  shall not use the same GRMP server 9433  \nas the CDS.  9434  \nDFSR -21 The DFS CDS may support the addition of USG provided insider threat monitoring 9435  \nsystem however that must be done in coordination with the DFS component vendor to 9436  \nensure proper MAC, D AC, SECCOMP (via systemd), SIC/CIC, and other platform 9437  \nsecurity requirements are implemented to prevent exploitation of the DFS CMS via the 9438  \ninsider threat monitoring system.  9439  \nDFSR -22 DFS components shall send their JAL data to the CDS Monitoring OOB  9440  \nDFSR -23 The DFS shall generate a filter report for each file filtered by the DFS and send any 9441  \nsuccessful content and the associated filter report to the CDS.  9442  \nDFSR -24 The CDS must understand the filtering capabilities of the DFS for each data type so 9443  \nthat it can ensure that the received filter reports are correct for the data types being 9444  \nfilter ed. 9445  \nDFSR -25 The DFS use the NCDSMO Verification, Inspectio n, and Sanitization (VIS) Report 9446  \nSpecification  v2.0 or higher specification for the filter report.  9447  \nDFSR -25.1 If the DFS does not implement the NCDSMO VIS Report  v2.0 or higher 9448  \nspecification then the filtering report must implement the following requirements:  944", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}684{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "683", "chunk": "9  \nDFSR -25.1.1 The filtering report must be implemented in XML.  9450UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 325 of 397 Clarification:  Until CDS natively support JSON including validating JSON files against 9451  \nJSON schemas and have support for digitally signed JSON, XML is the only viable 9452  \nstandardized data format that can be used for filter reports for a DFS. This 9453  \nrequirement may be removed  in the future depending on the adoption of JSON by 9454  \nCDS.  9455  \nDFSR -25.1.2 The filtering actions and results of each filter must be recorded in the report.  9456  \nDFSR -25.1.3 The following filtering result values shall be used to report the final filtering result 9457  \nfor all content:  9458  \n\u2022 PASS \u2013 The content completed filtering with no changes.  9459  \n\u2022 PASS _WITH _CHANGE \u2013 The content completed filtering but the content changed. 9460  \nThis is the most common pass condition.  9461  \n\u2022 FAILED _MALICIOUS  \u2013 The content failed in filtering  and was suspected or 9462  \nconfirmed to be malicious. It  will not be delivered to the orchestration engine.  9463  \n\u2022 FAILED _DLP  \u2013 Th", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}685{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "684", "chunk": "e content failed in filter ing due to a  data loss prevention  issue and 9464  \nmay be delivered to the to the orchestration engine . 9465  \n\u2022 FAILED_OTHER \u2013 The content failed in filtering for an uncategorized reason and 9466  \nwill not be delivered to the orchestration engine.  9467  \n\u2022 ERROR \u2013 An error occurred in the filtering and the content did not complete filtering 9468  \nand will not be delivered to the to the orchestration engine .  9469  \nClarification:  This list does not imply t hese are the only result s given for the filtering 9470  \nperformed. The f iltering report must include all the filtering actions taken against the 9471  \ncontent. These are just the summary results and ultimately what is used by the CDS to 9472  \ndetermine if the file should be transferred.  9473  \nDFSR -25.1.4 The DFS shall create SHA -384 (or higher) hashes for all content referenced in the 9474  \nfilter report.  9475  \nClarification: The DFS that are integrated with CDS must use the same hashing 9476  \nmechanism for filter reports.  9477  \nDFSR -25.1.5 The DFS shall treat all errored  content as failed and shall not send it to the CDS.  9478  \nDFSR -25.1.6 Each DFS component system shall digitally sign its filter reports.  9479  \nDFSR -25.1.7 Each filter on a DFS component system shall di", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}686{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "685", "chunk": "gitally sign its filtering results in 9480  \nits portion of the filter report.   9481  \nDFSR -26 The CDS shall perform, at minimum, the following validations on receipt of filter 9482  \nreport and content from a DFS s: 9483  \nDFSR -26.1 The CDS shall syntactically and semantically validate the filter report with the fitler 9484  \nreport  schema using two independent implementations prior to acting on the report.  9485UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 326 of 397 DFSR -26.2 The CDS shall verify  the PASS, PASS WITH CHANGE, FAIL, or ERROR status of 9486  \nthe filter report . 9487  \nDFSR -26.3 The CDS shall verify  the correct policy was used to filter the data . 9488  \nDFSR -26.4 The CDS shall verify  the validity of the sidecar signature against an approved 9489  \nsidecar sig ners list . 9490  \nDFSR -26.5 The CDS shall verify  integrity of filter  report . 9491  \nDFSR -26.6 The CDS shall verify  the final hash, file size , and filename with actual data received 9492  \nfrom the DFS of a PASS or PASS WITH CHANG E. 9493  \nDFSR -26.7 The CDS shall verify  that if PASS WITH CHANGE was the result then ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}687{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "686", "chunk": "original file 9494  \nhash and the filtered file hash are different.  9495  \nDFSR -27 The CDS shall reject all content that does not have an associated filter report . 9496  \nDFSR -28 The CDS shall reject all content whose associated filter  report did not confirm the file 9497  \nPASSED or PASSED WIT H CHANGE.  9498  \nDFSR -29 The CDS shall shutdown the associated dataflow if it receives both the filter reports 9499  \nfor FAILED or ERRORED content and the associated content.  9500  \nRationale:  If this occurs that means there is a failure in or compromise of  the DFS.  9501  \nDFSR -30 The CDS shall shutdown the associated dataflow if it receives content without an 9502  \nassociated filter report  9503  \nRationale:  If this occurs that means there is a failure in or compromise of the DFS.  9504  \nDFSR -31 The CDS shall shutdown the associated dataflow if it receives FAILED or ERRORED 9505  \nfilter reports from a DFS component in a DSFR -DP-3 architecture.  9506  \nRationale:  If this occurs that means there is a failure in or compromise of the DFS.  9507  \nDFSR -32 The CDS shall validate the SHA -384 (or higher) hashes match the actual calculated 9508  \nhashes for all content referenced in the filter report.  9509  \nDFSR -33 The CDS shall validate the integrity and signatures for ea", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}688{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "687", "chunk": "ch filter report.  9510  \nDFSR -34 The CDS shall validate the type of the content provided by the DFS content and then 9511  \nverify that the filters used by the DFS co mponent (as listed in the filter report) are correct 9512  \nfor the type of the content.  9513  \nDFSR -35 The CDS shall unpack any archive formats (e.g., zip, tar) verify  the filenames and 9514  \nhash(es) of the content matches those in the filter report.  9515  \nDFSR -36 All journaled content, regardless of filtering results, will be SFTF wrapped prior to 9516  \ntransfer to DCO of CDS OOB . 9517  \nDFSR -37 DFS system should implement a n orchestration (see JSR, FRVR , and RPR  9518  \nrequirements)  capability to route content between different DFS components.  9519UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 327 of 397 Clarification:  The orchestration capability implements the job scheduler functionality 9520  \nand a filter report validator. However,  the CDS is implementing the security 9521  \nenforcing filter report validator.  9522  \nDFSR -38 Each DFS virtual machine, filter instance, o r container  must have unique  and separate  95", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}689{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "688", "chunk": "23  \nPKI keys per device for its TLS connections and signing filter reports.  9524  \nDFSR -39 The DFS must be capable of sending operating system logs, DFS component logs 9525  \n(e.g., protocol adapter, filters, orchestration components), filter reports, and all JAL data 9526  \nincluding quarantined files to the DCO of CDS OOB.  9527  \n24 CDS Decommissioning and Reuse Requirements (CDRR)  9528  \nThis section  covers the decommiss ioning and reuse of CDS hardware and related items.  9529  \nCDRR -1 If unclassified or classified CDS hardware reached end -of-life or has failed and can not 9530  \nbe repaired it shall  be destroyed in accordance with CNSSI No. 4004.1, Destruction and 9531  \nEmergency Protection Procedures for COMSEC and Classified Material . 9532  \nCDRR -2 CDS hardware may be repurposed for other uses if hard drives or other storage media 9533  \nare replaced and the classification of the new system is the same or higher.  9534  \nCDRR -3 CDS  hardware shall not be  declassified and resold.   9535  \nCDRR -4 CDS unclassified or classified CDS documentation and media including paper 9536  \ndocumentation,  hard drives (e.g., magnetic or solid state), dongles , USB devices, 9537  \nCDROM/DVD/Blu -Ray disc s, flash memory chips, or similar electronic media that can 9538  \nstor", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}690{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "689", "chunk": "e CDS software , documentation, and or configuration information must be  destroyed  9539  \nin accordance with  NSA/CSS Policy Manual 9 -12, Storage Device Sanitization and 9540  \nDestruction Man ual.270 9541  \nClarification:  NSA guidance on media destruction including Evaluated Product Lists is 9542  \navailable at https://www.nsa.gov/Resources/Media -Destruction -Guidance  9543  \nCDRR -5 CDS hardware that implements anti -tamper techniques must be tampered and zeroized 9544  \nprior to destruction procedures.  9545  \n 9546  \n25 Hardware -based  CDS  and Hardware -based Components 9547  \nRequirements (HWCR)  9548  \nThis section provides requirements for a hardware -based CDS  and hardware -based CDS 9549  \n \n270 http://media.defense.gov/2021/Oct/05/2002867897/ -1/-1/0/NSACSS%20PM%209 -12%2020201204.PDFUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 328 of 397 Components (i.e.,  Protocol Filtering Diodes (PFD ) and Hardware Content Filtering Devices 9550  \n(HCFD) ). This section merges the previous THA and HWR section and includes changes 9551  \nrequired to comply with the CDS Anti -Tamper and TEMPEST Impleme", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}691{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "690", "chunk": "ntation Requirements . 9552  \nHardware based CDS that intend to run filtering  software on embedded application processors 9553  \n(e.g., ARM\u00ae  or PowerPC\u00ae -based) fall into the THA category and are not considered a 9554  \nhardware -based CDS since some of the security enforcement is in software. However, this 9555  \nsection will apply to the hardware comp onents.  9556  \nIn this section, the term \u201cmanagement CPU\u201d refers to either a hard CPU included in the FPGA 9557  \npackage or soft CPU implemented in the FPGA fabric.  9558  \nIf a CDS developer, is creating a hardware -based CDS or HCFD, we strongly recommend 9559  \ndesigning the syste m to use c onfigurable rulesets that can loaded onto the device. Hardcoded 9560  \nrulesets will require an LBSA to verify new or changed rulesets.  9561  \nIf a hardware -based filtering solution is being developed, contact the NCDSMO to discuss before  9562  \nimplementation . 9563  \nThis section is divided  into three subsections:  9564  \n1) General  hardware requirements which apply to all hardware -based CDS and their 9565  \ncomponents  9566  \n2) Hardware -based CDS  or components , for non -tactical environments  9567  \n3) Hardware -based CDS, for tactical environments  9568  \nMost hardware -based CDS and CDS components leverage field programma", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}692{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "691", "chunk": "ble gate arrays271 due 9569  \nto their flexibility and ability to be reconfigured. Howe ver, this document does not require 9570  \nFPGAs be used. A CDS developer can use custom ASICs or other hardware mechanisms. If a 9571  \nCDS developer is considering using non -FPGA hardware as the basis for their hardware -based 9572  \nCDS or CDS components, please contact the NCDSMO to discuss.  9573  \n 9574  \nIn hardware -based CDS and hardware -based CDS components, the hardware is primarily used 9575  \nfor domain separation, protocol handling, and content filtering. In hardware -based tactical CDS 9576  \nthe hardware also implements  the anti -tamper functio nality.  9577  \n 9578  \n25.1 Hard ware-based CDS/Components General Hardware Requirements 9579  \n(HWC -GHR)  9580  \nHWC -GHR -1 FPGAs shall leverage the FGPA vendor\u2019s (e.g., Xilinx272) guidance on how to 9581  \n \n271 https://ie eexplore.ieee.org/stamp/stamp.jsp?arnumber=6849432  \n272 https://www.xilinx.com/applications/isolation -design -flow.htmlUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 329 of 397 implement red/black separation (also called isolated design", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}693{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "692", "chunk": " flow).  9582  \nHWC -GHR -1.1 The design documentation for the hardware must describe how the red/back 9583  \nseparation is implemented . 9584  \nHWC -GHR -1.2 FPGA must fence all isolated regions by at least one fence tile  from other 9585  \nunrel ated logic regions.  9586  \nHWC -GHR -2 Only Xilinx FPGA\u2019s that support the Xilinx Security Monitor (SecMon) IP can 9587  \nbe used  and the SecMon IP must be used . 9588  \nHWC -GHR -3 FPGA\u2019s must disable partial reconfiguration after provisioning of the FGPA.  9589  \nHWC -GHR -4 If the hardware device is implementing filtering,  then it shall be implemented 9590  \nprior to and in series with the one -way mechanism . 9591  \nHWC -GHR -5 The use of Joint Test Access Group (JTAG) ports may be used for initial loading 9592  \nof FPGA firmware . 9593  \nHWC -GHR -6 The JTAG port must be disabled for production units .  9594  \nHWC -GHR -7 The initial FPGA load should only contain the logic necessary to support boot 9595  \nstrapping of the FPGA so that remaining FPGA code can be cryptographically verified 9596  \nand loaded via other means (e.g., not the JTAG interface).  9597  \nRationale: The intent is that by minimizing  the bootstrapping simple there should be 9598  \nlittle need to change it over time and thus the impact of physically disabling", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}694{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "693", "chunk": " access to 9599  \nthe JTAG interface should have minimal impact on depot repairs and other 9600  \nmaintenance activities.  9601  \nHWC -GHR -8 FPGA filtering must be implemented in VHDL or SystemVerilog (i.e., IEEE 9602  \n1800 -2017273 or higher).  9603  \nClarification:  The VHDL and SystemVerilog can be generated via an automated tool 9604  \nbased on code written in a higher -level language like C.  9605  \nHWC -GHR -9 The rulesets must be digitally signed and verified by the F PGA during load  and 9606  \nprotected from change in the FPGA.  9607  \nClarification :  For example, if the FPGA supports dynamic reconfiguration that must be 9608  \ndisabled after provisioning of the FPGA.  9609  \nHWC -GHR-9.1 Rulesets must be  stored encrypted . 9610  \nClarification:  Details of the how decryption is do ne depends on the deployment: non - 9611  \ntactical versus tactical.  9612  \nHWC -GHR -10 For a bidirectional flow, a hardware -based filtering (e.g., an HCFD) solution 9613  \n \n273 https://en.wikipedia.org/wiki/SystemVerilogUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 330 of 397 satisfies the third  filter impleme", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}695{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "694", "chunk": "ntation  requirement  if the filtering is determined to be 9614  \nsufficient to address the data attack and data hiding risks of the data type.  9615  \nClarification: For an  HCF D, if it is implementing the OWT -12 \u201cRule of Three\u201d 9616  \nrequirement. Redundant and independent software filtering will  still be needed on 9617  \nhigh and low pitcher/catchers or on the high side multi -domain CDS (see OWTDP - 9618  \n4C). 9619  \nHWC -GHR-10.1 In cases where the data format is simple enough that all syntactic, semantic, 9620  \nand logical filt ering can be performed in the FPGA then external software filtering may 9621  \nnot be required.  9622  \nHWC -GHR-10.2 In order to replace external software filtering with FPGA filtering, there must 9623  \nbe redundant and independent implementations of the filters.  9624  \nHWC -GHR-10.3 For each flow direction , the same implementations maybe used but not the 9625  \nsame instance .  9626  \nHWC -GHR-10.4 Each flow direction shall have its own instance of the one -way transfer 9627  \nmechanism.  9628  \nHWC -GHR -11 A soft core CPU (e.g., ARM\u00ae, OpenRISC,  RISC -V\u2122, MicroBlaze \u2122, etc.) may 9629  \nbe used on an FPGA to configure dataflow related portions of the FPGA fabric.  9630  \nHWC -GHR -12 A soft core CPU may be used on an FPGA for Protocol Adap", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}696{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "695", "chunk": "ters.  9631  \nHWC -GHR -13 A soft core CPU may be used on an FPGA for most data normalization and 9632  \ndenormalization functions.  9633  \nClarification:  Most data denormalization functions (e.g., converting XML based into 9634  \nfixed format binary, perhaps via Apache Daffodil \u2122) are not considered security 9635  \nrelevant. However, for some data t ypes like images, audio (file or streaming), and 9636  \nvideo (file or streaming) the denormalization function is usually lossy compression of 9637  \nthe data (e.g., raw bitmap to a JPEG) and the lossy compression is security relevant.  9638  \nHWC -GHR -13.1 Security relevant normalization and denormalization mechanisms shall be 9639  \nimplemented in FPGA logic.  9640  \nHWC -GHR -14 A soft core CPU shall not be used in an FPGA for content filtering.  9641  \nRationale:  Running software on an FPGA based soft CPU provides no increased security 9642  \nand has the same attack risks as a traditional CPU. If a soft core CPU is used for 9643  \nfiltering, it will be evaluated as software running on a regular CPU and the solution 9644  \nwill get no credit for hardware -based filtering.  9645  \nHWC -GHR -15 A soft core CPU shall  be a 64-bit CPU  if any operating systems is being in the 9646  \nsoft core.  9647  \nHWC -GHR -16 A soft core m ay ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}697{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "696", "chunk": "be a s small as an 8-bit CPU (e.g., Picoblaze \u2122) if it is running a 9648  \nsingle purpose application  with no operating system.  9649UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 331 of 397 HWC -GHR -17 Hardware based CDS and HCFDs shall implement an assured pipeline design 9650  \npattern with filtering logic implemented in separate FPGA logic separated by FPGA 9651  \nbased First -In/First -Out (FIFO) mechanisms.  9652  \nHWC -GHR -18 All hardware -based filtering must validate the content syntactically and 9653  \nsemantically.  9654  \nClarification: Syntactic parsing validates that the content complies with the data 9655  \nstructure defined in its specification. Semantic parsing validates values of the data 9656  \nfields comply with the type and value constraints stated in the specification. This 9657  \napplies to hardware -based CDS, PFD, and HCFDs.  9658  \nHWC -GHR -19 When implementing communications interfaces (e.g., USB, Ethernet , PCIe ) on 9659  \nan FPGA, separate instances of the communications  interface controller logic must be 9660  \nused for each interface.  9661  \nClarification: If the FPGA i", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}698{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "697", "chunk": "s not capable of implementing independent USB, Ethernet, 9662  \nor PCIe controllers, then additional FPGA s or USB/Ethern et/PCIe ASIC  will have to 9663  \nbe used  in the other domains connected to the FPGA.  9664  \nHWC -GHR -20 Hardware filtering mechanisms must log all failures in filtering.  9665  \nHWC -GHR -21 FPGA Physically Unclonable Functions (PUF) shall not be used for key 9666  \ngeneration to support bitstream protection or anti -tamper functionality.  9667  \nHWC -GHR -22  HCFD and Hardware -based CDS  that use external ruleset compilers that 9668  \nconvert the ruleset s (e.g., XSD) to into FPGA logic is allowed  however  direct control of 9669  \ncompilation  and signing process shall not be  provided to the user.  9670  \nClarification: Essentially the user  cannot control how the rulesets are converted  into a 9671  \nformat used by the FGPA.  9672  \nHWC -GHR -22.1 CDS that use external ruleset compilers shall  have the ability to run the 9673  \ncompiled ruleset on a n FPGA simulator  with goo d and bad data to verify the ruleset 9674  \nworks as expected.  9675  \nHWC -GHR -22.2 The ruleset compilation process and toolchain will be  evaluated in the LBSA  9676  \nfor the CDS . 9677  \n25.2 Hardware -based CDS/Components Non -Tactical Requirements 9678  \n(HWC -NTR)  9679  ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}699{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "698", "chunk": "\nThese requirements are for hardware -based CDS and hardware -based CDS Components used in 9680  \nnon-tactical environments.  9681  \n HWC -NTR-1 A hardware -based CDS/ component leveraging a System -on-a-Chip (SOC) that 9682UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 332 of 397 includes a physical General Purpose CPU (GPCPU)274 in the same package as a FPGA 9683  \nshall only use the GPCPU for the management, monitoring, and configuration of the 9684  \nFPGA and supporting chips.  9685  \nClarification:  This only applies if the FPGA is being used for one -way transfer (e.g., 9686  \ndiode) enforcement and/or for  hardware -based filtering that is considered physically 9687  \ninline in the dataflow pipeline. If the SOC is solely using the FPGA for high 9688  \nperformance processing of the data (e.g., using the FPGA to do massively parallel 9689  \ncalculations on an image) then this requ irement does not apply. However, the 9690  \nhardware -based filtering in this context is not considered physically inline because it 9691  \nis under the complete control of software. If a GPCPU uses an FPGA on a daughter 9692", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}700{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "699", "chunk": "  \ncard (e.g., either via  PCI-E or a proprietary protocol)  as a sidecar  (the FPGA has no 9693  \nnetwork communications)  then the FPGA -based filter  is not considered physically 9694  \ninline .  9695  \nHWC -NTR-1.1 A hardware -based CDS/component leveraging a FPGA that needs to implement 9696  \nprotocol and data type filtering that cannot be fully implemented in the FPGA logic 9697  \nshould use a separate GPCPU in each domain connected (e.g., Ethernet, PCI -E) to the 9698  \nFPGA to implement  the protocol and data type filtering.  9699  \nHWC -NTR-1.2 A hardware -based CDS/component leveraging a FPGA should implement 9700  \nsyntactic and semantic validation of the content in the FPGA.  9701  \nRationale:  Essentially, the FPGA should focus on enforcing one -way dataflows, 9702  \nverifying the content is what it claims to be, and verifying that it fully complies 9703  \nsyntactically and semantically with its data format specification. While the software 9704  \nfilters in the CDS  would also do the same checks (so there is a redundant and 9705  \nindependent mechanism) it would do additional processing to address other data 9706  \nattack and data hiding issues that cannot be efficiently or effectively implemented in a 9707  \nFPGA. The software filters w ould also implement logical", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}701{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "700", "chunk": " filtering of data including 9708  \napplication of policy.  9709  \nHWC -NTR-1.3 A CDS using a FPGA for filtering shall not implement the filtering on a soft 9710  \nmicroprocessor core implemented in FPGA logic  as that is considered software \u2013based 9711  \nfiltering not hardware -based. The filtering must be implemented directly in FPGA logic.  9712  \nHWC -NTR-1.4 The GPCPU that is included within a System -on-a-Chip (SoC)  shall not be used 9713  \nfor dataflow processing.  9714  \nHWC -NTR-2 FPGAs used for domain separation and filtering shall not be configured from or 9715  \nbe capable of being configured from a GPCPU that is used to process dataflow data.  9716  \nClarification: If the FPGA is used solely for filtering and is a \u201csidecar\u201d to the GPCPU, 9717  \nthen it can be configured by its host GPCPU. In this case, the FPGA is not considered 9718  \n \n274 A GPCPU implemented in FPGA logic does not count as physical CPUs in this requirement.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 333 of 397 inline and thus not allowed to be used for domain separation.  9719  \nHWC -NTR -3 FPGA configuration must be sid", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}702{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "701", "chunk": "e -loaded into the FPGA memory via a 9720  \nmanagement interf ace and cannot be loaded from low or high sides.  9721  \nHWC -NTR -4 FPGA rulesets must be side -loaded into the FPGA memory via a management 9722  \ninterface and cannot be loaded from low or high sides.  9723  \nHWC -NTR -5 The management CPU shall validate the integrity and signature of the FPGA 9724  \nbitstreams prior to transfer for storage and SFPGA  configuration.  9725  \nHWC -NTR -5.1 If a management CPU is used, the SFPGA  must be able to independently verify 9726  \nthe bitstreams being loaded.  9727  \nHWC -NTR-5.2 The management CPU shall secure boot only from a local image stored  in non - 9728  \nvolatile storage . 9729  \nHWC -NTR -6 The management CPU shall only communicate to external systems over a 9730  \ndedicated system high management interface.  9731  \nHWC -NTR -6.1 The management interface physical layer protocol should be Ethernet or USB.  9732  \nHWC -NTR -7 The management CPU shall not have access to data being processed by the 9733  \nFPGAs.  9734  \nHWC -NTR -8 The management CPU may receive logs from the FPGA filtering logic, FPGA 9735  \nprotocol adapters, and external GPCPUs or pit cher/catchers (see OWTDP -6 and 9736  \nOWTDP -7). 9737  \nHWC -NTR -8.1 Each system  component sending logs to the mana", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}703{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "702", "chunk": "gement CPU must do so 9738  \nthrough separate and independent one -way transfer mechanisms.  9739  \nClarification: The same one -way technique/technology can be reused for each.  9740  \nHWC -NTR -8.2 The one -way transfer mechanism for log transfer to the management CPU shall 9741  \nbe within the FPGA fabrics.  9742  \nHWC -NTR -9 An HCFD shall have the ability to send logs to a DCO OOB via connection 9743  \nseparate from the management interface.  9744  \nHWC -NTR -10 An HCFD may have the ability to send logs to a DCO OOB via the management 9745  \ninterface.  9746  \n 9747  \n25.3 Hardware -based CDS/Components Tactical Requirements  (HWC - 9748  \nTR) 9749  \nThese requirements are for hardware -based CDS used in tactical environments.  Most platform 9750  \nsecurity requirements including sensors ; responses to sensors ; key generation, storage, 9751  \nmanagement, and use ; and zeroization  are covered in the CDS Anti -Tamper and TEMPEST 9752UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 334 of 397 Implementation Requirements  document.  9753  \nHWC -TR-1 A Security Watchdog Processor (SWP ) shall be used  to pr", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}704{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "703", "chunk": "ovid e secure system 9754  \nstartup for the SRAM -based FPGAs and any commodity CPUs . 9755  \nClarification: The SWP is usually implemented in a Non -Volatile  FPGA  and referred as 9756  \nthe W NVFPGA  in this document.  9757  \nHWC -TR-2 The SWP  shall provide system security monitoring  services for the active anti - 9758  \ntamper mechanisms.  9759  \nHWC -TR-3 A dedicated FGPA or ASIC , called the Secure Loading Device (SLD)  management 9760  \nCPU , shall be used to communicate with the  SLD.    9761  \nHWC -TR-3.1 The SLD management CPU  shall transfer the software, FPGA bitstreams, and 9762  \nrulesets, CDS configuration, system patches, and signing and decryption keys to the 9763  \nWNVFPGA for validation and storage.  9764  \nHWC -TR-4 The SWP  shall validate the integrity and signature of the FPGA bitstreams prior to 9765  \ntransfer to storage . 9766  \nHWC -TR-5 The SFPGA shall be responsible for configuring itself based on the decrypted 9767  \nconfiguration provided by the Security Watchdog process or. 9768  \nHWC -TR-6 The SWP  functionality shall not be implemented on a Commodity CPU or SRAM - 9769  \nbased FPGAs.  9770  \nHWC -TR-7 The SWP  shall be implemented on either a non -volatile FPGA or custom ASIC 9771  \nwith \u201cinstant on\u201d capabilities.  9772  \nHWC -TR-8 FPGA s with e", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}705{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "704", "chunk": "mbedded General Purpose CPUs (e.g., ARM\u00ae, RiscV \u2122) shall not be 9773  \nused in tactical CDS.  9774  \nHWC -TR-9 FPGAs may use a soft core CPU (e.g., ARM\u00ae, RiscV \u2122) to support remote 9775  \nmonitoring of the CDS, however, the soft core CPU shall have no ability to modify 9776  \nFPGA fabric.  9777  \n25.3.1  Tactical CDS FPGA Requirements  9778  \nThe requirements listed in the following subsections detail broad security and anti -tamper 9779  \nrequirements for F PGAs deployed within Tactical CDS. The implementation of these 9780  \nrequirements is often used as a respond to security related incidents or user initiated zeroization 9781  \nrequests.  Detailed implementation descriptions, definitions, and specifics of implementing t hese 9782  \nrequirements are available in security implementation guides from FPGA manufacturers like 9783UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 335 of 397 Xilinx275, Intel276, and Microchip277 278. Detailed specifications and requirements traceable to the 9784  \nrequirements below can be found in the classified do cument CDS A nti-Tamper and TEMPEST 9785  \nImplementation Require", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}706{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "705", "chunk": "ments .  9786  \n Overarching FPGA Requirements Applicable to any CDS SFPGA, WNVFPGA, and 9787  \nSNVFPGA  9788  \nFPGA -1 FPGAs shall have the ability to permanently disable any JTAG ports that are accessible 9789  \nat the FPGA physical package.  9790  \nFPGA -2 FPGAs shall have security monitoring and reporting circuitry.  9791  \nFPGA -3 FPGAs shall have the ability to disable any individual or all inputs and outputs.  9792  \nFPGA -4 FPGAs shall have the ability to zeroize  its logic fabric and internal memory.  9793  \n SFPGA Specific Requirements  9794  \nSFPGA -1 SFPGAs shall have capabilities for bitstream decryption and authentication.  9795  \nSFPGA -2 Deleted.  9796  \nSFPGA -3 SFPGAs shall have a true random number generator.  9797  \nSFPGA -4 SFPGAs shall have user programmable electronic fuses.  9798  \nSFPGA -5 SFPGAs shall have side -channel differential power analysis (DPA) resistance.    9799  \nSFPGA -6 Deleted.    9800  \nSFPGA -7 SFPGAs shall have boot decision circuitry that will terminate a boot sequence if 9801  \npredetermined environmental parameters are viola ted. 9802  \nSFPGA -8 SFPGAs shall have clock and voltage glitch detection  and response  capabilities . 9803  \nSFPGA -9 SFPGAs shall have temperature and voltage monitors that track the SFPGA state.  9804  \n \n275", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}707{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "706", "chunk": " https://www.xilinx.com/support/documentation/application_notes/xapp1098 -tamper -resist -designs.pdf  \n276 https://www.intel.com/content/www/us/en/docs/programmable/683823/2 2-1/device -security -overview -s10-fm-\ndm.html  \n277 https://www.microsemi.com/document -portal/doc_download/1245814 -PolarFire -FPGA -and-PolarFire -SoC-\nFPGA -Security -User -Guide  \n278 https://www.microsemi.com/document -portal/doc_download/132037 -ug0443 -smartfusion2 -and-igloo2 -fpga-\nsecurity -best-practices -user-guideUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 336 of 397 SFPGA -10  SFPGAs should  have single event upset (SEU280) circuitry, capable of detecting and 9805  \nrecovering from upsets.  9806  \nSFPGA -11 SFPGAs shall be able to  permanently disable design for test (DFT) functionality, 9807  \nnormally used for validating and testing hardware during development.  9808  \nSFPGA -12 SFPGAs shall have an internal, uninterruptable clock source.  9809  \nSFPGA -13 SFPGAs shall have  a capability  to zeroize  key material stored in Battery -Backed 9810  \nRandom Access Memory (BBRAM).   9811  \nClarification:  This BBRAM is n", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}708{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "707", "chunk": "ot on the FPGA die.  9812  \nSFPGA -14 SFPGAs shall have the capability to halt its internal boot sequence if predetermined 9813  \nconditions are not met during the stages of boot.  9814  \nSFPGA -15 SFPGAs shall have a dynamic JTAG monitor.  9815  \nSFPGA -16 SFPGAs s hall have  a capability to permanently disable internal encryption and 9816  \ndecryption circuitry.  9817  \nSFPGA -17 SFPGAs shall have the ability to log security related events for retrieval by an 9818  \nauthorized user or other FPGA.  9819  \nSFPGA -18 SFPGAs shall have the capability permanently disable itself.  9820  \nSFPGA -19 SFPGAs shall have the capability for partial reconfiguration.  9821  \n WNVFPGA Specific Requirements  9822  \nWNVFPGA -1 WNVFPGAs shall have a unique device serial number . 9823  \nWNVFPGA -2 WNVFPGAs  shall have the capability  to detect internal voltage fluctuations.  9824  \nWNVFPGA -3 WNVFPGAs shall have the capability to monitor the temperature of the 9825  \nWNVFPGA.  9826  \nWNVFPGA -4 Deleted.  9827  \nWNVFPGA -5 WNVFPGAs shall have clock and voltage glitch detection and response  9828  \ncapabilities . 9829  \nWNVFPGA -6 WNVFPGAs shall have a security mesh built into the device package.  9830  \nWNVFPGA -7 WNVFPGAs shall have a capability to detect changes to internal clocks.  9831  \nWNVFPG", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}709{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "708", "chunk": "A -8 WNVFPGAs shall have JTAG activity detector.  9832  \n \n280 https://www.xilinx.com/support/documentation/white_papers/wp395 -Mitigating -SEUs.pdfUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 337 of 397 \n SNVFPGA Specific Requirements  9833  \nSNVFPGA -1 SNVFP GAs shall be capable of battery powered operation for a minimum of 3 9834  \nyears from the date of final CDS assembly.  9835  \nSNVFPGA -1.1 SNVFPGAs should be capable of battery powered operation for a minimum of 5 9836  \nyears from the  date of final CDS assembly.  9837  \nSNVFPGA -2 SNVFPGA s shall be coupled with  power hold up capacitors with sufficient 9838  \ncapacity to zeroize or erase all decryption keys  if battery power is interrupted for a 9839  \npredetermined period of time.  9840  \nSNVFPGA -3 SNVFPGAs shall be capable monitoring and responding to tamper detection 9841  \nsensors while operating on battery power.  9842  \n  9843UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}710{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "709", "chunk": " \nPage 338 of 397 26 Government Documents  9844  \n\u2022 Cross Domain Solution (CDS)  Development and Testing Environment  Security Requirements 9845  \nNCDSMO Doc ID: NCDSMO -R-00011 -001_01, NCDSMO  9846  \n\u2022 CDS Anti -Tamper  and TEMPEST  Implementation Requirements , NCDSMO Doc ID:   9847  \nNCDSMO -R-00018 -001_00 , NCDSMO  9848  \n\u2022 Required Audit Events for Cross Domain Solutions , NCDSMO Doc ID:  NCDSMO -R- 9849  \n00019 -001_00 , NCDSMO  9850  \n\u2022 Primer for Cyber Incident Response of Cross Domain Solutions (CDS) , NCDSMO Doc ID: 9851  \nNCDSMO -G-00049 -001_ 01, NCDSMO  9852  \n\u2022 Guidance for Enabling Rapid Application Deployment with Cross Domain Solution , 9853  \nNCDSMO Doc ID: NCDSMO -G-00027 -001_02, NCDSMO  9854  \n\u2022 Cyber One -Way Taps Technical Requirements , NCDSMO Doc ID:  NCDSMO -R-00016 - 9855  \n001_0 1, NCDSMO  9856  \n\u2022 Security Assessment of Cross Domain Solutions (CDS): Process and Requirements , 9857  \nNCDSMO  Doc ID: NCDSMO -R-0000 3-004_00, NCDSMO  9858  \n\u2022 CDS 101: An Introduction to  Domain Solution s, NC DSMO Doc ID: NCDSMO -G-00032 - 9859  \n001_00 , NCDSMO  9860  \n\u2022 Versioning and Patching Requirements for Cross Domain Solutions (CDS) , NCDSMO Doc 9861  \nID: NCDSMO -R-00002 -003_00, NCDSMO  9862  \n\u2022 Basic XML Security Consideration , NCDSMO Doc ID: NCDSMO -G-0000", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}711{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "710", "chunk": "2 -001_00 , 9863  \nNCDSMO  9864  \n\u2022 Inspection and Sanitization Gui dance for Data Types (multiple documents), NCDSMO  9865  \n\u2022 Malware Testing Process for Content Filtering Systems , NCDSMO  9866  \n\u2022 Frequently Asked Questions about the Release and Export of Cross Domain Solutions , 9867  \nNCDSMO Doc  ID: NCDSMO -G-00028 -001_01 , NCDSMO  9868  \n\u2022 Best Practices Guide for Operating a Cross Domain Solution in a Virtualized Environment , 9869  \nNCDSMO  Doc ID: NCDSMO -G-00042 -001_ 02, NCDSMO  9870  \n\u2022 Guidance for Remote Monitoring of Cross Domain Solutions Using Simple Network 9871  \nManagement Protocol (SNMP) Version 3 , NCDSMO Doc ID: NCDSMO -G-00033 -001_02 , 9872  \nNCDSMO  9873  \n\u2022 Verification, Inspection, and Sanitization (VIS) Specification , NCDSMO Doc  ID: NCDSMO - 9874  \nS-00001 -001_0, NCDSMO  9875  \n\u2022 Filter Sidecar Protocol (FSP) Specification , NCDSMO Doc  ID: NCDSMO -S-00002 - 9876  \n001_06 , NCDSMO  9877  \n\u2022 Cross Domain Solution (C DS) Configuration & Compliance Report (C3R) Specification , 9878  \nNCDSMO Doc ID: NCDSMO -S-00006 -001_00 , NCDSMO  9879  \n\u2022 Guard Remote Management Protocol (GRMP) Specification , NCDSMO Doc ID: NCDSMO - 9880  \nS-00008 -003_00 , NCDSMO  9881  \n\u2022 Using Linux Secure Computing (SECCOMP) Mode in Cross Domain Solutions  (NCDSMO - 9882  \nG", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}712{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "711", "chunk": "-00050 -001_00 ), NCDSMO  9883UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 339 of 397 \u2022 Manage and Secure Processes on Linux -based Cross Domain Solutions Using systemd 9884  \n(NCDSMO -G-00051 -001_00 ), NCDSMO  9885  \n\u2022 Using Linux Namespaces and Control Groups  (CGROUP) to Secure Cross Domain Solution 9886  \nProcesses  (NCDSMO -G-00052 -001_00 ), NCDSMO  9887  \n\u2022 Using Linux Containers with Cross Domain Solutions  (NCDSMO -G-00053 -001_00 ), 9888  \nNCDSMO  9889  \n\u2022 Using Linux Capabilities  in Cross Domain Solutions  (NCDSMO Doc ID: NCDSMO -G- 9890  \n00055 -001_00 ), NCDSMO  9891  \n\u2022 Analysis of Linux Interprocess Communication (IPC) Mechanisms for use in Cross Domain 9892  \nSolutions  (NCDSMO -G-00054 -001_00) , NCDSMO  9893  \n\u2022 Suspect File Transmission Format ( SFTF ) Specification , NCDSMO, Doc ID: NCDSMO -S- 9894  \n00003 -002_01 9895  \n\u2022 NSA/ CSS Policy Manual 9 -12, Storage Device Sanitization and Destruction Manual , 4 9896  \nDecember 2020  9897  \n\u2022 Linux Standard Base (LSB) 5.0 Core Specification , The Linux Foundation, 3 June 2015  9898  \n\u2022 Filesystem Hierarchy Standard (FHS) 3.0 Specification ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}713{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "712", "chunk": ", The Linux Foundation , 3 June 2015  9899  \n\u2022 U.S. Department of Defense Instruction ( DoD I) 8500.01 Cybersecurity, dated March 14, 9900  \n2014  9901  \n\u2022 U.S. Department of Defense Instruction ( DoD I) 8510.01, \u201cRisk Management Framework 9902  \n(RMF) for DoD  Information Technology (IT)\u201d, Change 2, dated July 28, 2017 . 9903  \n\u2022 U.S. Department of Defense Instruction ( DoD I) 8540.01, \u201c Cross Domain (CD) Policy\u201d, 9904  \nChange 1 dated August 28, 2017  9905  \n\u2022 Chairman Joint Chiefs of Staff Instruction (CJCSI) 6510.06C, \u201cCommunications Security 9906  \nReleases to Foreign Nations\u201d, November 8,  2013  9907  \n\u2022 NIST SP 800 -53 Rev 5, \u201cSecurity and Privacy Controls for Federal Information Systems and 9908  \nOrganizations,\u201d September 2020 (with updates as of 10 December 2020)  9909  \n\u2022 Committee on National Security Systems Instruction (CNSSI) No. 1253, \u201cSecurity 9910  \nCategorizatio n and Control Selection for National Security Systems\u201d , 29 July 2022.  9911  \n\u2022 CNSSI 1253, Appendix F, Attachment 3, \"Cross Domain Solution Overlay\", 1 February 9912  \n2023   9913  \n\u2022 CNSSI 1253, Appendix E, Attachment 5, \u201cClassified Information Overlay\u201d. 30 September 9914  \n2022  9915  \n\u2022 CNSSI No . 4004.1, Destruction and Emergency Protection Procedures for COMSEC and 9916  \nClassified Material  991", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}714{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "713", "chunk": "7  \n\u2022 International Traffic in Arms Regulations (ITAR) Part 121, Category XIII (b) (4)  9918  \n\u2022 Defense Security Cooperation Agency, \u201cSecurity Assistance Management Manual\u201d, August 9919  \n9, 2015  9920  \n\u2022 US Military Handbook MIL -HDBK -520a Systems Requirements Document (SRD) Guidance , 9921  \n19 Dec 2011  9922  \n\u2022 MIL-STD -6016 F, Department of Defense Interoperability Standard: Tacti cal Data Link 9923  \n(TDL) Link -16 Message Standard, Version F  9924UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 340 of 397 \u2022 MIL-STD -3011, Department of Defense Joint Range Extension Application Protocol 9925  \n(JREAP)  9926  \n\u2022 MIL-STD -6040 B, Department of Defense Interface Standard: United States Message Text 9927  \nFormatting Program, 26 Augu st 2009   9928  \n\u2022 DoD I 5200.44, Protection of Mission Critical Functions to Achieve Trusted Systems and 9929  \nNetworks (TSN)  9930  \n\u2022 Supply Chain Attack Patterns:   Framework and Catalog , Office of the Deputy Assistant 9931  \nSecretary of Defense for Systems Engineering, August 2014.  9932  \n\u2022 Key Practices and Implementation Guide for DoD  Comprehensive National Cyber", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}715{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "714", "chunk": "security 9933  \nInitiative 11 Supply Chain Risk Management Pilot Program , DoD  SCRM Program 9934  \nManagement Office (PMO), 25 February 2010  9935  \n\u2022 Department of Defense Instruction 5000.2:   Operat ion of the Defense Acquisition System , 9936  \nOffice of the Under Secretary of Defense for Acquisition, Technology and Logistics, Change 9937  \n3, August 10, 2017 . 9938  \n\u2022 Department of Defense Instruction 5200.44:   Protection of Mission Critical Function to 9939  \nAchieve Trusted Systems and Networks (TSN) , Office of the Under Secretary of Defense for 9940  \nAcquisition, Technology and Logistics, 27 July 2017  9941  \n\u2022 Enhanced Procedures for Enterprise -wide Use of Section 806 Supply Chain Risk 9942  \nManagement Authorities for DoD  National Securi ty Systems , Deputy Secretary of Defense, 9943  \n13 March 2018  9944  \n\u2022 NIST Special Publication 800 -161:  Supply Chain Risk Management Practices for Federal 9945  \nInformation Systems and Organizations , National Institute of Standards and Technology, 9946  \nApril 2015  9947  \n\u2022 DSB Task Force o n Cyber Supply Chain , Office of the Under Secretary of Defense for 9948  \nAcquisition, Technology, and Logistics, February 2017  9949  \n\u2022 Committee on National Security Systems Directive 505: Supply Chain Risk Management , 9950  \nCNSS", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}716{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "715", "chunk": " 26 July 2017  9951  \n\u2022 Intelligence Community Directive 731: Supply Chain Risk Management , Office of the 9952  \nDirector of National Intelligence, 7 December 2013  9953  \n\u2022 Intelligence Community Directive 731 -01: Supply Chain Criticality Assessments , Office of 9954  \nthe Director of National Intelligence, 2 October 2015  9955  \n\u2022 Intelligence Community Directive 731 -02: Supply Chain Assessments , Office of the Director 9956  \nof National Intelligence, 17 May 2016  9957  \n\u2022 Intelligence Community Directive 731 -03: Supply Chain Information Sharing , Office of the 9958  \nDirector of National Intelligence, 29 June 2017  9959  \n\u2022 Intelligence Community Directive 731 -03 Annex A: Supply Chain Information Sharing 9960  \nImplementation , Office of the Director of National Intelligence, no date.  9961  \n\u2022 Defense Standardization Program , http://www.dsp.dla.mil  9962  \n\u2022 The Inevitability of Failure: The Flawed Assumpt ion of Security in  Modern Computing 9963  \nEnvironments , https://www.nsa.gov/resources/everyone/digital -media - 9964  \ncenter/publications/research -papers/assets/files/the -inevitability -of-failure -paper.pdf  9965UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//RE", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}717{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "716", "chunk": "L TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 341 of 397 \u2022 UEFI Secure Boot Customization, National Security Agency, Septemb er 2020, v1.1, 9966  \nhttps://media.defense.gov/2020/Sep/15/2002497594/ -1/-1/0/CTR -UEFI -SECURE -BOOT - 9967  \nCUSTOMIZATION -20200915.PDF/CTR -UEFI -SECURE -BOOT -CUSTOMIZATION - 9968  \n20200915.PDF  9969  \n\u2022 GCHQ/NCSC, \u201cSecurity principles for cross domain solutions\u201d, 21 January 2021,  9970  \nhttps://www.ncsc.gov.uk/collection/cross -domain -solutions  9971  \n\u2022 GCHQ/NCSC, \u201c Design Pattern: Safely Exporting Data \u201d, 13 December 2019, 9972  \nhttps://www.ncsc.gov.uk/guidance/design -pattern -safely -exporting -data 9973  \n\u2022 GCHQ/NCSC, \u201cPattern: Safely Importing Data\u201d, 15 July 2018,  9974  \nhttps://www.ncsc.gov.uk/guidance/pattern -safely -importing -data 9975  \n 9976  \n27 Non-Government Publications  9977  \n\u2022 The Syslog Protocol , IETF RFC 5424  9978  \n\u2022 Transmission of Syslog Messages over TCP,  IETF RFC 6587  9979  \n\u2022 Transport Layer Security (TLS) Transport Mapping for Syslog , IETF RFC 5425  9980  \n\u2022 Transmission of Syslog Messages over UDP , IETF RFC 5426  9981  \n\u2022 Transport Layer Security (TLS) Protocol , IETF RFC 5246  9982  \n\u2022 Datagram Transport Layer Security  (DTLS) , IETF RFC  6347  9983  \n\u2022 Datagram Transport Layer Sec", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}718{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "717", "chunk": "urity (DTLS) Transport Mapping for Syslog , IETF  RFC 6012  9984  \n\u2022 Signed Syslog Messages , IETF RFC 5848  9985  \n\u2022 \u201cExtensible Markup Language (XML) 1.0 (Fifth Edition)\u201d, W3C, 26 November 2008  9986  \n\u2022 \u201cExtensible Markup Language (XML) 1.1 (Second Edition)\u201d specification dated 16 August 9987  \n2006, edited in place 29 September 2006  9988  \n\u2022 \u201cXML Sche ma Part 0: Primer Second Edition\u201d, W3C, 28 October 2004  9989  \n\u2022 \u201cXML Schema Part 1: Structures Second Edition\u201d, W3C, 28 October 2004  9990  \n\u2022 \u201cXML Schema Part 2: Datatypes Second Edition\u201d, W3C, 28 October 2004  9991  \n\u2022 \u201cXML Schema Definition Language (XSD) 1.1 Part 1: Structures\u201d, W3C, 5 April 2012  9992  \n\u2022 \u201cXML Schema Definition Language (XSD) 1.1 Part 2: Datatypes\u201d, W3C, 5 April 2012  9993  \n\u2022 \u201cXSL Transformations (XSLT)\u201d, Version 1.0, 16 November 1999  9994  \n\u2022 \u201cXML Path Language (XPath)\u201d, Version 1.0, 16 November 1999 (Status updated October 9995  \n2016)  9996  \n\u2022 \u201cXSL Tran sformations (XSLT)\u201d Version 2.0, 23 January 2007  9997  \n\u2022 \u201cXML Path Language (XPath) 2.0 (Second Edition)\u201d, 14 December 2010 (Link errors 9998  \ncorrected 3 January 2011; Status updated October 2016)  9999  \n\u2022 \u201cXML Signature Syntax and Processing Version 1.1\u201d, W3C, 11 April 2013  10000  \n\u2022 \u201cXML Encryption Syntax and Processing Version 1.1\u201d, W3C, 11", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}719{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "718", "chunk": " April 2013  10001  \n\u2022 \u201cCanonical XML 1.1\u201d, W3C, 2 May 2008  10002  \n\u2022 \u201cInformation technology, Document Schema Definition Languages (DSDL), Part 3: Rule - 10003UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 342 of 397 based validation, Schematron (ISO/IEC 19757 -3:2006)\u201d, First Edition  10004  \n\u2022 \u201cInformation technology, Document Schema Definition Languages (DSDL), Part 3: Rule - 10005  \nbased validation, Schematron (ISO/IEC 19757 -3:2016)\u201d, Second Edition  10006  \n\u2022 Unified Extensible Firmware Interface Specification , Version 2.7 , May 2017  10007  \n28 Trademarks  10008  \nMicrosoft Office \u00ae, Microsoft Word\u00ae, Microsoft PowerPoint\u00ae,  ActiveX\u00ae, Hyper -V\u00ae, 10009  \nWindows\u00ae , VS Code\u00ae , and Active Directory\u00ae are registered trademarks of Microsoft 10010  \nCorporation.  10011  \nPitBull\u00ae is a registered trademark of General Dynamics Mission Systems Inc.  10012  \nRed Hat\u00ae and Red Hat\u00ae Enterprise Linux\u00ae (RHEL\u00ae) are registered trademarks of Red Hat\u00ae 10013  \nInc. 10014  \nVirtualBox\u00ae, SPARC\u00ae, Solaris\u00ae, Oracle\u00ae, and Java\u00ae are registered trademarks of Oracle 10015  \nand/or its affiliates.  10016  \nAMD\u00ae and AMD Epyc\u00ae ar", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}720{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "719", "chunk": "e registered trademark s of Advanced Micro Devices, I nc. 10017  \nIntel\u00ae , Altera \u00ae, and Intel Xeon\u00ae are registered trademark s of Intel Corporation.  10018  \nLattice\u00ae is registered trademark of Lattice Semiconductor Corporation.  10019  \nMicrosemi \u00ae is a registered trademark  of Microsemi Corporation.  10020  \nPostScript\u00ae and Adobe Acrobat\u00ae is a registered trademark of Adobe Systems, Inc.  10021  \nArm\u00ae  is a registered trademark of Arm Limited (or its affiliates).  10022  \nVMware ESXi\u00ae, VMware Workstation\u00ae, VMware Fusion\u00ae are registered trademarks of 10023  \nVMware, Inc.  10024  \nCitrix\u00ae, XenDesktop\u00ae and XenServer\u00ae are  registered trademarks of  Citrix System, Inc.  10025  \nIntegrity\u00ae is a registered trademark of  Green Hills , Inc.  10026  \nLynxSecure\u00ae is a registered trademark of Lynx Software Technologies, Inc.  10027  \nHP\u00ae is a trademark of the Hewlett Packard Company, Inc.  10028  \nUNIX\u00ae  is a registered trademark of The Open Group.  10029  \nPOSIX\u00ae  is a registered trademark  of the Institute of Electrical and Electronic Engineers, Inc . 10030  \nPowerPC\u00ae  is a registered  trademark of International Business Machines, Inc . 10031  \nDell Technologies \u00ae, Dell\u00ae, Dell EMC \u00ae, and other trademarks are trademarks of Dell Inc. or its 10032  \nsubsidiaries.  10033  \nXilinx \u2122, Kintex \u2122", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}721{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "720", "chunk": ", MicroBlaze \u2122, UltraScale \u2122, UltraScale+ \u2122, Virtex \u2122, and Zynq \u2122 are 10034  \ntrademarks of Xilinx . 10035UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 343 of 397 RAR \u00ae is a registered trademark of Alexander Roshal . 10036  \nWind River\u00ae is a registered trademark of Wind River Systems, Inc.  10037  \nSwift\u00ae and MacOS\u00ae are registered trademark s of Apple Corporation.  10038  \nLinux\u00ae is a registered trademark of Linus Torvalds.  10039  \nSTOP \u2122 is a trademark of BAE Systems.  10040  \nDebian \u00ae is a trademark of Software In The Public Interest Incorporated . 10041  \nUbuntu\u00ae is a registered trademark of Canonical Ltd.  10042  \nBSD \u00ae is a registered trademark of Verizon Business.  10043  \nUEFI\u00ae is a registered trademark of the UEFI Forum, Inc . 10044  \nAppArmor\u00ae is a registered trade mark of SUSE LLC.  10045  \nLibreOffice\u00ae is a registered trademark of The Document Foundation.  10046  \nKubernetes \u00ae is a registered trademark of The Linux Foundation . 10047  \nGoogle \u00ae is a registered trademark of Google LLC.  10048  \nGithub \u00ae is a registered trademark in the United States by GitHub, Inc.  10049  \nFacebook\u00ae is a regist", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}722{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "721", "chunk": "ered trademark of Facebook , Inc. 10050  \nNetBeans\u00ae  and Apache\u00ae are registered trademark s of the Apache Software Foundation . 10051  \nCommon Vulnerability Enumeration (CVE) \u00ae is a registered trademark of The MITRE 10052  \nCorporation . 10053  \nCommon Weakness Enumeration (CWE) \u2122 and C ommon Attack Pattern Enumeration and 10054  \nClassification  (CAPEC) \u2122 are trademarks of The MITRE Corporation.  10055  \nRust\u2122 is a trademark of the Mozilla Foundation.  10056  \nRISC -V\u00ae sis a registered trademark of RISC -V International . 10057UNCLASSIFIED//FOR OFFIC IAL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 344 of 397 29 Appendix A  \u2013 Abbreviations and Acronyms  10058  \nA&A \u2013 Assessment and Authorization  10059  \nADOC \u2013 Air Defense Operations Center  10060  \nADP \u2013 Acceptable Design Pattern  10061  \nAECA \u2013 Arms Export Control Act  10062  \nAO \u2013 Authorizing Official  10063  \nAOC  \u2013 Air Operations Center  10064  \nATC \u2013 Air Traffic Control  10065  \nATO \u2013 Authorization to Operate  10066  \nARP \u2013 Address Resolution Protocol  10067  \nASIC \u2013 Application -Specific Integrated Circuit  10068  \nBIOS \u2013 Basic Input/Output Syste m 10069  \nBMC3I \u2013 Battle Man", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}723{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "722", "chunk": "agement, Command, Control, Communications,  and Intelligence  10070  \nBMC \u2013 Baseboard Management Controller  10071  \nBPG \u2013 Best Practices Guides    10072  \nC2 \u2013 Command and Control  10073  \nC3R \u2013 CDS Configuration and Compliance Report  10074  \nC4ISR \u2013 Command, Control, Communica tions, Computers, Intelligence, Surveillance and 10075  \nReconnaissance  10076  \nCALD \u2013 Central Audit and Logging Daemon  10077  \nCAPEC \u2013 Common Attack Pattern Enumeration and Classification  10078  \nCCEVS \u2013 Common Criteria Evaluation and Validation Scheme  10079  \nCCOTS \u2013 Composed COTS CDS  10080  \nCCRI \u2013 Command Cyber Readiness Inspection  10081  \nCD \u2013 Compact Disc  10082  \nCDR \u2013 Content Disarm and Reconstruction  10083  \nCDRM \u2013 Cross Domain Risk Model  10084  \nCDS \u2013 Cross Domain Solutions  10085  \nCDSE \u2013 Cross Domain Support Element  10086  \nCDSO \u2013 Cross Domain Support Office  10087UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 345 of 397 CDTAB \u2013 Cross Domain Tech nical Advisory Board  10088  \nCI \u2013 Communications Interface  10089  \nCIC \u2013 Configuration Integrity Checker  10090  \nCIS \u2013 Center for Internet Security  10091  \nCISMOA ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}724{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "723", "chunk": "\u2013 Communication Interoperability and Security Memorandum of Agreement (CIS 10092  \nMOA)  10093  \nCJD \u2013 Central Journal Daemon  10094  \nCMS \u2013 CDS Manag ement Server  10095  \nCNA \u2013 Computer Network Attack  10096  \nCNE \u2013 Computer Network Exploit  10097  \nCNSS \u2013 Committee on National Security Systems  10098  \nCNSSI \u2013 Committee on National Security Systems Instruction  10099  \nCNSSP \u2013 Committee on National Security Systems Policy  10100  \nCOTS \u2013 Commercial Off -The-Shelf  10101  \nCPI \u2013 Critical Program Information  10102  \nCPICDS \u2013 Critical Program Information Protection CDS  10103  \nCPU \u2013 Central Processing Unit  10104  \nCSfC  \u2013 Commercial Solutions for Classified  10105  \nCVE \u2013 Common Vulnerabilities and Exposures  10106  \nCWE \u2013 Common Weakness Enumeration  10107  \nCYBERCOM  \u2013 United States Cyber Command  10108  \nDAC \u2013 Discretionary Access Control  10109  \nDAR \u2013 Defense Acquisition Requirements  10110  \nDAR \u2013 Data -at-Rest 10111  \nDCCDS \u2013 Data Center CDS  10112  \nDCCDS -CD \u2013 Data Center CDS Complex Document  10113  \nDCCDS -FF \u2013 Data Center CDS Fixed Format  10114  \nDCO \u2013 Defensive Cyberspace Operations  10115  \nDFDL \u2013 Data Format Description Language  10116  \nDISA \u2013 Defense Information Systems Agency  10117UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, K", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}725{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "724", "chunk": "OR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 346 of 397 DIT \u2013 Data -in-Transit  10118  \nDLP \u2013 Data Loss Prevention  10119  \nDoD I \u2013 Department of Defense Instruction  10120  \nDoS \u2013 Denial  of Service  10121  \nDR \u2013 Domain Router  10122  \nDTLS \u2013 Datagram Transport Layer Security  10123  \nDTD \u2013 Document Type Definitions  10124  \nDVD \u2013 Digital Versatile  Disc 10125  \nECDSP \u2013 Enterprise Cross Domain Service Provider  10126  \nEEUM \u2013 Enhanced End Use Monitoring  10127  \nFDE \u2013 Full Disk Encryption  10128  \nFIFO \u2013 First In, First Out  10129  \nFIPS \u2013 Federal Information Processing Standards  10130  \nFOE \u2013 Filter Orchestration Engine  10131  \nFPGA \u2013 Field Programmable Gate Array  10132  \nFRV \u2013 Filter Report Validator  10133  \nFSP \u2013 Filter Sidecar Protocol  10134  \nGCC \u2013 GNU C Compiler  10135  \nGMAC \u2013 Galois Message Authentication Co de 10136  \nGOTS \u2013 Government Off -The-Shelf  10137  \nGPCPU \u2013 General Purpose Central Processing Uni t 10138  \nGRMP \u2013 Guard Remote Management Protocol  10139  \nGSOMIA \u2013 General Security of Military Information Agreement  10140  \nGUI \u2013 Graphic User Interface  10141  \nHB \u2013 Hardware Based  10142  \nHMAC \u2013 Hash -based Message Authentication Code  10143  \nHTN \u2013 High Thr", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}726{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "725", "chunk": "eat Network  10144  \nHTTP \u2013 HyperText Transport Protocol  10145  \nHTTPS \u2013 HyperText Transport Protocol Secure  10146  \nIASRD \u2013 Information Assurance Security Requirements Document  10147UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 347 of 397 IAVA \u2013 Information Assurance Vulnerability Alerts  10148  \nIC \u2013 Intelligence Community  10149  \nID \u2013 Identifier  10150  \nIDRAC \u2013 Integrated Dell Remote Access  10151  \nIETF \u2013 Internet Engineering Task Force  10152  \nILO \u2013 Integrated Lights -Out 10153  \nINFOSEC \u2013 Information Security  10154  \nIPC \u2013 Inter -Process Communications  10155  \nIPMI \u2013 Intelligent Platform Management Interface  10156  \nIPSEC  \u2013 Internet Protocol Security  10157  \nIRT \u2013 Incident Response Teams  10158  \nISG \u2013 Inspection and Sanitization Guidance  10159  \nITAR \u2013 International Traffic in Arms Regulations  10160  \nIV&V \u2013 Independent Verification and Validation  10161  \nISM.XML \u2013 Information Security Marking Metadata  Data Encoding Specification  10162  \nISMCAT.XML \u2013 Information Security Marking Country Codes and Tetragraphs  XML  10163  \nJAF \u2013 JALoP Audit Format  10164  \nJAL \u2013 Journal(ing), Audit(in", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}727{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "726", "chunk": "g), and Log(ging)  10165  \nJALoP \u2013 Journaling, Auditing, and Logging Protocol  10166  \nJDK \u2013 Java Development Kit  10167  \nJRE \u2013 Java Runtime Environment  10168  \nJREAP \u2013 Joint Range Extension Applications Protocol  10169  \nJS \u2013 Job Scheduler  10170  \nJSON \u2013 JavaScript Object Notation  10171  \nLAN \u2013 Local Area Network  10172  \nLBSA \u2013 Lab-Based Securi ty Assessment  10173  \nLDAP \u2013 Lightweight Directory Access Protocol  10174  \nLDIF \u2013 LDAP Data Interchange Format  10175  \nLOA \u2013 Letter of Offer and Acceptance  10176  \nLTS \u2013 Long -Term Support  10177UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 348 of 397 LVM \u2013 Language Virtual Machine  10178  \nMAC \u2013 Mandatory Access Control  10179  \nMACSEC \u2013 Media Access Control Securit y 10180  \nMACP \u2013 Mobile Access Capability Package  10181  \nMCS \u2013 Multiple Category Security  10182  \nMDA \u2013 Missile Defense Agency  10183  \nMDFG \u2013 Mission Data Format Guide  10184  \nMESG \u2013 Mission Environment Specification Guide  10185  \nMFA \u2013 Multi -Factor Authentication  10186  \nMIL-DTL \u2013 Military Detail Specificati on 10187  \nMIL-STD \u2013 U.S. Government Military Standard  10188  \nMIME \u2013 Multip", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}728{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "727", "chunk": "urpose Internet Mail Extensions  10189  \nML \u2013 Multi -Level  10190  \nMLS \u2013 Multi -Level Security  10191  \nMLDB \u2013 Multi -Level Database  10192  \nNDP \u2013 National Disclosure Policy  10193  \nNIAP \u2013 National Information Assurance Partnership  10194  \nNIPRNet  \u2013 Non-Classified Internet Protocol Router Network  10195  \nNIST \u2013 National Institute of Standards and Technology  10196  \nNSA \u2013 National Security Agency  10197  \nNCDSMO \u2013 National  Cross Domain Strategy and  Management Office  10198  \nNSS \u2013 National Security Systems  10199  \nNTP \u2013 Network Time Protocol  10200  \nOWT \u2013 One Way Transfer  10201  \nPA \u2013 Protocol Adapter  10202  \nPCRE \u2013 Perl Compatible Regular Expressions  10203  \nPEFA \u2013 Policy Enforcement Failure Analysis  10204  \nPFD \u2013 Protocol Filtering Diode  10205  \nPKI \u2013 Public Key Infrastructure  10206  \nPOLK \u2013 Principle of Least Knowledge  10207UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 349 of 397 POLF  \u2013 Principle of Least Functionality  10208  \nPOLP \u2013 Principle of Least Privilege  10209  \nPOSIX\u00ae  \u2013 Portable Operating System Interface for UNIX\u00ae  (POSIX\u00ae ) 10210  \nPTP \u2013 Precision Time Protocol  10211  \nR", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}729{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "728", "chunk": "AID \u2013 Redundant Array of Independent Disks  10212  \nRAIN \u2013 Redundant, Always Invoked, Independent,  and Non -Bypassable  10213  \nRBAC \u2013 Role Based Access Control  10214  \nRDAC \u2013 Risk Decision Authority Criteria  10215  \nRFC \u2013 Request for Comment  10216  \nRHR \u2013 Reliable Human Review  10217  \nRMF \u2013 Risk Management Framework  10218  \nRP \u2013 Results Processor  10219  \nRTB \u2013 Raise The Bar  10220  \nSAN \u2013 Storage Area Network  10221  \nSAO \u2013 Security Assessment Outbrief  10222  \nSBSA \u2013 Site-Based Security Assessment  10223  \nSCAP \u2013 Security Content Automation Protocol  10224  \nSCD \u2013 Simple CDS Diode  10225  \nSCRM \u2013 Supply Chain Risk Management   10226  \nSDK \u2013 Software Development Kit  10227  \nSDL \u2013 Security Development Lifecycle  10228  \nSDR \u2013 Security Design Review  10229  \nSDS \u2013 Simple Diode Solution  10230  \nSECCOMP \u2013 Secure Computing Mode  10231  \nSECCOMP -BPF \u2013 Secure Computing Mode Berk eley Packet Filter  10232  \nSETUID \u2013 Set User ID  10233  \nSFTP \u2013 Secure File Transport Protocol  10234  \nSFTF \u2013 Suspect File Transmission Format  10235  \nSHA \u2013 Secure Hash Algorithm  10236  \nSIC \u2013 System Integrity Checker  10237UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}730{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "729", "chunk": "ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 350 of 397 SIPRNet  \u2013 Secure Internet Protocol Router Network  10238  \nSNMP \u2013 Simple Network Management Protocol  10239  \nSoC \u2013 System -on-a-Chip  10240  \nSP \u2013 Special Publication  10241  \nSRD \u2013 System Requirements Document  10242  \nSSRD \u2013 System Security Requi rements Document  10243  \nSSH \u2013 Secure Shell  10244  \nSTANAG \u2013 NATO Standardization Agreement  10245  \nSTIG \u2013 Security Technical Implementation Guide  10246  \nSTPR \u2013 Security Test ing Preparation Review  10247  \nSWaPC \u2013 Space, Weight, Power, and Cooling  10248  \nSYSLOG \u2013 System Logger  10249  \nTADIL \u2013 Tactical Digita l Information Link  10250  \nT&W \u2013 Threats and Weaknesses  10251  \nTCDS \u2013 Tactical CDS  10252  \nTCP \u2013 Transmission Control Protocol  10253  \nTDL \u2013 Tactical Data Link  10254  \nTHA \u2013 Traditional with Hardware Assist  10255  \nTKPC \u2013 Two Knowledgeable Person Control  10256  \nTLS \u2013 Transport Layer Security  10257  \nTPM \u2013 Trusted Platform Module  10258  \nTRR \u2013 Test Readiness Review  10259  \nTSB \u2013 Traditional Software Based  10260  \nTUI \u2013 Text-based User Interface  10261  \nUCDSMO  \u2013 Unified Cross Domain Services Management Office  10262  \nUCL \u2013 NCDSMO  Control List  10263  \nUDP \u2013 User Datagr am Protocol  10264  \nUDP \u2013 Unacceptable Design Pattern  10265  \nUEFI \u2013 Unified Ex", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}731{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "730", "chunk": "tensible Firmware Interface  10266  \nUSB \u2013 Universal Serial Bus  10267UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \n \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 351 of 397 USG \u2013 United States Government  10268  \nUSMTF \u2013 United States Message Text Format  10269  \nVDI \u2013 Virtual Desktop Infrastructure  10270  \nVLAN \u2013 Virtual Local Area Ne twork  10271  \nVM \u2013 Virtual Machine  10272  \nVMF \u2013 Variable Message Format  10273  \nVRF \u2013 Virtual Routing and Forwarding  10274  \nVXLAN \u2013 Virtual Extensible L ocal Area Network  10275  \nVOIP \u2013 Voice Over Internet Protocol  10276  \nW3C \u2013 World Wide Web Consortium  10277  \nXML \u2013 Extensible Markup Language  10278  \nXPath \u2013 XML Path Language  10279  \nXSD \u2013 XML Schema Definition  10280  \nXSLT \u2013 XML Stylesheet Transformation  10281UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 352 of 397 \n 30 Appendix B \u2013 Encryption & Digital Signature Standards  \nThe latest version of the CSfC  capability packages for DIT and DAR should be review ed before \nimplementing", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}732{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "731", "chunk": " DIT and DAR in a CDS to ensure the implementation complies with the latest \nguidance.  \nCSfC  capability packages can be found at:  \nhttps://www.nsa.gov/Resources/Commercial -Solutions -for-Classified -Program  \n \nTable 4 - Approved Algorithms for IPSEC   \nSecurity Service  Algorithm Suite  Specifications  \nConfidentiality (Encryption)  AES -256 FIPS PUB 197  \nIETF RFC 6239  \nIETF RFC 6379  \nIETF RFC 6380  \nIETF RFC 6460  \nAuthentication (Digital Signature)  RSA 3072  \nor, \nECDSA over the curve P -384 with \nSHA -384 FIPS PUB 186 -4 \nIETF RFC 6239  \nIETF RFC 6380  \nIETF RFC 6460  \nKey Exchange/Establishment  ECDH over the curve P -384 (DH Group \n20) \nor, \nDiffie -Hellman 3072  NIST SP 800 -56A \nIETF RFC 6239  \nIETF RFC 6379  \nIETF RFC 6380  \nIETF RFC 6460  \nIntegrity (Hashing)  SHA -384 FIPS PUB 180 -4 \nIETF RFC 6239  \nIETF RFC 6379  \nIETF RFC 6380  \nIETF RFC 6460  \n \nTable 5 - Approved Algorithms for TLS  \nSecurity \nService  TLS Cipher Suites  Specifications  \nTLS Cipher \nSuite  TLS_DHE_RSA_WITH_AES_256_GCM_SHA384  \nor \nTLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384  \nor \nTLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384  FIPS PUB 180 -4 \nFIPS PUB 186 -3 \nFIPS PUB 197  \nFIPS 800 -56A \nIETF RFC 6460  \nIETF RFC 5246  \nIETF RFC 4492UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}733{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "732", "chunk": ", JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 353 of 397 \n Security \nService  TLS Cipher Suites  Specifications  \nAuthentication \n(Digital \nSignature)  RSA 3072  \nOr \nECDSA over the curve P -384 with SHA -384  \nKey Exchange  ECDHE over the curve P -384 (DH Group 20)  \nOr \nDiffie -Hellman 3072   \n \nTable 6 - Approved Algorithms for SRTP  \nSecurity \nService  TLS Cipher Suites  Specifications  \nConfidentiality \n(Encryption)  AES -256 in Counter Mode (CM)  IETF RFC 3711  \nIETF RFC 2675  \nAuthentication \n(Digital \nSignature)  RSA 3072  \nOr \nECDSA over the curve P -384 with SHA -384 IETF RFC 3711  \nIETF RFC 2104  \nKey Exchange  TLS-SDES or DTLS  IETF RFC 4568  \nIETF RFC 6347  \n \nTable 7 - Approved Algorithms for D ata-At-Rest \nSecurity \nService  TLS Cipher Suites  Specifications  \nConfidentiality \n(Encryption)  AES -256 FIPS PUB 197  \nAuthentication \n(Digital \nSignature)  Elliptic Curve Digital Signature Algorithm \n(ECDSA) over the curve P -384 with SHA -384 FIPS PUB 186 -4 \nRSA 3072 (Minimum)  FIPS PUB 186 -4 \nIntegrity \n(Hashing)  SHA -384 FIPS PUB 180 -4 \n \nTable 8 - Approved Algorithms for SSH/SFTP/SCP  \nSecurity \nService  TLS Cipher Suites  Specifications  \nConfidentiality \n(E", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}734{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "733", "chunk": "ncryption)  AES256 -GCM  IETF RFC 5647  \nFIPS PUB 197  \nIETF RFC 6239UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 354 of 397 \n Security \nService  TLS Cipher Suites  Specifications  \nIETF RFC 4253  \nAuthentication \n(Digital \nSignature)  RSA 3072  \nOr \nECDSA over the curve P -384 with SHA -384 IETF RFC 6239  \nIETF RFC 4253  \nIETF RFC 5656  \nKey Exchange   ECDH -SHA2 -P384  IETF RFC 6239  \nIETF RFC 5656  \nIETF RFC 8268  \nIETF RFC 4253  \nMessage \nAuthentication \nCode  HMAC -SHA -384 \nHMAC -SHA2 -512 IETF RFC 6239  \nIETF RFC 6668  \nIETF RFC 8332  \nIETF RFC 4253UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 355 of 397 \n 31 Appendix C \u2013 RTB Requirements Mapping for Access CDS  \nThe below table provides the typical RTB requirements section mapping for Access CDS  \n(specifically ADP -7: Virtual  Machine Based Access  CDS) . Since each CDS is different, \ndevelopers should verify the applicability of other sections for their CDS.  \nTR RMANR  \nPMR ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}735{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "734", "chunk": " RMONR  \nNCR  PAR - maybe  \nNRR  TPR \nSCR  SC \nGAR  DCOR  \nC2R - maybe  MPCR - maybe  \nOSSR  SK \nSASR  MLS  \nDPMR  THA -P \nSIHCR  HWCR \nPIR VTR  \nRBACR  LBSAR  \nEDSR  SBSAR  \nSIR MLSWNR  \nVIRT  ACDSR  \nJALSRUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 356 of 397 \n 32 Appendix D \u2013 RTB Requirements Mapping for HCFD, PFD, \nand Hardware CDS  \nThe below table provides the typical RTB requirements section mapping for Protocol Filtering \nDiodes, Hardware Content Filter Devices, and Hardware  CDS.  Due to unique  nature of hardware \nbased systems not all requirements in these sections apply.  Since each system  is different, \ndevelopers should verify the applicability of other sections for their CDS.  \nRTB  \nRequirements  PFD  HCFD  HW \nCDS  RTB  \nRequirements  PFD  HCFD  HW \nCDS  \nTR Y Y Y RMONR  N Y Y \nPMR  Y Y Y MLSWNR  Y Y Y \nNCR  Y Y Y CMSR  Y Y Y \nNRR  Y Y Y HWCR  Y Y Y \nSCR  Y Y Y EDSR  Y Y Y \nGAR  Y Y Y     \nC2R N Y Y     \nDPMR  Y Y Y     \nJALSR  N Y Y     \nTPR Y Y Y     \nSC Y Y Y     \nGDFR  N Y Y     \nMMFFR  N Y YUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SA", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}736{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "735", "chunk": "U, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 357 of 397 \n  \n33 Appendix E \u2013 CDS Audit Events  \nThis section has been moved into separate NCDSMO documen t Required Audit Events for Cross \nDomain Solutions , v1.0, NCDSMO Doc ID : NCDSMO -R-00019 -001_00 . \n34 Appendix F \u2013 RTB Specific Threats  \nID Description  RTB Requirements  \nTRTB -00001  Migration of attack into new process  MPCR -16;OSSR -36 \nTRTB -00002  Network interface used by unauthorized \nprocess  MPCR -22.1;OSSR -20.1;OSSR -36.1;OSSR -\n36.2;OSSR -40.1;PIR -10.2;SASR -6.6;VIRT -\n27 \nTRTB -00003  Change namespace assignment  OSSR -36.3 \nTRTB -00004  Process migration: An adversary leverages \nestablished control of a process to gain control \nof another process.  C2R-8;JALSR -30.2;JALSR -32;JALSR -\n5;JSR -4;RPR -9 \nTRTB -00005  Pipeline Bypass Due to Other Pipeline Process' \nFiles or Directories Being Readable  MPCR -3;MPCR -4;OSSR -4.2;OSSR -4.6 \nTRTB -00006  Leaking of Pipeline Process Critical Files  MPCR -25;MPCR -25.1;MPCR -3;MPCR -\n4;OSSR -4.2;OSSR -4.6 \nTRTB -00007  Abuse of Unnecessary Applications & Libraries  OSSR -6 \nTRTB -00008  Brute Force Address Space Layout \nRandomization (ASLR) Attack  OSSR -10.2;OSSR -12 \nTRTB -00009  Exploit", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}737{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "736", "chunk": "ation for Execution: overwrite global \noffset table using buffer overflow / stack \nsmashing  OSSR -14 \nTRTB -00010  Exploitation for Execution: Return -Oriented \nProgramming (ROP) attacks to application  OSSR -15UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 358 of 397 \n ID Description  RTB Requirements  \nTRTB -00011  Exploitation for Execution: Return -Oriented \nProgramming (ROP) attacks to kernel \nprograms.  OSSR -15.1 \nTRTB -00012  Circumventing the one -way transfer \nmechanism with backchannel  GAR -2;OSSR -20.2;OSSR -20.3;OSSR -\n40.2;OSSR -40.3;SIHCR -3.3.3;VIRT -25 \nTRTB -00014  Obscure user identity by running support tools \nas root or a system user account.  GAR -5.5;OSSR -2.1;SASR -1;SASR -2;SASR -\n3;SIR -14 \nTRTB -00015  Incorrect system time or clock drift leads to \ninaccurate audit / log timestamps.  MPCR -15;OSSR -20;OSSR -40 \nTRTB -00016  Circumvention of one -way IPC with \nbackchannel: Abuse of mq_notify SYSCALL  OSSR -27.1 \nTRTB -00017  Abuse of Unnecessary Kernel Modules and \nDevice Drivers  OSSR -25.1 \nTRTB -00018  Installation of Unauthorized / Malicious Kernel \nModule.  OSSR -25.3 \nTRTB -0", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}738{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "737", "chunk": "0019  Inadvertent deployment of software and/or \nconfiguration to the wrong system  SASR -5.8.1  \nTRTB -00020  Circumvention of one -way IPC with \nbackchannel: UDP/IP sender can receive data, \nreceiver can send data  OSSR -27.2 \nTRTB -00021  Exploiting bi -directional transfer ability of \ninter -process communication mechanism  C2R-8;GDFR -11;JALSR -30.2;JALSR -5;JSR -\n4;MPCR -20;MPCR -7.1;MPCR -9;RPR -9 \nTRTB -00023  Hijacking high integrity level process  GAR -3.2;MLS -11.1;MLS -11.2;MLS -\n11.3;MLS -3 \nTRTB -00024  Exploiting application allowlisting capability \nmechanism  GAR -5.3;RBACR -7.15 \nTRTB -00025  System exploits of missing process, network \nand device monitoring system.  GAR -5.5;SIR -14 \nTRTB -00027  Legitimate alarms missed due to false alarms  GAR -6UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 359 of 397 \n ID Description  RTB Requirements  \nTRTB -00029  Perform exploit circumventing security policy \nenforcement  C2R-2;DPMR -19;FRVR -1;FRVR -12;FRVR -\n9;FRVR -9.1;GAR -1.1;GAR -1.4;GDFR -\n30.1;GDFR -43;RBACR -7.2;RPR -12 \nTRTB -00030  Kernel based IP forwarding used to bridge one \nor more inte", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}739{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "738", "chunk": "rfaces  OSSR -34 \nTRTB -00032  Time manipulation attacks such as altering log \ntimestamping, circumvention of time -based \naccess controls, certificate problems, etc.  OSSR -20.1;OSSR -40.1 \nTRTB -00033  Non -malicious user impacts system availability  OSSR -16.1;RBACR -10;SIHCR -13;VIRT -\n8;VIRT -8.1 \nTRTB -00034  Network Exploit of Service/Process That is \nExposed Unnecessarily.  DPMR -8.2;GAR -5.4;MPCR -22;MPCR -\n22.1;OSSR -18.1;OSSR -19;OSSR -\n36.1;OSSR -36.2;OSSR -36.4;PAR -3;PAR -\n4;PIR -10.2;SASR -6.6;SIR -12 \nTRTB -00035  Network exploits of unnecessary services  OSSR -10.2;OSSR -12;OSSR -18 \nTRTB -00036  Operating With Protection Mechanism \nDisabled  SASR -11.4.1  \nTRTB -00037  Unattributable Security Critical Action \nPerformed  DPMR -12.14;FRVR -11;GAR -5.5;GDFR -\n3;GDFR -32.1;GDFR -34;GDFR -35;GDFR -\n35.1;GDFR -4;GDFR -44;GDFR -5;GDFR -\n6;GDFR -6.1;GDFR -6.2;GDFR -\n6.6.1;GDFR -6.6.3;GDFR -6.6.4;GDFR -\n6.6.5;GDFR -6.6.6;GDFR -6.6.7;GDFR -\n6.6.8;GDFR -6.6.9;GDFR -6.7;JALSR -\n10;JALSR -11;JALSR -13;JALSR -18;JALSR -\n20;JALSR -21;JALSR -22;JALSR -23;JALSR -\n27;JALSR -30;JALSR -36;JALSR -37;JALSR -\n38;JALSR -4;JALSR -4.1;JALSR -6;MPCR -\n32;MPCR -34;OSSR -23.4;OSSR -\n31.2;OSSR -39;OSSR -8.5;PIR -1;RBACR -\n12;RPR -8;SASR -1;SASR -11.7;SASR -\n11.8;SASR -11.9;SASR -2;SASR -\n5.1", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}740{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "739", "chunk": "2;SASR -5.5;SASR -6.4;SASR -7.2;SASR -UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 360 of 397 \n ID Description  RTB Requirements  \n7.2.1;SASR -7.9;SIHCR -17.2;SIHCR -\n17.3;SIR -14;SIR -15.3;VIRT -18.2;VIRT -\n18.3;VIRT -29;VIRT -4.3 \nTRTB -00038  System resources reallocated while in use  OSSR -16;OSSR -16.1;SIHCR -13 \nTRTB -00039  Booting of Unauthorized Operating System  SIR-1.3;SIR -1.4;VIRT -1;VIRT -26 \nTRTB -00040  Exploiting Incorrectly Configured Security \nProtections  DPMR -12.7;DPMR -12.7.1;GDFR -\n47;SIHCR -14;SIHCR -17.2;SIR -3.3.1;SIR -\n3.3.3;VIRT -18.2;VIRT -8;VIRT -8.1 \nTRTB -00041  Scanning for Vulnerable Hardware  SIR-3.3;SIR -3.4 \nTRTB -00042  Unauthorized Party Accesses Sensitive \nInformation  DPMR -12.7;DPMR -12.7.1;DRR -1;GAR -\n9;GAR -9.2;GDFR -24;GDFR -24.4;GDFR -\n24.5;GDFR -38.3;GDFR -38.4.1;GDFR -\n38.4.2;GDFR -38.4.3;GDFR -38.4.4;PAR -\n2;PAR -6;RBACR -7.8 \nTRTB -00043  Unattributable Network Access  OSSR -39 \nTRTB -00044  Acquisition of New Privileges via execve()  PIR-10.4 \nTRTB -00045  Abuse of Mounts to Overwrite Filesystem \nContent  PIR-10.9 \nTRTB -00046  Resource Starvation via Abu", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}741{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "740", "chunk": "se of Control \nGroups Controls  PIR-10.10  \nTRTB -00047  Exploit CDS interaction with untrusted \nenvironments or transfer data while on -access \nintegrity checks for application allowlisting \ndisabled.  SIR-10 \nTRTB -00048  Attacker submits non -compliant content \nthrough the CDS.  DPMR -1;GDFR -15;GDFR -16;SIR -15.3 \nTRTB -00049  Exploiting Unapproved Hardware and/or \nKernel Drivers  SIHCR -15;VIRT -9UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 361 of 397 \n ID Description  RTB Requirements  \nTRTB -00050  Exploiting Incorrect or Inconsistent System \nConfiguration  DPMR -12.7;DPMR -12.7.1;MPCR -\n2;SIHCR -1;SIHCR -2;VIRT -17 \nTRTB -00051  Exploitation of out -of-date packages with \nmissing security patches  DPMR -1;SIHCR -5.2 \nTRTB -00052  System unavailability due to the complex \nconfiguration process  SIHCR -1 \nTRTB -00053  Theft of system software and/or design  DPMR -11;DPMR -12;DPMR -12.1;DPMR -\n12.12;DPMR -12.2;DPMR -12.3;DPMR -\n12.4;DPMR -12.8;DPMR -12.9 \nTRTB -00055  Exploitation with Reused Exploit  DPMR -19;FRVR -1;FRVR -9;GAR -\n1.1;GDFR -30.1;GDFR -30.2;GDFR -\n30.3;GDFR -43 \nTRTB -00056  System ava", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}742{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "741", "chunk": "ilability impact  RBACR -7.3 \nTRTB -00057  Combined roles or privileges granted to a \nsingle administrator enable bypass of TKPC in \nsecurity -critical operations.  RBACR -7.7 \nTRTB -00058  Introduction of Unapproved Communication \nChannel  RBACR -7.3 \nTRTB -00059  Usability impact due to lack of reporting to \nuser RBACR -7.11 \nTRTB -00060  Incorrectly configured filter reports (e.g. \nredaction) exploited as an exfiltration channel  RBACR -7.11 \nTRTB -00061  Content transits the CDS that does not \nconform to policy.  DRR -3;DRR -5;FRVR -10;FRVR -12;FRVR -\n6;GDFR -1;GDFR -13;GDFR -39;GDFR -\n42;GDFR -6.1;GDFR -6.2;GDFR -9;MLS -\n10;MLS -4;MLS -5;MLS -5.1;MLS -6;MLS -\n7;RPR -12;RPR -3;RPR -5;RPR -6;RPR -8 \nTRTB -00063  Attacker submits content including sensitive \ninformation.  GDFR -29UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 362 of 397 \n ID Description  RTB Requirements  \nTRTB -00064  Attacker Causes a CDS Process to Crash or \nEnter a Non -Recoverable State  GDFR -19;GDFR -19.1;GDFR -19.2;GDFR -\n19.3;GDFR -19.4;GDFR -19.5;GDFR -\n21;GDFR -21.1;GDFR -21.2;GDFR -\n22;MPCR -14 \nTRTB -00065  Filter Bypass  DRR -", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}743{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "742", "chunk": "2;FRVR -2;FRVR -3;FRVR -4;FRVR -\n5;GDFR -11;GDFR -12;GDFR -13;GDFR -\n17;GDFR -31;GDFR -36;GDFR -42;GDFR -\n46;GDFR -46.1;JSR -3;MLS -5.1;MPCR -\n20;MPCR -25;MPCR -25.1;RPR -2;VIRT -25 \nTRTB -00067  Known or suspected malicious content transits \ndataflow in active state.  GDFR -14.1;GDFR -18 \nTRTB -00068  Transiting data using a dataflow policy that \nhas not been explicitly activated by \nadministrator(s).  GDFR -37 \nTRTB -00069  Exploiting Incomplete or Inconsistent Software \nInstallation  MPCR -2.1 \nTRTB -00070  Installation of Malicious System BIOS/UEFI \nFirmware  VIRT -2 \nTRTB -00071  Hindrance of Forensic Analysis  JALSR -10;JALSR -13;JALSR -18;JALSR -\n6;VIRT -4.3 \nTRTB -00074  Hijacking a privileged VM  VIRT -23 \nTRTB -00077  Data Leak of Information Into Different \nSecurity Domain  FRVR -9.1;JALSR -10;MLS -11.1;MLS -\n11.2;MLS -11.3;MLS -3;MLS -4;MLS -\n5;VIRT -11;VIRT -11.1;VIRT -11.3;VIRT -\n11.3.1;VIRT -11.5;VIRT -12.1;VIRT -\n12.2;VIRT -12.4;VIRT -19.2;VIRT -\n20.1;VIRT -22;VIRT -24;VIRT -30 \nTRTB -00078  Transmission of Expired Data  VIRT -16 \nTRTB -00081  Known or suspected malicious content stored \nor transferred to other processes in an active \nstate.  JALSR -30.3UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCL", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}744{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "743", "chunk": "ASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 363 of 397 \n ID Description  RTB Requirements  \nTRTB -00082  Misuse of Privilege by Insider  CMSR -11 \n \n35 Appendix G \u2013 RTB Specific Weakness es \nWeakness ID  Description  RTB Requirements  \nWRTB -00001  Improper Integrity Compartmentalization: \nConnecting Data Paths With Different \nIntegrity Levels  GAR -3.2;MLS -11.1;MLS -11.2;MLS -\n11.3;MLS -3;OSSR -20.1;OSSR -40.1;VIRT -4.1 \nWRTB -00002  Dynamic or Interpreted Program with \nPrivilege  OSSR -2.3;OSSR -2.4;OSSR -8.1 \nWRTB -00003  Execution with root Privileges instead of \nLeast Privilege Capabilities  OSSR -2.5 \nWRTB -00004  Missing necessary system information to an \nauthorized actor  OSSR -16 \nWRTB -00005  Installed applications or libraries that are not \nneeded to operate and protect the CDS  MPCR -25.2;MPCR -26;OSSR -6 \nWRTB -00006  Excessive Attack Surface related to network \nservices  OSSR -10.2;OSSR -12;OSSR -18 \nWRTB -00007  Execution with access to unnecessary system \ncalls MPCR -21;OSSR -23;OSSR -23.1;OSSR -23.5 \nWRTB -00008  Installed kernel modules and device drivers \nthat are not needed to operate and protect \nthe CDS system  OSSR -25.1 \nWRTB -00009  Global offset table is writable  OSSR -14 \nWRTB -00010  R", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}745{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "744", "chunk": "e-use of Public Key Between Unrelated \nSystems  SASR -5.8.1  \nWRTB -00011  Improper handling of allowed application  GAR -5.3 \nWRTB -00012  Missing monitoring system to detect \nrenegade processes  GAR -5.5;SIR -14 \nWRTB -00013  False alarms (as classified by original \ndevelopers) present in log  GAR -6 \nWRTB -00014  Backchannel for process endpoints \nconnected by one -way transfer mechanism  GAR -2;OSSR -20.2;OSSR -20.3;OSSR -\n27.2;OSSR -40.2;OSSR -40.3;SIHCR -3.3.3  \nWRTB -00015  Security -relevant components are not \ninvoked during system operation  C2R-11;GAR -1.2 \nWRTB -00016  Providing time from lower -privileged time \nsource to higher -privileged processes  OSSR -20.1;OSSR -40.1UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 364 of 397 \n Weakness ID  Description  RTB Requirements  \nWRTB -00017  Backchannel for POSIX message queues \nmechanism because mq_notify SYSCALL is \nnot restricted  OSSR -27.1 \nWRTB -00018  Incomplete List of Disallowed kernel modules  OSSR -25.3 \nWRTB -00019  LSM -based MAC system provides insufficient \ngranularity of access control  OSSR -22.1 \nWRTB -00020  Failure to Achieve Fault", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}746{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "745", "chunk": " Tolerance due to \nInsufficient Redundancy  DPMR -19;FRVR -1;FRVR -12;FRVR -9;FRVR -\n9.1;GAR -1.1;GAR -1.4;GAR -3;GAR -\n5.3;GDFR -30.1;GDFR -43;MPCR -9;RPR -\n12;SIR -11;SIR -11.1 \nWRTB -00021  Exposure of the internal state of a process \nwith tracing abilities  OSSR -26 \nWRTB -00022  Using Components with Known \nVulnerabilit ies DPMR -10;DPMR -15;MPCR -35;MPCR -\n35.1;MPCR -36;OSSR -10.3.1;OSSR -25;OSSR -\n32;OSSR -32.3.1;OSSR -32.5.1;OSSR -\n32.6;SIHCR -14;SIR -3;SIR -3.3;SIR -3.4 \nWRTB -00023  Improper access to load kernel modules after \nsystem boot  OSSR -25.2 \nWRTB -00024  Missing or disabled MAC enforcement  OSSR -31;OSSR -31.1;SASR -6.5;SASR -7.3 \nWRTB -00025  Network Exposure  C2R-1;DPMR -8.2;GAR -3;GAR -3.1;MPCR -\n22;MPCR -22.1;OSSR -18.1;OSSR -36.1;OSSR -\n36.2;OSSR -36.4;SASR -1;SIHCR -3.3.1;SIHCR -\n3.3.2;SIHCR -3.3.3;VIRT -4.4 \nWRTB -00026  Insufficient logging of MAC enforcement \nchanges  OSSR -31.2 \nWRTB -00027  IP forwarding is enabled in the OS Kernel  OSSR -34 \nWRTB -00028  Exploitation for Execution: Inserting and \nrunning code from data storage memory  OSSR -13 \nWRTB -00029  Protection Mechanism Failure by Firewall  GAR -5.4;OSSR -19;OSSR -36.4;SIR -12 \nWRTB -00030  Insufficient redundancy in points of failure: \nFailure to neutralize data originating from \nhigh -th", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}747{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "746", "chunk": "reat source  C2R-2 \nWRTB -00031  Insufficient protection of data -flow \nenforcement  C2R-11;FRVR -2;FRVR -3;GAR -1.2;MLS -10 \nWRTB -00032  Incorrect system time  MPCR -15;OSSR -20;OSSR -40 \nWRTB -00033  Lack of sufficient address space to implement \naddress space layout randomization  OSSR -10.2;OSSR -12 \nWRTB -00034  Process endpoints connected by \nunconstrained transfer mechanism that \nallows bi -directional communication  C2R-8;GDFR -11;JALSR -30.2;JALSR -5;JSR -\n4;RPR -9UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 365 of 397 \n Weakness ID  Description  RTB Requirements  \nWRTB -00035  Acceptance of lower integrity level input data  GAR -3.1;MLS -11.1;MLS -11.2;MLS -11.3 \nWRTB -00036  Execution with unnecessarily elevated \nintegrity control level  GAR -3.2 \nWRTB -00037  Least privilege violation: Write access to \nbinaries  OSSR -4.3;OSSR -4.7 \nWRTB -00038  Least privilege violation: Write access to \nconfiguration  OSSR -4.4;OSSR -4.7;RBACR -7.2;RBACR -7.9 \nWRTB -00039  Least privilege violation: Access to files of \nother pipeline processes  OSSR -4.2;OSSR -4.6 \nWRTB -00040  Insufficient Validation Frequen", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}748{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "747", "chunk": "cy -- Possible \nUndetected Hostile Activity between \nValidations  SIR-10.3;SIR -15.1;SIR -3.3.1;SIR -3.3.3  \nWRTB -00041  Insufficient Detection of Integrity Violation  GDFR -36;JALSR -7.1;MPCR -23;SIR -10.1;SIR -\n10.2;SIR -10.6;SIR -10.7;SIR -10.9;SIR -3.3.4  \nWRTB -00042  Reliance on Third Party Tool that does not \nprovide regular updates to software and data \ndefinitions  SIHCR -14;SIR -3.4 \nWRTB -00043  Execution with Unnecessary Network \nInterface Access  PAR-3;PAR -4;PIR -10.2;SASR -6.6 \nWRTB -00044  Improper Privilege Management: Memory \nMappings Both Writable and Executable  PIR-10.8 \nWRTB -00045  Improper Privilege Management: Access to \nPhysical Device  PIR-10.3 \nWRTB -00046  Improper Privilege Management: Exposure of \nControl Groups Settings  PIR-10.10  \nWRTB -00047  Improper Privilege Management: Exposure of \nKernel Tunables  PIR-10.7 \nWRTB -00048  CDS continues to interact with untrusted \nenvironments or transfer data while on -\naccess integrity checks for application \nallowlisting disabled.  SIR-10 \nWRTB -00049  Destruction of digital artifact(s) that are part \nof a security incident.   SIR-15.3 \nWRTB -00050  Failure to establish root of trust for secure \nchain of custody  SIHCR -3.1;SIHCR -3.2.3;SIHCR -3.3;VIRT -26 \nWRTB -00051  Accepting network -based installatio", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}749{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "748", "chunk": "n image \nfrom untrusted source  CMSR -3.1;CMSR -3.2;SIHCR -3.3.1;SIHCR -\n3.3.2;SIHCR -3.3.3  \nWRTB -00052  Optional feature can be enabled when not \ninstalled  MPCR -2.1;SIHCR -7.5UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 366 of 397 \n Weakness ID  Description  RTB Requirements  \nWRTB -00053  Lack of disk, storage, or RAID failure planning \nimpacts system availability  SIHCR -13 \nWRTB -00054  Undefined behavior or malicious behavior by \nunapproved kernel drivers  SIHCR -15 \nWRTB -00055  Protection mechanism failure due to \nimproper configuration  DPMR -12.7;DPMR -12.7.1;SIHCR -14 \nWRTB -00056  Reliance on error -prone user input to \nperform functions.  SIHCR -1;SIHCR -2 \nWRTB -00057  Loss of OS vendor's package integrity, which \nunderpin the OS certification  SIHCR -5.2 \nWRTB -00058  Exposure of development environment to \nthe internet  DPMR -12;DPMR -12.1;DPMR -12.12  \nWRTB -00059  Development environment accessible by \nunconstrained transfer mech anism that \nallows bi -directional communication  DPMR -12.2;DPMR -12.3;DPMR -12.4 \nWRTB -00060  Insufficient vetting of personnel within \norganization  DPMR -", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}750{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "749", "chunk": "11 \nWRTB -00061  Use of low -trust/unevaluated 3rd -party \nhardware  DPMR -12.2 \nWRTB -00062  Use of unsupported version of programming \nlanguage loses the compatibility and testing \nguarantees provided by the OS vendor.  DPMR -14 \nWRTB -00063  Missing version control system for tracking \nsoftware or hardware design changes  DPMR -1 \nWRTB -00064  Loss of software or  hardware design artifacts  DPMR -1 \nWRTB -00065  Release or deployment of wrong software \nversion  DPMR -1;MPCR -2.1 \nWRTB -00066  Missing requirements management tracking \nsoftware  DPMR -2 \nWRTB -00067  Unimplemented security -relevant \nrequirement  DPMR -2 \nWRTB -00068  Installation of applications or libraries that \nprovide dangerous capabilities to potential \nmalicous adversary  DPMR -5 \nWRTB -00069  Software interpreter allows unrestricted \naccess to system calls through language \nconstructs.  DPMR -8.1;DPMR -8.2 \nWRTB -00070  System administrator personnel turnover  RBACR -10UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 367 of 397 \n Weakness ID  Description  RTB Requirements  \nWRTB -00071  Failure to enforce Two Knowledgeable \nPerson Cont", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}751{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "750", "chunk": "rol (TKPC) reviews for security \ncritical actions  RBACR -10.1;RBACR -2.1;RBACR -2.2;RBACR -\n2.3;RBACR -2.3.1;RBACR -2.3.2;RBA CR-\n4.4.1;RBACR -7.1;RBACR -7.10;RBACR -\n7.11;RBACR -7.12;RBACR -7.13;RBACR -\n7.14;RBACR -7.15;RBACR -7.16;RBACR -\n7.2;RBACR -7.3;RBACR -7.4;RBACR -\n7.5;RBACR -7.6;RBACR -7.7;RBACR -\n7.8;RBACR -7.9;SASR -11.13;VIRT -4.8 \nWRTB -00072  Capabilities are combined into a single role \nthat allows that role to perform unsafe \nactions  GDFR -38.2;RBACR -1;VIRT -15;VIRT -4.7 \nWRTB -00073  Improper handling of allowed USB devices  RBACR -7.15 \nWRTB -00074  Least privilege violation: Access to files of \nother CDS processes  MPCR -25;MPCR -25.1;OSSR -4.5 \nWRTB -00075  System update changes configuration to \nunsafe defaults without regard for existing \nconfiguration.  SIHCR -5.5 \nWRTB -00076  Failure to validate file integrity.  SIR-10.10;SIR -10.11  \nWRTB -00077  Failure to Achieve Fault Tolerance due to \nInsufficient Diversity of Implementations  DPMR -19;FRVR -1;FRVR -9;GAR -1.1;GDFR -\n30.1;GDFR -30.2;GDFR -30.3;GDFR -43 \nWRTB -00078  System does not prevent processes from \nmaking non -native system calls, potentially \nbypassing SECCOMP filtering.  PIR-10.11 \nWRTB -00079  Mismatch between configuration and \napplicable software version.  MPCR -2.1;SASR -11.10;SASR -", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}752{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "751", "chunk": "11.12  \nWRTB -00080  Excessive amount of unused administrative \naccounts  RBACR -10.1 \nWRTB -00081  Administrator Configuration Error  VIRT -17;VIRT -18.2;VIRT -18.3;VIRT -20 \nWRTB -00083  Filter fails to produce reports to be validated \nby the FRV  GDFR -6.1;GDFR -6.2 \nWRTB -00085  Inability to perform incident response due to \ninsufficient auditing or alerting.  GDFR -19;GDFR -19.1;GDFR -19.2;GDFR -\n19.3; GDFR -19.4;GDFR -19.5;GDFR -\n21;GDFR -21.1;GDFR -21.2;GDFR -22;MPCR -\n14 \nWRTB -00086  Insufficient scrubbing of metadata from filter \nreports  GDFR -38.4.1;GDFR -38.4.2;GDFR -\n38.4.3;GDFR -38.4.4  \nWRTB -00088  CDS component functionality combined into \na single modular component that allows \nunsafe actions.  MPCR -7.2UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 368 of 397 \n Weakness ID  Description  RTB Requirements  \nWRTB -00090  Modular component communication \nendpoints connected by unconstrained \ntransfer mechanism that allows bi -directional \ncommunication.  MPCR -20 \nWRTB -00091  Insufficient or incomplete MAC policy that \nfails to isolate its target as intended.  MPCR -3 \nWRTB -00092  Modular co", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}753{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "752", "chunk": "mponent endpoints connected by \nunconstrained transfer mechanism that \nallows bi -directional communication.  MPCR -7.1 \nWRTB -00093  Reliance on incomplete, inconsistent, or \ncontradictory installers.  MPCR -2 \nWRTB -00094  Missing Integrity Check for Local Resources  SIR-11;SIR -11.1;SIR -11.2;SIR -11.4  \nWRTB -00095  Trust in Third -Party Signing Certificate  SIR-1.3;SIR -1.4 \nWRTB -00096  Use of Software on Uncertified Platform or \nWith an Uncertified Configuration  VIRT -9 \nWRTB -00098  Missing network monitoring system to detect \ncompromised or renegade hosts or \nhypervisors  VIRT -27 \nWRTB -00099  Least privilege violation: Access to \ncommunication channels of other CDS VMs \nor hypervisors.  VIRT -22 \nWRTB -00100  Sharing of the Hypervisor Between High -\nPrivilege Software and High -Threat Software  VIRT -4.6 \nWRTB -00101  Remanent Data Included in Snapshot  VIRT -16 \nWRTB -00103  Mutable Kernel Software  VIRT -19 \nWRTB -00104  Protection Mechanism Failure at Network \nTraffic Layer  VIRT -11.4  \nWRTB -00105  Failure to Initialize Protection Mechanism \nBefore Operation  JALSR -38 \nWRTB -00106  Failure to Quarantine Known or Suspected \nMalicious Data  JALSR -30 \nWRTB -00107  Unacceptable probability of fault in critical \ncomponent  FRVR -9.1 \nWRTB -00108  Missing Attestation", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}754{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "753", "chunk": " That Security Gate \nPassed  RPR-5;RPR -6UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 369 of 397 \n Weakness ID  Description  RTB Requirements  \nWRTB -00109  Unsafe handling of low -integrity data by \nhigh -integrity process  DRR -2;JSR -3;PAR -10 \nWRTB -00110  Exposure of Resource to lower integrity \nnetworks  CMSR -4;CMSR -4.1.1  \nWRTB -00111  Insufficient Insider Threat Monitoring  CMSR -11 \nWRTB -00112  Improper Validation of Network Traffic Label  MLS -11.1;MLS -11.2;MLS -11.3UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 370 of 397 \n 36 Appendix H \u2013 Example Boot Sequences for Tactical CDS \nwith FPGA s \nExpanded and moved to the CDS Anti -Tamper and TEMPEST Implementation Requirements  \ndocument.UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 371 of 397 \n Appendi", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}755{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "754", "chunk": "x I \u2013 Alignment of RTB requirements to NIST \nControls  \nThe CDS Overlay identifies security and privacy control specifications needed to safeguard a \nCDS, the networks to which they connect, and the information stored, processed, or transmitted \nby the CDS.  The Committee for National Security Systems Ins truction (CNSSI) No. 1253 \ndefines a set of security and privacy baselines to identify the applicable controls based on the \nsystem categorization. This CDS Overlay incorporates the controls that comprise the High -High -\nModerate (H -H-M) security baseline, the  privacy baseline, and additional controls needed for a \nCDS to safeguard national security information and networks.  \nThe controls included in the CDS Overlay identify the objective (i.e., the \u2018what\u2019) that needs to be \nimplemented.   The RTB requirements are more detailed and provide specific information for \nCDS implementations (i.e., the \u2018how\u2019).   This appendix contains the mapping between of NIST \ncontrols in the CDS Overlay to requirements in RTB v5 that are primarily the responsibility of \nthe Developer/Asses sor.  Since RTB requirements are principally technical and targeted toward \nCDS development, not all of the NIST controls included in the CDS Overlay (e.g., those that are \nprimarily the responsibility of the", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}756{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "755", "chunk": " Site/Assessor) are included in this mapping.   \n \nThe requirement cells with blue shading  identify the new requirements in RTB v5.  \n \n \nRTB \nRequirement  NIST \nControl  \nOWT -1 AC-4(28)  \nSA-17 \nOWT -2 SC-7(29)  \nSC-37 \nOWT -3 SC-37 \nOWT -4 AC-4(27)  \nOWT -5 AC-4(27)  \nSA-17(9)  \nOWT -6 SA-17(9)  \nOWT -7   \nOWT -8 SC-3(1) \nSC-49 \nOWT -9 AC-4(27)  \nSA-15(5)  RTB \nRequirement  NIST \nControl  \nOWT -10 PL-8(1) \nSA-15(5)  \nOWT -11 SC-38 \nOWT -12 AC-4(27)  \nSA-15(5)  \nOWT -12.1  PL-8(2) \nOWT -12.2  AC-4(28)  \nCA-2(3) \nOWT -12.3  SC-7(13)  \nOWT -12.4  SC-43 \nOWT -12.5  PL-8 \nOWT -13 SC-41 \nOWT -14 SC-41 \nOWT -15 SC-41 RTB \nRequirement  NIST \nControl  \nOWT -16 SC-41 \nOWT -17 SC-7(17)  \nOWT -17.1  AC-4(24)  \nOWT -18 SC-7(13)  \nSC-7(21)  \nOWT -18.1  SC-7(13)  \nSC-7(21)  \nOWT -18.2  SC-7(13)  \nSC-7(21)  \nOWT -19 PL-8  \nOWT -19.1  SA-15(5)  \nSA-8 \nOWT -20 SA-5 \nOWT -21 SA-8 \nAU-4(1)UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 372 of 397 \n RTB \nRequirement  NIST \nControl  \nOWT -21.1  AU-4(1) \nSI-4(16)  \nOWT -22 SA-8 \nOWT -22.1  SA-8 \nOWT -22.2    \nOWT -23 CM-7 \nOWT -24 SC-30(2)  \nSA-15(5)  \nOWT -24.1  SC-30(2)  \nSA-1", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}757{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "756", "chunk": "5(5)  \nOWT -25 SA-15(5)  \nOWT -26 AC-4(8) \nAC-4(12)  \nOWT -27 AC-4(7) \nOWT -28 AC-4(8) \nAC-4(12)  \nOWT -28.1  AC-4(8) \nOWT -29 AC-4(7) \nOWT -30 PL-8 \nOWT -31 AC-4(8) \nSI-11 \nOWT -31.1  SC-49 \nTR-1 AT-2(4) \nAT-2(5) \nAT-3 \n SA-16 \nTR-2 SA-16 \nTR-3 SA-16 \nSA-8(32)  \nTR-4 AT-3 \nSA-16 \nTR-5 AT-3 \nTR-6 SA-5 \nSA-8(32)  \nSA-16 RTB \nRequirement  NIST \nControl  \nTR-6.1 SA-5 \nSA-8(32)  \nTR-6.2 SA-5 \nSA-8(32)  \nPMR -1 MA-7 \nNCR -1 SC-7(14)  \nNCR -2 SC-7(14)  \nNRR -1 SA-8(7) \nNRR -2 SC-7(13)  \nSC-7(29)  \nNRR -3 SC-7(13)  \nSC-7(29)  \nNRR -4 SC-7(13)  \nSC-7(29)  \nNRR -4.1 AC-17(2)  \nNRR -5 PL-8 \nNRR -6   \nNRR -7 AC-17(2)  \nNRR -7.1 AC-17(2)  \nNRR -7.2 AC-17(3)  \nNRR -8 SA-8(6) \nSC-4 \nNRR -8.1 PL-8 \nNRR -9 SC-5(2) \nSI-13(5)  \nNRR -9.1 CM-7 \nNRR -9.2  SA-8(6) \nNRR -9.3  SA-4(9) \nNRR -9.4  SA-15(5)  \nNRR -9.5  AC-4 \nSA-8(18)  \nNRR -9.6  SI-15 \nNRR -9.7 SA-4(9) \nNRR -9.7.1  SA-4(9) RTB \nRequirement  NIST \nControl  \nNRR -9.8   SC-5 \nNRR -9.9   SA-4(9) \nNRR -10 PL-8 \nSC-37 \nNRR -11 SA-8 \nSCR-1 CA-2(3) \nSA-11(3)  \nSI-4(9) \nSCR-2 RA-2 \nSCR-2.1 RA-2 \nSCR-2.2 PL-2 \nSCR-2.3 SA-4 \nSA-4(2) \nSA-17(2)  \nSCR-2.4   \nSCR-3 SA-4(7) \nSCR-3.1 SA-4(7) \nSCR-3.2 SA-4(7) \nGAR -1 AC-4(27)  \nAC-4(28)  \nAC-25 \nSA-8(3) \nSA-17(9)  \nGAR -1.1 AC-4(27)  \nSA-17(9)  \nGAR -1.2 AC-4(28)  \nGAR -1.3 AC-3(4) \nGAR -1.4 AC-3(3) \nGAR -1", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}758{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "757", "chunk": ".5 AC-3(15)  \nGAR -2 AC-4(7) \nSC-49 \nGAR -2.1 SC-49 \nGAR -3 AC-4(27)  \nSI-10UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 373 of 397 \n RTB \nRequirement  NIST \nControl  \nGAR -3.1 AC-4(12)  \nSI-10 \nGAR -3.2 AC-4 \nGAR -4 SI-4(23)  \nGAR -5 SI-4(23)  \nGAR -5.1 AC-3(3) \nAC-16(3)  \nGAR -5.2 AU-4(1) \nGAR -5.3 CM-7(5) \nGAR -5.3.1    \nGAR -5.4 SC-7 \nSC-7(12)  \nGAR -5.4.1  AU-2 \nGAR -5.4.2  AU-2 \nGAR -5.4.3  AU-2 \nGAR -5.4.4  AU-2 \nGAR -5.4.5  AU-2 \nGAR -5.4.6  AU-2 \nAU-3 \nGAR -5.5 CM-8(3) \nSI-4(23)  \nGAR -5.5.1  AU-2 \nGAR -5.6 SI-7 \nGAR -6 AC-3(3) \nGAR -7 CM-8 \nGAR -7.1 CM-8 \nGAR -7.2 CM-8 \nGAR -8 SA-4(2) \nGAR -9 SA-4(5) \nGAR -9.1 SA-4(5) \nGAR -9.2 SC-30 \nSC-38 \nGAR -10 CM-10 RTB \nRequirement  NIST \nControl  \nGAR -10.1  CM-10 \nGAR -10.2  SI-17 \nGAR -10.2.1  AU-2 \nGAR -10.3  CM-8 \nSA-8 \nGAR -10.4  AU-2 \nGAR -10.5  AU-2 \nGAR -10.6  AC-2(11)  \nGAR -10.6.1  AU-2 \nC2R-1  AC-4(19)  \nSI-7(17)  \nC2R-2 AC-4(19)  \nC2R-3 AC-4(6) \nAC-4(19)  \nC2R-4 AC-4(6) \nC2R-4.1 SA-8(20)  \nC2R-4.2 AC-4(19)  \nC2R-5 AC-4(6) \nC2R-5.1 AC-4(19)  \nC2R-6 AC-4(6) \nC2R-6.1 AC-4(6) \nC2R-6.2 AC-4(6) \nC2R-7 SA-8(6)     \nC2R-7.1   \nC2R-8 AC-4(21)  \nC2R-9 AC", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}759{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "758", "chunk": "-4 \nAC-4(6) \nC2R-9.1 AC-4(6) \nAC-4(8) \nC2R-10 AC-4(21)  \nC2R-11 AC-4(27)  \nAC-4(28)  \nOSSR -1 AC-6 RTB \nRequirement  NIST \nControl  \nOSSR -1.1 AC-6 \nOSSR -2 AC-6 \nOSSR -2.1 AC-6(8) \nOSSR -2.2 AC-6 \nOSSR -2.3 SA-15(5)  \nOSSR -2.4 SA-15(5)  \nOSSR -2.5 AC-6 \nSA-15(5)  \nOSSR -3 AC-6(5) \nOSSR -4 AC-3(4) \nOSSR -4.1 SA-17 \nOSSR -4.2 AC-3(3) \nOSSR -4.3  AC-6 \nOSSR -4.4  AC-6 \nOSSR -4.5 AC-6 \nOSSR -4.5.1   AC-4(28)  \nAC-6 \nOSSR -4.6  AC-6 \nSA-8(6) \nOSSR -4.7 AC-6(8) \nCM-7(2) \nOSSR -4.8 AC-6 \nOSSR -4.9 SA-8 \nOSSR -5 CM-6 \nOSSR -5.1 CM-6 \nOSSR -6 SA-8(7) \nSC-3(3) \nOSSR -7 SA-4(7) \nOSSR -8 AC-6(10)  \nOSSR -8.1 SA-15 \nSA-15(5)  \nOSSR -8.2 CM-7 \nOSSR -8.3 SI-10UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 374 of 397 \n RTB \nRequirement  NIST \nControl  \nOSSR -8.4 AC-6 \nOSSR -8.5 AU-3 \nAU-3(1) \nOSSR -9 AC-6 \nSA-8(14)  \nOSSR -9.1 AC-3(15)  \nSA-8(14)  \nOSSR -10 SA-8 \nOSSR -10.1  SA-8 \nOSSR -10.2  SA-8 \nOSSR -10.3  SA-8 \nOSSR -10.3.1  SA-8 \nOSSR -11 SA-8 \nOSSR -12 SA-15(5)  \nOSSR -13 SA-8 \nOSSR -14 SA-8 \nOSSR -15 SA-8 \nOSSR -15.1  SA-8 \nOSSR -16 SC-7 \nOSSR -16.1  SC-7 \nOSSR -17 SC-7(16)  \nOSSR -18 CM-7 \nSC-7(5) \nOSSR -18.1  SC-", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}760{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "759", "chunk": "7(3) \nOSSR -19 SC-7(5) \nOSSR -20 SC-45 \nOSSR -20.1  SC-7(5) \nSC-45 \nOSSR -20.2  SC-7(5) \nSC-45 \nOSSR -20.3  SC-7(5) \nSC-45 \nOSSR -20.4  SC-43 RTB \nRequirement  NIST \nControl  \nOSSR -21 CM-6 \nSI-2(4) \nOSSR -21.1  PL-9 \nOSSR -21.2  CM-6(1) \nOSSR -21.3    \nOSSR -22 AC-3(3) \nOSSR -22.1  AC-3(3) \nOSSR -23 AC-6 \nOSSR -23.1  AC-6 \nOSSR -23.2  SC-39 \nOSSR -23.3    \nOSSR -23.4  AU-2 \nOSSR -23.5  CM-7 \nSC-39 \nOSSR -24 CM-8 \nOSSR -24.1  CM-8 \nOSSR -24.2  CM-8(1) \nOSSR -24.3  CM-3(1) \nOSSR -25 SA-8 \nOSSR -25.1   CM-7 \nSA-15(5)  \nOSSR -25.2  CM-7 \nSA-15(5)  \nOSSR -25.3   CM-7(4) \nOSSR -26  SA-15(5)  \nOSSR -27  SA-8(18)  \nOSSR -27.1   CM-7 \nOSSR -27.2  SC-7(17)  \nOSSR -27.2.1  AC-6 \nSC-39  \nOSSR -27.3  SA-8(2) \nSA-8(6) \nOSSR -27.4  AC-6 RTB \nRequirement  NIST \nControl  \nOSSR -27.5  CM-6 \nOSSR -27.6  AC-6 \nSA-8(14)  \nOSSR -27.7  AC-6 \nSA-8(14)  \nOSSR -27.8  AC-6 \nSA-8(14)  \nOSSR -27.9  AC-6 \nCM-7 \nOSSR -27.10  AC-3(3) \nOSSR -27.11  CM-7 \nOSSR -27.12  AC-6 \nSA-8(14)  \nOSSR -27.13  AC-6 \nSA-8(14)  \nOSSR -27.14  AC-3(3) \nAC-6 \nSA-8(14)  \nOSSR -27.15  AC-3(4) \nOSSR -27.15.1  SA-15(5)  \nOSSR -27.16  AC-6 \nOSSR -27.17  AC-3(4) \nOSSR -27.18  AC-3(3) \nOSSR -27.19  AC-3 \nAC-6 \nSA-15(5)   \nOSSR -28 AC-7 \nOSSR -29  AC-7 \nOSSR -29.1  AC-7 \nOSSR -29.2  AC-7 \nOSSR -30  IA-5(1) \nOSSR -31  SI-6 \nSI-7(9) \nOSSR ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}761{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "760", "chunk": "-31.1  SI-6 \nSI-7(1)UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 375 of 397 \n RTB \nRequirement  NIST \nControl  \nOSSR -31.2  AU-2 \nAC-3(3) \nOSSR -32 CM-10(1)  \nSA-8(8) \nOSSR -32.1  SA-8(8) \nOSSR -32.2  SA-8(8) \nOSSR -32.3  SA-8(8) \nOSSR -32.3.1  SA-8(8) \nOSSR -32.3.2  SA-8(8) \nOSSR -32.4  SA-8(8) \nOSSR -32.5  SA-8(8) \nOSSR -32.5.1   SA-8(8) \nOSSR -32.6  SA-8(8) \nOSSR -33  SA-11 \nOSSR -34 CM-7 \nOSSR -35 AC-6 \nSA-8(14)  \nOSSR -35.1  CM-7 \nOSSR -35.2  AC-6 \nSA-8(14)  \nOSSR -36 SC-39 \nOSSR -36.1  SA-17(7)  \nSC-39 \nOSSR -36.2  SA-17(7)  \nSC-39 \nOSSR -36.3  AC-3 \nSA-17(7)  \nOSSR -36.4  SC-7 \nOSSR -36.5  SA-17(7)  \nSC-39 \nOSSR -36.6  SA-17(7)  \nSC-39 \nSC-39(2)  \nOSSR -37 SA-8(5) \nSC-6 RTB \nRequirement  NIST \nControl  \nOSSR -37.1  SC-6 \nOSSR -38 AC-6(8) \nCM-7 \nOSSR -39 AU-2 \nAU-3 \nOSSR -40 SC-45 \nOSSR -40.1  CM-7 \nOSSR -40.2  SA-17 \nOSSR -40.3  SA-17 \nOSSR -41 SA-15(5)  \nOSSR -42 SA-15(5)  \nOSSSR -43 SC-43 \nOSSSR -44 SC-43 \nOSSSR -45 SA-15(5)  \nSASR -1 AC-17 \nSASR -2 AC-6(8) \nSASR -2.1 CM-7 \nSC-7 \nSASR -2.2 AC-3(3) \nSASR -2.3 CM-7 \nSASR -3 AC-6(8) \nAU-3 \nSASR -3.1  AC-6 \nSASR -4 SA-8(27)  \nSI-10 \nSI-10(3)  \nSASR -4.", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}762{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "761", "chunk": "1 AC-6 \nCM-7 \nSASR -4.2 SI-10 \nSASR -4.3  SA-8(29)  \nSASR -4.4 AC-6 \nSA-15(5)  \nSASR -5 MP-7 \nSASR -5.1 CM-3(8) RTB \nRequirement  NIST \nControl  \nSASR -5.2 CM-6 \nCM-8 \nSASR -5.2.1  SC-28 \nSASR -5.3 SI-7(5) \nSASR -5.4 SI-7(5) \nSASR -5.5 SI-7(8) \nSASR -5.6 SI-7(6) \nCM-14 \nSASR -5.6.1  CM-14 \nSASR -5.6.2  SI-7(6) \nSASR -5.7   \nSASR -5.8 SC-28(1)  \nSASR -5.8.1  SC-28(1)  \nSASR -5.9 MP-7 \nSASR -5.10  MP-7 \nSASR -5.11  MP-7 \nSASR -5.12  MP-1 \nSI-7(15)  \nSASR -6 AC-6(5) \nSASR -6.1 AC-6(5) \nSASR -6.2 IA-1 \nIA-2(1) \nSASR -6.3 AC-2(11)  \nAC-6(5) \nSASR -6.4 AU-2 \nSASR -6.5 AC-2(11)  \nSASR -6.6 SC-43 \nSASR -7 AC-3(5) \nSASR -7.1 MA-1 \nSASR -7.1.1  MA-1 \nSASR -7.2 MA-1 \nSASR -7.2.1  MA-1UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 376 of 397 \n RTB \nRequirement  NIST \nControl  \nSASR -7.3 AC-3(15)  \nMA-1 \nSASR -7.4 AC-3(7) \nMA-1 \nSASR -7.5 MA-1 \nSASR -7.5.1  MA-1 \nSASR -7.5.2  MA-1 \nSASR -7.5.3  MA-1 \nSASR -7.5.4  MA-1 \nSASR -7.5.5  MA-1 \nSASR -7.5.6  MA-1 \nSASR -7.5.7  MA-1 \nSASR -7.5.8    \nSASR -7.6 MA-1 \nSASR -7.6.1  MA-1 \nSASR -7.6.2  MA-1 \nSASR -7.6.3  MA-1 \nSASR -7.6.4  MA-1 \nSASR -7.6.5   MA-1 \nSI-3(4) \nSASR -7.6.6 ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}763{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "762", "chunk": " MA-1 \nSASR -7.6.7  MA-1 \nSASR -7.6.8  MA-1 \nSASR -7.6.9  MA-1 \nSASR -7.7 MA-1 \nSASR -7.8 AC-4(10)  \nSASR -7.8.1    \nSASR -7.8.2  AC-4(10)  \nSASR -7.8.3  AC-4(10)  \nSASR -7.8.4  AC-4(10)  \nSASR -7.9 AC-2(3) \n SASR -8 AC-4(10)  RTB \nRequirement  NIST \nControl  \nSASR -9 CM-7(1) \nSASR -10 CM-7(1) \nSASR -11 CM-3 \nSASR -11.1  CM-2(3) \nSA-15(11)  \nSASR -11.2  CM-2(3) \nCP-10 \nSASR -11.3  CM-3(1) \nSASR -11.4  CM-3 \nSASR -11.4.1  MA-1 \nSASR -11.4.2  MA-1 \nSASR -11.5  CM-2(3) \nSASR -11.6  CM-3 \nSA-17(8)  \nSASR -11.7  AU-9 \nCM-3 \nSASR -11.8  CM-3(1) \nSASR -11.9  CM-3(1) \nSASR -11.10  CM-3 \nSASR -11.11  CM-3(1) \nSASR -11.12  CM-3(1) \nSASR -11.13  CM-5(4) \nSASR -12 CM-6(1) \nSASR -13 SC-12 \nSASR -14 AC-7(2) \nMP-6 \nSASR -14.1  CM-5(4) \nSASR -15 AC-4(10)  \nSASR -16 CM-3(8) \nSASR -16.1  CM-3 \nDPMR -1 SA-10 \nDPMR -1.1 SA-10(1)  RTB \nRequirement  NIST \nControl  \nDPMR -2 SA-8(30)  \nSA-15 \nDPMR -3 SA-3 \nSA-8 \nSA-11(5)  \nSA-11(6)  \nSA-11(8)  \nSA-15(8)  \nSC-31 \nSC-31(1)  \nDPMR -3.1 SA-4(3) \nDPMR -4 SA-4(3) \nSA-8 \nDPMR -5 SA-8 \nDPMR -6 SA-8 \nDPMR -7 SA-8 \nDPMR -8 SA-8 \nSC-18 \nDPMR -8.1 CM-7 \nDPMR -8.2 CM-7 \nDPMR -9 AC-3(15)  \nSA-8 \nDPMR -10 SI-2 \nDPMR -11 SA-21 \nDPMR -12 CM-2(6) \nSA-3(1) \nSA-15(5)  \nDPMR -12.1  SA-3(1) \nSA-15(5)  \nDPMR -12.2  SA-15 \nDPMR -12.3  MP-7 \nSA-15 \nDPMR -12.4  MP-7 \nSA-15 \nDPMR", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}764{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "763", "chunk": " -12.5  AC-17(2)  \nDPMR -12.6  AC-17(2)UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 377 of 397 \n RTB \nRequirement  NIST \nControl  \nDPMR -12.7  AC-17(2)  \nDPMR -12.7.1  AC-17(2)  \nSC-7(21)  \nDPMR -12.8  SA-15 \nDPMR -12.9  AC-17(2)  \nSC-7(21)  \nDPMR -12.10  MP-5 \nDPMR -12.11  SA-11 \nDPMR -12.12  SA-11 \nDPMR -12.13  SR-4 \nDPMR -12.14  SA-3(1)  \nDPMR -12.15  SA-3(1)  \nDPMR -13   \nDPMR -14  SA-15 \nSA-15(5)  \nDPMR -15  SA-15(5)  \nDPMR -16 CM-8(4) \nDPMR -17 SA-4 \nSR-4 \nDPMR -18 CM-7(8) \nSA-15 \nSC-18 \nDPMR -19 SC-29 \nDPMR -20 SA-15 \nSA-15(5)  \nDPMR -21 CM-2 \nDPMR -22 SA-3(3) \nSIHCR -1 CM-11(3)  \nSIHCR -1.1 CM-11(3)  \nSIHCR -2 CM-6(1) \nSIHCR -3 CM-11 \nSIHCR -3.1  CM-11(3)  \nSIHCR -3.2 CM-11 \nSA-10(6)  RTB \nRequirement  NIST \nControl  \nSIHCR -3.2.1  SA-5 \nSIHCR -3.2.2  CM-11 \nSIHCR -3.2.3  CM-14 \nSIHCR -3.3  AC-17 \nCM-11 \nSIHCR -3.3.1  AC-17 \nCM-11 \nSIHCR -3.3.2  AC-17 \nCM-11 \nSIHCR -3.3.3  AC-17 \nCM-11 \nSIHCR -3.3.4  AC-17 \nSI-7 \nSIHCR -3.3.5  AC-17 \nSI-7 \nSIHCR -4   \nSIHCR -5 CM-11 \nCM-14 \nSIHCR -5.1  CM-11 \nSIHCR -5.1.1  CM-11 \nSIHCR -5.1.2  CM-11 \nSIHCR -5.2  CM-11 \nSIHCR -5.2.1  CM-11 \nSIHCR -5.3  CM-11 \nCM-14 \n", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}765{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "764", "chunk": "SIHCR -5.4    \nSIHCR -5.5 CM-11 \nSIHCR -6 CM-11 \nSIHCR -7 CM-11 \nSIHCR -7.1   \nSIHCR -7.2 CM-11 \nSIHCR -7.3 CM-11 \nSIHCR -7.4 CM-11 RTB \nRequirement  NIST \nControl  \nSIHCR -7.5  CM-11 \nSA-17(8)  \nSIHCR -8 SA-3(3) \nSA-8(8)  \nSI-2(4) \nSIHCR -8.1  CM-11 \nSIHCR -8.1.1  CM-11 \nSIHCR -8.1.2  CM-11 \nCP-10 \nCP-10(4)  \nSIHCR -8.1.3  CM-11 \nSIHCR -9 CP-9(8) \nSIHCR -10 CP-10(6)  \nSI-7(15)  \nSIHCR -11 IA-5(1) \nSIHCR -12 CP-9(6)  \nSC-36 \nSIHCR -13 AU-2 \nAU-3 \nSI-4 \nSIHCR -14 CM-6 \nSIHCR -14.1  CM-6 \nSIHCR -14.2    \nSIHCR -14.3    \nSIHCR -14.4    \nSIHCR -14.5    \nSIHCR -14.6    \nSIHCR -14.7    \nSIHCR -14.8    \nSIHCR -15 CM-7(9) \nSIHCR -16 IA-3(3) \nSIHCR -17 CM-6(1) \nSIHCR -17.1  SI-7(15)UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 378 of 397 \n RTB \nRequirement  NIST \nControl  \nSIHCR -17.2  CM-14 \nSI-7(15)  \nSIHCR -17.3  CM-14 \nSIHCR -17.4  CM-6 \nSIHCR -18 SA-4(9) \nSIHCR -19 CM-11 \nSIHCR -20 CM-6 \nCM-11 \nSIHCR -20.1  CM-6 \nCM-11 \nSIHCR -21 SA-8(23)  \nPIR-1 AC-3(15)  \nAC-6 \nPIR-2 AC-3(15)  \nAC-6 \nPIR-3 SA-8(6) \nPIR-4 AC-3(15)  \nAC-6 \nPIR-5 AC-3(15)  \nAC-6 \nPIR-6 AC-6 \nAU-9(4) \nPIR-7 SC-4(2) \nSC-39 \nPIR-7.1 SC-4(2) \nSC-39 \n", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}766{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "765", "chunk": "PIR-8 AC-6 \nPIR-9 AC-6 \nPIR-10 AC-6 \nPIR-10.1  AC-6 \nPIR-10.2  AC-6 \nPIR-10.3  AC-6 \nPIR-10.4  AC-6 \nPIR-10.5  AC-6 RTB \nRequirement  NIST \nControl  \nPIR-10.6  AC-6 \nPIR-10.7  AC-6 \nPIR-10.8  AC-6 \nPIR-10.9  AC-6 \nPIR-10.10  AC-6 \nPIR-10.11  AC-6 \nPIR-10.12  AC-6 \nRBACR -1 AC-3(7) \nSC-2(1) \nRBACR -2 AC-3(2) \nRBACR -2.1 AC-3(2) \nCM-5(4) \nRBACR -2.2 AC-3(2) \nCM-5(4) \nRBACR -2.3 AC-3(2) \nCM-5(4) \nRBACR -2.3.1  AC-3(2) \nCM-5(4) \nRBACR -2.3.2  AC-3(2) \nCM-5(4) \nRBACR -3 AC-3(7) \nAC-5 \nRBACR -3.1 AC-5 \nRBACR -3.1.1  AC-5 \nRBACR -3.1.2  AC-5 \nRBACR -3.1.3  AC-5 \nRBACR -3.1.4  AC-5 \nRBACR -3.1.5  AC-5 \nRBACR -3.1.6  AC-5 \nRBACR -3.1.7  AC-5 \nRBACR -3.1.8  AC-5 \nRBACR -3.1.9  AC-5 \nRBACR -3.1.10  AC-5 RTB \nRequirement  NIST \nControl  \nRBACR -3.1.11  AC-5 \nRBACR -3.1.12  AC-5 \nAC-7(2) \nRBACR -3.1.13  AC-5 \nRBACR -3.1.14  AC-5 \nRBACR -3.2 AC-5 \nRBACR -3.2.1  AC-5 \nRBACR -3.2.2  AC-4(11)  \nAC-5 \nRBACR -3.2.3  AC-5 \nRBACR -3.2.4  AC-5 \nRBACR -3.2.5  AC-5 \nRBACR -3.2.6  AC-5 \nRBACR -3.2.7  AC-5 \nRBACR -3.2.8  AC-5 \nRBACR -3.3 AC-5 \nRBACR -3.3.1  AC-4(11)  \nAC-5 \nRBACR -3.3.2  AC-5 \nRBACR -3.4 AC-5 \nAU-6(7) \nRBACR -3.4.1  AC-5 \nRBACR -3.4.2  AC-5 \nRBACR -3.4.3  AC-5 \nRBACR -3.4.4  AC-5 \nRBACR -3.4.5  AC-5 \nRBACR -4 AC-6 \nRBACR -4.1 AC-6 \nRBACR -4.2 AC-6 \nRBACR -4.3 AC-6 \nAU-6(7) \nRBACR -4.4 AC-", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}767{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "766", "chunk": "6UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 379 of 397 \n RTB \nRequirement  NIST \nControl  \nRBACR -4.4.1  AC-3(2) \nAC-6 \nRBACR -5 AC-3(7) \nRBACR -6 AC-6(7) \nRBACR -7 AC-3(2) \nCM-5(4) \nSA-8(15)  \nRBACR -7.1 AC-3(2) \nCM-5(4) \nSA-8(15)  \nRBACR -7.2 AC-3(2) \nCM-5(4) \nSA-8(15)  \nRBACR -7.3 AC-3(2) \nCM-5(4) \nSA-8(15)  \nRBACR -7.4 AC-3(2) \nCM-5(4) \nSA-8(15)  \nRBACR -7.5 AC-3(2) \nAU-9(5) \nSA-8(15)  \nRBACR -7.6 AC-3(2) \nCM-5(4) \nSA-8(15)  \nRBACR -7.7 AC-3(2) \nCM-5(4) \nSA-8(15)  \nRBACR -7.7.1    \nRBACR -7.8 AC-3(2) \nCM-5(4) \nSA-8(15)  \nRBACR -7.9 AC-3(2) \nCM-5(4) \nSA-8(15)  \nRBACR -7.10  AC-3(2) \nCM-5(4) \nSA-8(15)  RTB \nRequirement  NIST \nControl  \nRBACR -7.11  AC-3(2) \nCM-5(4) \nSA-8(15)  \nRBACR -7.12  AC-3(2) \nCM-5(4) \nSA-8(15)  \nRBACR -7.13  AC-3(2) \nCM-5(4) \nSA-8(15)  \nRBACR -7.14  AC-3(2) \nCM-5(4) \nSA-8(15)  \nRBACR -7.15  AC-3(2) \nCM-5(4) \nSA-8(15)  \nRBACR -7.16  AC-3(2) \nCM-5(4) \nSA-8(15)  \nRBACR -7.17  AC-3(2) \nCM-5(4) \nSA-8(15)  \nRBACR -7.18  AC-3(2) \nCM-5(4) \nSA-8(15)  \nRBACR -8 AC-3(7) \nRBACR -9 AC-6(5) \nRBACR -10 AC-2 \nAC-2(11)  \nRBACR -10.1  AC-2(11)  \nAC-3(2) \nRBACR -10.2  AC-2(11)  \nRBACR -10.3  AC-2(11", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}768{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "767", "chunk": ")  \nRBACR -10.4  AC-2(11)  \nAC-6(1) \nAC-6(5) \nRBACR -11 AC-3(15)  \nSA-8(15)  \nRBACR -12 AU-2 RTB \nRequirement  NIST \nControl  \nEDSR -1 SC-8(1) \nSC-13 \nSC-28(1)  \nEDSR -1.1 SC-8(1) \nSC-13 \nSC-28(1)  \nEDSR -1.2 SC-13 \nSC-28(1)  \nEDSR -2 SC-8(1) \nSC-23(5)  \nEDSR -2.1  SC-8(1) \nSC-23(5)  \nEDSR -2.2  SC-8(1) \nSC-23(5)  \nEDSR -3 SC-13 \nEDSR -4 SC-8(1) \nSC-23(5)  \nEDSR -4.1  SA-8(23)  \nSC-8(1) \nSC-23(5)  \nEDSR -5 SC-13 \nEDSR -5.1 SC-13 \nEDSR -5.2 SC-13 \nEDSR -6 SC-13 \nEDSR -7 SC-13 \nEDSR -8 SC-13 \nSC-28(1)  \nEDSR -9 SC-28(1)  \nEDSR -10 SA-4(7) \nSC-13 \nSC-28(1)  \nEDSR -11 SC-12 \nSC-28(3)  \nEDSR -12 SR-3 \nSR-4(3) \nEDSR -13 SC-28(1)UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 380 of 397 \n RTB \nRequirement  NIST \nControl  \nEDSR -13.1  SC-28(1)  \nEDSR -13.2   SC-28(3)  \nEDSR -13.2.1  SC-28(3)  \nEDSR -14  IA-5  \nEDSR -15 IA-2(1) \nIA-2(2) \nEDSR -15.1  IA-2(6) \nEDSR -15.2  IA-5(2)  \nEDR-15.3  IA-5(2)  \nEDSR -15.4  IA-2(6) \nEDSR -15.5  IA-2(6) \nEDSR -16 AC-19(5)  \nSC-28 \nEDSR -16.1  AC-3(2) \nSA-8(15)  \nEDSR -17 SC-28 \nSIR-1 SI-7(9) \nSI-7(10)  \nSIR-1.1 SI-7(9) \nSI-7(10)  \nSIR-1.2 SI-7(9) \nSI-7(10)  \nSIR-1.3 SI-7(9) \nSI-7(10", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}769{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "768", "chunk": ")  \nSI-7(15)  \nSIR-1.4 SI-7(9) \nSI-7(10)  \nSI-7(15)  \nSIR-2 SA-8(21)  \nSI-7(9)  \nSI-7(10)  \nSIR-3 SA-10 \nSIR-3.1 SA-8(31)  \nSA-10 \nSIR-3.2 SA-10(6)  \nSR-4(3) RTB \nRequirement  NIST \nControl  \nSIR-3.2.1  RA-5 \nSIR-3.3  CM-2(2) \nCM-7(9) \nSA-10(3)  \nSI-7 \nSIR-3.3.1  CM-2(2) \nCM-7(9) \nSA-10(3)  \nSI-7 \nSIR-3.3.2  CM-2(2) \nCM-7(9) \nSA-10(3)  \nSI-7 \nSIR-3.3.3  CM-2(2) \nCM-7(9) \nSA-10(3)  \nSI-7 \nSIR-3.3.4  SI-7 \nSIR-3.3.5  CM-8(1) \nSIR-3.4  RA-5(11)  \nSIR-4 SI-7(17)  \nSIR-5 SI-7(17)  \nSIR-6 SC-3(1) \nSIR-7 SC-28(3)  \nSI-7 \nSIR-7.1 SC-13 \nSIR-7.2 SC-13 \nSIR-8 IA-3(4) \nSA-8(21)  \nSIR-9 SC-43  \nSIR-10 SI-7 \nSI-7(1) \nSIR-10.1  SI-7 \nSI-7(1) \nSIR-10.1.1  AC-3(3) \nSI-7 RTB \nRequirement  NIST \nControl  \nSIR-10.2  SI-7 \nSI-7(1) \nSIR-10.2.1  AC-3(3) \nAC-3(7) \nSIR-10.3  SI-7(1)  \nSIR-10.4  SI-7 \nSI-7(1) \nSIR-10.5  SI-7(1)  \nSIR-10.6  SA-8(24)  \nSI-7(5) \nSIR-10.7  SA-8(24)  \nSIR-10.8   \nCM-3(8) \nCM-5(5) \nSIR-10.9  SI-7 \nSIR-10.10  CM-3(8) \nSIR-10.10.1  CM-3(8) \nSIR-10.11  CM-3(8) \nSIR-11 CM-7(4) \nCM-7(5) \nSIR-11.1  CM-7(5) \nSIR-11.2  CM-7(5) \nSIR-11.3  CM-7(5) \nSIR-11.4  CM-7(5) \nSIR-11.5  CM-7(5) \nSIR-11.6  CM-7(5) \nSIR-12  SC-7(12)  \nSC-7(26)  \nSIR-13  SC-7(12)  \nSC-7(26)  \nSIR-14 AU-2 \nSI-4 \nSIR-15 SI-3 \nSIR-15.1  SI-3UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}770{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "769", "chunk": ", NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 381 of 397 \n RTB \nRequirement  NIST \nControl  \nSIR-15.2  SI-3 \nSIR-15.3  SI-3 \nSIR-16 AU-2 \nSI-4 \nSIR-17 AC-16 \nSIR-17.1  AC-3(3) \nAC-16 \nSIR-17.2  AC-3(3) \nAC-16 \nJALSR -1 CM-7 \nSA-8(14)  \nSC-3(2) \nJALSR -2 SC-3(2) \nJALSR -2.1 AU-6(1) \nJALSR -2.2 AU-6(1) \nCM-6 \nJALSR -2.3 AC-4(10)  \nCM-6 \nJALSR -2.4 CM-6 \nJALSR -2.5 AU-6(7) \nSI-4(2) \nSI-4(13)  \nJALSR -2.5.1  SA-8(24)  \nSI-4(7) \nJALSR -2.5.2  SA-8(24)  \nSI-4(7) \nJALSR -2.5.3  AC-4(31)  \nSA-8(24)  \nSI-4(7) \nJALSR -2.5.4  SA-8(24)  \nSI-4(7) \nJALSR -3 AC-6(1) \nJALSR -4 AU-12 \nJALSR -4.1 CM-6 \nJALSR -5 AC-4 \nPL-9 RTB \nRequirement  NIST \nControl  \nJALSR -6 AU-2 \nAU-3 \nAU-3(1) \nSA-8(22)  \nJALSR -7 AC-4(8) \nJALSR -7.1 AU-5(4) \nSA-8(24)  \nJALSR -8 AU-11 \nJALSR -9 AU-11 \nJALSR -9.1 AU-5 \nJALSR -10 AU-4(1) \nJALSR -11 AC-4(3) \nAU-5 \nJALSR -12   \nJALSR -13 AU-1 \nJALSR -14 AU-12(1)  \nJALSR -15 AU-4(1) \nAU-6(4) \nSC-37 \nJALSR -16 AU-4(1) \nSC-37 \nJALSR -17   \nJALSR -18 AU-4(1) \nAU-5 \nJALSR -19 AU-2 \nAU-12 \nJALSR -20 AC-4(26)  \nAU-2 \nAU-3(1) \nJALSR -21 AC-4(8) \nAC-4(31)  \nJALSR -22 AC-4(26)  \nAU-2 \nAU-3(1) \nJALSR -23 AU-5(4) RTB \nRequirement  NIST \nControl  \nJALSR -24 AU-5 \nAU-5(2) \nSI-4(5) \nJALSR -25 AU-4 ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}771{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "770", "chunk": "\nAU-11 \nJALSR -26 AU-12(2)  \nJALSR -26.1  AU-6(4) \nAU-12(2)  \nJALSR -26.2  AU-12(2)  \nJALSR -26.3  AU-12(2)  \nJALSR -27 AU-12(2)  \nJALSR -28 AU-12(2)  \nJALSR -29 AU-4(1) \nAU-6(4) \nJALSR -30 AU-6(4) \nJALSR -30.1  AU-3(1) \nCM-6 \nJALSR -30.2  AC-4 \nJALSR -30.3  AU-9 \nJALSR -31  AU-9 \nJALSR -31.1  AU-9 \nJALSR -32 AC-4 \nJALSR -33 AU-2 \nJALSR -34 AU-2 \nJALSR -34.1  SA-4(2) \nJALSR -35 AU-2 \nSA-4(2) \nJALSR -36 AU-5 \nJALSR -37 AU-5 \nJALSR -38 SI-7(9) \nJALSR -39 SA-4(2) \nSA-5UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 382 of 397 \n RTB \nRequirement  NIST \nControl  \nJALSR -40 AU-4(1) \nAU-6(4) \nSC-37 \nJALSR -41 AU-4(1) \nAU-6(8) \nSC-37 \nJALSR -42 AU-3(1) \nAU-6(4) \nJALSR -43 AU-6(1) \nAU-12 \nJALSR -44 AU-6(1) \nAU-12(1)  \nRMONR -1 AU-4(1) \nRMONR -2 AU-4(1) \nAU-12(2)  \nRMONR -3 AU-12(2)  \nRMONR -3.1 AU-12(2)  \nRMONR -3.2 AU-12(2)  \nRMONR -3.3 AU-12(2)  \nRMONR -3.4 AU-12(2)  \nRMONR -3.5 AU-12(2)  \nRMONR -4 CM-7 \nSA-4(9) \nRMONR -4.1 CM-7 \nSA-4(9) \nRMONR -5 CM-7 \nSA-4(9) \nRMONR -5.1 CM-7 \nSA-4(9) \nRMONR -6 AU-1 \nRMONR -7 CM-7 \nSA-4(9) \nSI-4 \nRMONR -7.1 SA-4(9) \nSC-7(4) \nRMONR -7.2 AC-4 RTB \nRequirement  NIST \nControl  \nRMONR -", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}772{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "771", "chunk": "8 SC-7(4) \nRMONR -8.1 SC-7(4) \nRMONR -9 CM-7 \nSA-4(9) \nRMONR -10  SA-8(18)  \nRMONR -10.1  AC-6 \nRMONR -11 AU-4(1) \nRMANR -1 AC-17(3)  \nAC-17(4)  \nRMANR -1.1  AC-17(3)  \nAC-17(4)  \nRMANR -2 AC-17  \nSC-39 \nRMANR -2.1 AC-17  \nSC-39 \nRMANR -2.2 AC-17(4)  \nCM-7 \nRMANR -2.3 AC-4(12)  \nSI-7(17)  \nRMANR -2.4 AC-4(12)  \nSI-4(4) \nSI-15 \nRMANR -2.5 IA-2(1) \n IA-2(6) \nRMANR -2.5.1  IA-5(2) \nRMANR -2.6 AC-17(2)  \nRMANR -2.7 MP-7 \nSC-41 \nRMANR -2.8 CM-7 \nRMANR -2.9 AC-4(28)  \nRMANR -3 AC-17 \nCM-7  \nSA-4(9) \nRMANR -3.1 AC-17(1)  \nAC-17(4)  RTB \nRequirement  NIST \nControl  \nRMANR -3.2 AC-17 \nCM-7  \nSA-4(9) \nRMANR -3.3 AC-6  \nAC-17 \nSC-43 \nRMANR -3.4 SC-43 \nRMANR -3.5 AC-6 \nRMANR -3.6 IA-2(1) \nRMANR -4 IA-5(2) \nRMANR -5 IA-5(2) \nSC-17 \nRMANR -6 AC-3(8) \nIA-5(2) \nSC-17 \nRMANR -6.1 AC-4 \nCM-7 \nRMANR -6.2 AC-4 \nCM-7 \nRMANR -7 CM-6 \nCM-7 \nRMANR -8 CM-6 \nCM-7 \nRMANR -9 AC-17 \nAC-17(2)  \nRMANR -10 AC-17   \nSC-41 \nRMANR -10.1  SC-41 \nRMANR -10.2  SC-41 \nRMANR -10.3  IA-5(1) \nRMANR -\n10.3.1  IA-5(5) \nRMANR -\n10.3.2  IA-5(5) \nRMANR -10.4  SC-41 \nRMANR -11 SA-4(9)UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 383 of 397 \n RTB \nRequirem", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}773{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "772", "chunk": "ent  NIST \nControl  \nPAR-1 SC-7(21)  \nPAR-2 SC-46 \nSC-50 \nPAR-3 CM-7 \nPAR-4 CM-7 \nPAR-5 AC-3(15)  \nSA-8(6) \nPAR-6 SA-8(18)  \nPAR-7 SC-43 \nPAR-8 SC-7(5) \nPAR-9 SC-3(2) \nPAR-9.1 SA-15(5)  \nPAR-10 SC-7(17)  \nPAR-11 AC-4(21)  \nSA-8(18)  \nSA-17(9)  \nDRR -1 AC-4(2) \nAC-4(32)  \nDRR -2 AC-4(32)  \nDRR -3 AC-4(19)  \nAC-4(32)  \nDRR -4 AC-4(19)  \nDRR -5 AC-4(8) \nDRR -6 AC-3(15)  \nSA-8(6) \nDRR -7 AU-2 \nSA-8(24)  \nDRR -8 SA-8(24)  \nSC-24 \nDRR -9  AC-4(19)  \nFRVR -1 SC-3(5) \nSC-39 \nFRVR -2 AC-4(8) \nFRVR -3 AC-4(8) RTB \nRequirement  NIST \nControl  \nFRVR -4 SI-7 \nSI-15 \nFRVR -5 AC-16(8)  \nAU-10(2)  \nFRVR -6 SI-15 \nFRVR -7 AU-2 \nSA-8(24)  \nFRVR -8 AC-3(15)  \nSA-8(6) \nFRVR -9 AC-4(27)  \nSA-17(9)  \nFRVR -9.1  AC-4(14)  \nAC-4(19)  \nFRVR -10 AC-4(15)  \nAC-4(31)  \nFRVR -11 AU-2 \nFRVR -12 AC-4(8) \nJSR-1 AC-4(12)  \nAC-4(19)  \nAC-4(29)  \nJSR-2 AC-4(1) \nJSR-3 AC-4 \nAC-4(29)   \nJSR-4 AC-4(21)  \nSA-8(18)  \nJSR-5 AC-3(15)  \nSA-8(6) \nJSR-6 SA-8(24)  \nSC-24 \nRPR-1 AC-4(29)   \nRPR-2 SI-15 \nRPR-3 AC-4(29)  \nSI-15 \nRPR-4 No \nmapping   \nRPR-5 AC-16(8)  RTB \nRequirement  NIST \nControl  \nRPR-6 AC-4(8) \nAC-4(29)  \nRPR-7 AC-4(29)   \nRPR-8 AC-4(15)  \nAC-4(29)  \n AC-4(31)  \nRPR-9 AC-4(8) \nSA-8(18)  \nRPR-10 AC-3(15)  \nSA-8(6) \nRPR-11 SA-8(24)  \nSC-24 \nRPR-12 AC-4(8) \nTPR-1 PE-3(5) \nSR-9 \nTPR-2 SC-41 \nTPR-3 PE-3(5) \nSR-9 \n", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}774{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "773", "chunk": "TPR-4 PE-3(5) \nSR-4(2) \nSR-9 \nTPR-5 PE-3(5) \nSA-10(6)  \nSR-9 \nTPR-6   \nTPR-7   \nTPR-8 SR-7 \nTPR-9 SR-7 \nTPR-10 SR-4(3) \nSR-7 \nSR-10  \nTPR-11 SA-4(3) \nSR-9 \nSR-10 \nTPR-12 IA-3(1) \nTPR-13 PE-3(5) \nSR-9UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 384 of 397 \n RTB \nRequirement  NIST \nControl  \nTPR-13.1  PE-3(5) \nSR-9 \nTPR-13.2  PE-3(5) \nSR-9 \nTPR-13.3  PE-3(5) \nSR-9 \nTPR-13.4  SR-9 \nTPR-13.5  SR-9 \nTPR-13.6  SR-9 \nTPR-13.7  PE-3(5) \nSR-9 \nTPR-13.8  SA-8 \nSR-9(1) \nSC-1 SR-1 \nSR-4(1) \nSR-4(4) \nSC-2 SR-2 \nSC-3 RA-3(1) \nSR-3 \nSR-6 \nSC-4 SR-2 \nSC-4.1 SR-2 \nSC-5  SR-4(3) \n SR-11 \nSC-6  SR-3 \nSC-7 SR-5 \n SR-11(1)  \nSC-8 SR-3(3) \n SR-8 \nSC-9 SR-6 \nSC-10 SR-4(3) \nSR-4(4) \nSR-5(2) \nSR-6(1) \nSR-11 \nSC-11 SR-4(4) \nSR-5 RTB \nRequirement  NIST \nControl  \nSC-11.1  SR-4(3) \nSR-11 \nSC-12 SR-5 \nSC-13 SR-5 \nDCOR -1 AU-4(1) \nAU-6(4) \nAU-9(2) \nDCOR -2   \nDCOR -3   \nDCOR -4 AU-4(1) \nAU-9(2) \nDCOR -5   \nDCOR -6  CM-8 \nDCOR -6.1  CM-8 \nDCOR -6.2  CM-8 \nDCOR -7 SC-37 \nGDFR -1 AC-4(8) \nGDFR -2 AC-4 \nSA-8(5) \nSC-6 \nGDFR -3 AC-4 \nGDFR -4 AC-4(26)  \nGDFR -4.1  AC-4(26)  \nGDFR -5 AC-4(26)  \nGDFR -5.1 AC-4(26)  \nGDFR -6 AC-4(8) \nAC-16(8)  \nG", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}775{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "774", "chunk": "DFR -6.1 AC-4(26)  \nGDFR -6.2 AC-4(26)  \nGDFR -6.3 AC-16(8)  \nGDFR -6.4 AC-16(8)  \nGDFR -6.5 AC-16(8)  \nGDFR -6.6 AC-4(26)  RTB \nRequirement  NIST \nControl  \nGDFR -6.6.1  AC-4(26)  \nGDFR -6.6.2  AC-16(8)  \nGDFR -6.6.3  AC-4(26)  \nGDFR -6.6.4  AC-4(26)  \nGDFR -6.6.5  AC-4(26)  \nGDFR -6.6.6  AC-4(26)  \nGDFR -6.6.7  AC-4(26)  \nGDFR -6.6.8  AC-4(26)  \nGDFR -6.6.9  AC-4(26)  \nGDFR -6.7 AC-4(26)  \nAC-4(29)  \nAC-16(8)  \nGDFR -7 AC-16(8)  \nGDFR -7.1 AC-16(8)  \nGDFR -7.2 CM-14 \nSI-7(15)  \nGDFR -7.3 IA-5 \nSC-12 \nGDFR -8 AC-4(12)  \nGDFR -9 AC-4(8) \nAC-21(1)  \nSC-7(10)  \nGDFR -10 AC-4(14)  \nGDFR -11 AC-3(15)  \nSA-8(6) \nSC-39 \nGDFR -12 AC-4(28)  \nAC-21(1)  \nGDFR -13 AC-4(32)  \nGDFR -14 AC-4(10)  \nGDFR -14.1  SC-8 \nSI-3 \nGDFR -15 AC-4(8) \nGDFR -16 AC-4(8)UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 385 of 397 \n RTB \nRequirement  NIST \nControl  \nGDFR -17 AC-4(8) \nAC-4(31)  \nGDFR -17.1  AC-4 \nGDFR -18 SC-8 \nSI-3 \nGDFR -19 SI-17 \nGDFR -19.1  SI-17 \nGDFR -19.2  SI-17 \nGDFR -19.3  SI-17 \nGDFR -19.4  SI-17 \nGDFR -19.5  SI-17 \nGDFR -20 AC-4 \nGDFR -21 SI-17 \nGDFR -21.1  SI-17 \nGDFR -21.2  SI-17 \nGDFR -22 SI-17 \nGDFR -23 AC-4(12)", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}776{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "775", "chunk": "  \nAC-4(21)  \nSA-8(14)  \nGDFR -24 AC-4(8) \nAC-4(14)  \nGDFR -24.1  AC-4(8) \nAC-4(14)  \nGDFR -24.2  AC-4(8) \nAC-4(14)  \nGDFR -24.3  AC-4(8) \nAC-4(14)  \nGFDR -24.4  AC-4(8) \nGDFR -24.5  AC-4(8) \nGDFR -25 AC-4(4) \nGDFR -25.1  AC-4(4) \nGDFR -25.2  AC-4(4) \nGDFR -26 AC-4(21)  \nGDFR -27 AC-4(14)  RTB \nRequirement  NIST \nControl  \nGDFR -27.1  AC-4(14)  \nGDFR -28 AC-4(19)  \nAC-4(24)  \nGDFR -29 AC-4(14)  \nGDFR -30 SA-17(5)  \nGDFR -30.1  AC-4(27)  \nGDFR -30.2  AC-4(30)  \nSC-39 \nGDFR -30.3  AC-4(30)  \nSC-39 \nGDFR -31 AC-4(8) \nSA-8(23)  \nGDFR -32 SA-8(24)  \nSI-17 \nGDFR -32.1  AU-2 \nGDFR -33 AC-4 \nGDFR -34 IA-4 \nGDFR -35 IA-4 \nGDFR -35.1  AC-4(11)  \nGDFR -35.2  AC-4(11)  \nGDFR -36 AC-4(8) \nAC-4(19)  \nSI-7(1) \nGDFR -37 AC-3(2) \nAC-4(11)  \nGDFR -38 AC-4(23)  \nAC-4(26)  \nSI-4(5) \nGDFR -38.1  AC-4(11)  \nGDFR -38.2  AC-3(7) \nGDFR -38.3  AC-3(3) \nAC-16(9)  \nGDFR -38.4  AC-4(11)  \nAC-4(23)  \nAC-4(26)  RTB \nRequirement  NIST \nControl  \nGDFR -38.4.1  AC-4(23)  \nAC-4(26)  \nGDFR -38.4.2  AC-4(23)  \nAC-4(26)  \nGDFR -38.4.3  AC-4(11)  \nCM-6 \nGDFR -38.4.4  AC-4(11)  \nCM-6 \nGDFR -38.5  SI-4(5) \nGDFR -38.6  SI-4(5) \nGDFR -39 AC-4(27)  \nPL-8(2) \nSA-17(9)  \nGDFR -40 SR-2 \nSR-5 \nGDFR -41 SC-7(4) \nGDFR -42 AC-4(24)  \nGDFR -43 AC-4(27)  \nAC-4(30)  \nGDFR -44 AU-3(1) \nGDFR -45 SA-15(5)  \nGDFR -45.1  SA-15(5)  \nGDFR ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}777{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "776", "chunk": "-47 SI-7(1) \nGDFR -48 AC-3(3) \nGDFR -49 AC-3 \nGXFFPR -1 AC-4(12)  \nAC-4(14)  \nGXFFPR -2 AC-4(8) \nAC-4(23)  \n AC-4(25)  \nGXFFPR -2.1 AC-4(24)  \nGXFFPR -2.2 AC-4(14)  \nGXFFPR -2.3 AC-4(14)  \nSC-7(10)  \nGXFFPR -2.4 AC-4(8)UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 386 of 397 \n RTB \nRequirement  NIST \nControl  \nGXFFPR -2.5 AC-4(14)  \nGXFFPR -3  AC-4(12)  \nAC-4(14)  \nGXFFPR -4 AC-4(12)  \nAC-4(14)  \nAC-4(23)  \n AC-4(25)  \nGXFFPR -5 AC-4(24)  \nGXFFPR -6 AC-4(24)  \nGXFFPR -7 SA-17 \nGXFFPR -7.1 SA-17 \nGXFFPR -8 AC-4(27)  \nAC-4(30)  \nSA-17(9)  \nGXFFPR -9 AC-4(14)  \nAC-4(23)  \n AC-4(25)  \nGXFFPR -10 AC-4(8) \nAC-4(27)   \nGXFFPR -11 AC-4(14)  \nAC-4(24)  \nGXFFPR -12 SA-15 \nGXFFPR -12.1  SA-15 \nGXFFPR -12.2  SA-15 \nGXFFPR -12.3  SA-15 \nGXFFPR -12.4  SA-15 \nGXFFPR -12.5  SA-15 \nGXFFPR -12.6  SA-15 \nGXFFPR -12.7  SA-15 \nGXFFPR -12.8  SA-15 \nGXFFPR -12.9  SA-15 \nGXFFPR -\n12.10  SA-15 \nGXFFPR -\n12.11  SA-15 RTB \nRequirement  NIST \nControl  \nGXFFPR -\n12.12  SA-15 \nGXFFPR -\n12.13  SA-15 \nGXFFPR -\n12.14  SA-15 \nGXFFPR -\n12.15  AC-16(8)  \nSI-7(6) \nSI-7(15)  \nMMFFR -1 AC-4(12)  \nMMFFR -1.1   \nMMFFR -2 SA-4(9) \nMMFFR -2.1 SA-4(9)", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}778{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "777", "chunk": " \nMMFFR -3 AC-4(12)  \nMMFFR -3.1   \nMMFFR -4 AC-4(12)  \nMMFFR -4.1   \nMMFFR -5 AC-4(14)  \nMMFFR -6 AC-4(14)  \nMMFFR -7 AC-4(14)  \nMMFFR -8 AC-4(14)  \nMMFFR -9 AC-4(14)  \nMMFFR -10 AC-4(14)  \nMMFFR -11 AC-4(14)  \nMMFFR -11.1  AC-4(14)  \nMMFFR -11.2  AC-4(14)  \nMMFFR -\n11.2.1  AC-4(14)  \nMMFFR -\n11.2.2  AC-4(14)  \nMMFFR -12 AC-4(23)  \n AC-4(25)  \nMMFFR -12.1  AC-4(14)  \nMMFFR -13 AC-4(14)  RTB \nRequirement  NIST \nControl  \nMMFFR -14 AC-4(14)  \nMMFFR -15 AC-4 \nAC-4(12)  \nMPCR -1  SA-17 \nMPCR -2  CM-11 \nCM-14 \nMPCR -2.1  CM-11 \n SA-17(8)  \nMPCR -2.2 CM-11 \nMPCR -3  AC-3(3) \nMPCR -4  SA-8(3) \nSA-8(6) \nSC-39 \nSC-39(2)  \nMPCR -5  CM-11 \nMPCR -6  SA-8(3) \nMPCR -7  SA-8(17)  \nSA-8(18)  \nMPCR -7.1  SA-8(18)  \nMPCR -7.2  SA-8(3) \nSC-39 \nMPCR -8  SA-15 \nSC-43 \nMPCR -9  SA-15(5)  \nSA-17 \nMPCR -10  SC-39  \nMPCR -11  SA-17(6)  \nMPCR -12  SA-17(6)  \nMPCR -13  CM-6 \nMPCR -14  SI-4(5) \nSI-11 \nSI-17 \nMPCR -15  SC-45 \nSC-45(1)  \nMPCR -16  CM-7 \nSA-8(5)UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 387 of 397 \n RTB \nRequirement  NIST \nControl  \nMPCR -16.1  SA-17(7)  \nSC-39 \nMPCR -17 SA-8(5)  \nSC-6 \nMPCR -18    \nMPCR -19    \nMPCR ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}779{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "778", "chunk": "-20 AC-3(15)  \nSA-8(3) \nMPCR -21  CM-7 \nMPCR -22 SA-8(18)  \nSC-7(21)  \nMPCR -22.1  SA-17(7)  \nSC-39 \nMPCR -23  SI-7 \nMPCR -24 AC-3(3) \nMPCR -25  SA-8(3) \nMPCR -25.1    \nMPCR -25.2  CM-7 \nSA-15(5)  \nMPCR -26  CM-7 \nSA-15(5)  \nMPCR -27  SI-14 \nMPCR -28 SA-15 \nSC-43 \nMPCR -29  SA-8(18)  \nMPCR -30 SA-17 \nMPCR -31 SA-17 \nMPCR -32 AC-6 \nSA-17(7)  \nMPCR -33 IA-4 \nMPCR -33.1  SA-17 \nMPCR -33.2  SA-17 \nMPCR -33.3  SA-17 \nMPCR -34 SA-17 RTB \nRequirement  NIST \nControl  \nMPCR -35 SA-15(5)  \nSA-17 \nMPCR -35.1  SA-8(8) \nMPCR -36 CM-9 \nSA-8(8) \nMPCR -37 SA-17 \nSR-5(2) \nMPCR -38 AC-3(7) \nCM-3(8) \nCM-11 \nMPCR -39 AC-3(7) \nCM-3(8) \nCM-11 \nMPCR -40 CA-9  \nMPCR -41 AU-2 \nMPCR -42 AC-3(7) \nCM-3(8) \nCM-11 \nMPCR -43 CM-3(8) \nCDMPCR -1 CA-9 \nSA-17 \nCDMPCR -2 CA-9 \nSA-8 \nCDMPCR -3 AC-4(27)  \nPL-8(2) \nSA-17(9)  \nCDMPCR -3.1 PL-8(2) \nSA-11 \nSA-17(9)  \nCDMPCR -4 SA-8 \nCDMPCR -5 SA-8 \nCDMPCR -6 SI-7(15)  \nCDMPCR -6.1 SI-7(15)  \nCDMPCR -6.2 SC-43 \nSI-7(15)  \nCDMPCR -7 SA-8 RTB \nRequirement  NIST \nControl  \nCDMPCR -8 SA-8 \nCDMPCR -9 SA-8 \nCDMPCR -10 SA-8 \nCDMPCR -11 SA-8 \nCDMPCR -\n11.1  SA-8 \nCDMPCR -12 AC-6 \nCDMPCR -13 AC-6 \nCDMPCR -14 AC-3(3) \nCDMPCR -\n14.1  AC-3(3) \nCDMPCR -15 SA-15 \nCDMPCR -\n15.1  SA-15 \nCDMPCR -16 SA-11 \nSA-15 \nSA-17(6)  \nCDMPCR -\n16.1  SA-17(6)  \nCDMPCR -\n16.2  SA-11 \nSA-17(6)  \nCDMPCR ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}780{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "779", "chunk": "-\n16.3  SI-7(15)  \nCDMPCR -\n16.4  SA-17(6)  \nCDMPCR -17 SI-7(15)  \nCDMPCR -18 SI-7(15)  \nVIRT -1 SI-7(9) \nVIRT -2 SI-7(10)  \nVIRT -3 SA-4(7) \nVIRT -4 SC-2 \nVIRT -4.1 AC-17  \nVIRT -4.2 SA-4(9) \nSC-13UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 388 of 397 \n RTB \nRequirement  NIST \nControl  \nVIRT -4.3 AU-2 \nAU-4(1) \nVIRT -4.4 SC-7(13)  \nVIRT -4.5   \nVIRT -4.6 SC-3 \nVIRT -4.7 AC-3(7) \nVIRT -4.8 AC-3(2) \nVIRT -5 SA-15(5)  \nVIRT -5.1 AC-6(4) \nVIRT -6 SA-15(5)  \nVIRT -7 SA-15(5)  \nVIRT -7.1 SC-3 \nVIRT -8 SA-15(5)  \nSC-3 \nVIRT -8.1 SC-3(1) \nVIRT -8.2  SC-3 \nVIRT -8.3 PL-8 \nSC-32 \nVIRT -9 CM-7(9) \nVIRT -10 CM-7(9) \nVIRT -10.1  SA-15(5)  \nVIRT -11 SC-7 \nVIRT -11.1  SC-7 \nVIRT -11.2    \nVIRT -11.3  SC-7(21)  \nVIRT -11.3.1  SC-7(21)  \nVIRT -11.4  SI-4(1) \nVIRT -11.5  AC-4(21)  \nSA-4(6) \nSC-13 \nVIRT -12 CA-9 \nMP-7 \nVIRT -12.1  SA-15(5)  RTB \nRequirement  NIST \nControl  \nVIRT -12.2  SA-8(6) \nSC-28(1)  \nVIRT -12.3  SA-15(5)  \nVIRT -12.4  SC-2 \nVIRT -12.5  SC-28(1)  \nVIRT -12.6  SA-4 \nVIRT -13 SI-13 \nSI-13(5)  \nVIRT -14 SI-13 \nSI-13(5)  \nVIRT -15 CM-3 \nCP-9 \nVIRT -16 CP-10(2)  \nVIRT -17 CM-3 \nVIRT -18 CM-3 \nVIRT -18.1  CM-", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}781{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "780", "chunk": "3 \nVIRT -18.2  CM-6 \nVIRT -18.3  CM-6 \nVIRT -19 SI-4 \nVIRT -19.1  SC-39 \nSI-4 \nVIRT -19.2  SC-39 \nSI-4 \nVIRT -19.3  SC-13 \nSC-39(1)  \nVIRT -19.4    \nVIRT -20 IA-3(3)  \nVIRT -20.1  SC-2 \nSC-39 \nVIRT -21 SC-3 \nSC-39 \nVIRT -21.1  SC-3 \nSC-39 \nVIRT -22 AC-3(3) RTB \nRequirement  NIST \nControl  \nVIRT -23 AC-3(3) \nVIRT -24 AC-4 \nVIRT -25 SA-8(23)  \nVIRT -26 SA-8(21)  \nSI-7(9) \nSI-7(10)  \nVIRT -27 IA-3 \nVIRT -28 SA-8(21)  \nSC-28(3)  \nSI-7(10)  \nVIRT -29 IA-3 \nIA-4 \nVIRT -30 AC-3 \nSC-39 \nVIRT -31 SC-4 \nSK-1 SA-8(5) \nSC-4 \nSK-1.1 SC-32 \nSK-2 SC-3 \nSC-32 \nSK-3 SA-17 \nSK-4 SA-8(18)  \nSK-5 SI-16 \nMLS -1 AC-3(3) \nAC-16(3)  \nMLS -2 AC-3(3) \nAC-17  \nMLS -3 AC-3(3) \nMLS -4 AC-4(32)  \nAC-16(2)  \nAC-16(4)  \nAC-16(9)  \nMLS -5 AC-4(32)  \nAC-16(9)  \nMLS -5.1 AC-4 \nAC-4(32)UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 389 of 397 \n RTB \nRequirement  NIST \nControl  \nMLS -6 AC-4(20)  \nAC-16(9)  \nMLS -7 AC-4(20)  \nSA-17 \nMLS -8 AC-3(3) \nAC-16(9)  \nMLS -9 AC-3(3) \nMLS -10 SC-7(21)  \nMLS -11 AC-3(3) \nMLS -11.1  AC-3(3) \nSC-16 \nMLS -11.2  AC-3(3) \nAU-2 \nMLS -11.3  AC-3(3) \nAU-2 \nMLS -12 SC-16 \nMLS -12.1  SC-16 \n DCFFTSB -\nADPR -1 AC-4(28", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}782{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "781", "chunk": ")  \nSA-17 \n DCFFTSB -\nADPR -2 AC-4(28)  \nSA-17 \nDCFFCOTS -P-\n1 AC-4(28)  \nSA-17 \nDCFFCOTS -P-\n2 AC-4(28)  \nSA-17 \nDCFFCOTS -R-\n1 AC-4(7) \nAC-4(30)  \nSA-17(9)  \nDCFFCOTS -R-\n1.1 AC-4(27)  \nAC-4(28)  \nDCFFCOTS -R-\n1.2 AC-4(27)  \nSA-17(9)  \nDCFFCOTS -R-\n1.3 SA-17(9)  RTB \nRequirement  NIST \nControl  \nDCFFCOTS -R-\n2 AC-4(7) \nAC-4(27)  \nSA-17(8)  \nSA-17(9)  \nDCFFCOTS -R-\n3 SA-23 \nDCFFCOTS -R-\n4 AC-4(14)  \nDCFFCOTS -R-\n5 AC-6(4) \nSC-32(1)  \nDCFFCOTS -R-\n6 N/A \nDCFFCOTS -R-\n6.1 SC-39 \n SC-39(1)  \nDCFFCOTS -R-\n6.2 SC-8 \nDCFFCOTS -R-\n6.3 SC-7(5) \nSC-23(5)  \nDCFFCOTS -R-\n6.4 SC-23 \nDCFFCOTS -R-\n6.5 SC-7(17)  \nSI-10(5)  \nDCFFCOTS -R-\n6.6 AC-4(6) \nAC-4(7) \nDCFFCOTS -R-\n6.7 SA-17 \nDCFFCOTS -R-\n6.8 SA-17 \nDCFFCOTS -R-\n6.9 IA-2(1) \nDCFFCOTS -R-\n6.10  IA-2(1) \nDCFFCOTS -R-\n6.11  AU-4 \nDCFFCOTS -R-\n6.12  AU-11 \nDCFFCOTS -R-\n7 N/A RTB \nRequirement  NIST \nControl  \nDCFFCOTS -R-\n7.1 SA-17 \nDCFFCOTS -R-\n7.2 AC-4(14)  \nSA-17 \nDCFFCOTS -R-\n7.3 AU-4 \nDCFFCOTS -R-\n7.4   \nDCFFCOTS -R-\n7.5 AU-11 \nDCFFCOTS -R-\n7.6 AU-11 \nDCFFCOTS -R-\n7.7 IA-2(1) \nDCFFCOTS -R-\n7.8 IA-2(1) \nDCFFCOTS -R-\n8 N/A \nDCFFCOTS -R-\n8.1 SA-17(9)  \nDCFFCOTS -R-\n8.2 IA-2(1) \nDCFFCOTS -R-\n8.3 IA-2(1) \nDCFFCOTS -R-\n8.4 IA-2(1) \nDCFFCOTS -R-\n8.5 IA-2(1) \nDCFFCOTS -R-\n8.6 AC-4(30)  \nSA-17(9)  \nDCFFCOTS -R-\n8.7 AC-4(14)  \nDCFFCOTS -R-\n8.8 AC-", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}783{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "782", "chunk": "4(15)  \nDCFFCOTS -R-\n8.9 AC-4(14)UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 390 of 397 \n RTB \nRequirement  NIST \nControl  \nDCFFCOTS -R-\n8.10  AC-4(15)  \nAC-4(31)  \nDCFFCOTS -R-\n8.11  AC-4(14)  \nDCFFCOTS -R-\n8.12  AC-4(15)  \nAC-4(31)  \nDCFFCOTS -R-\n8.13  AC-4(8) \nDCFFCOTS -R-\n8.14  AU-4 \nDCFFCOTS -R-\n8.15  AC-4(14)  \nAC-4(15)  \nDCFFCOTS -R-\n8.16  SA-17 \nDCFFCOTS -R-\n9 N/A \nDCFFCOTS -R-\n9.1 SA-17 \nDCFFCOTS -R-\n9.2 SA-17 \nDCFFCOTS -R-\n9.3 SA-17 \nDCFFCOTS -R-\n9.4 SA-17 \nDCFFCOTS -R-\n9.5 SA-17(9)  \nDCFFCOTS -R-\n9.6 SA-17(9)  \nDCFFCOTS -R-\n9.7   \nDCFFCOTS -R-\n9.8 CM-7 \nDCFFCOTS -R-\n9.9 SC-23 \nDCFFCOTS -R-\n9.10  SC-39 RTB \nRequirement  NIST \nControl  \nDCFFCOTS -R-\n9.11  AU-11 \nDCFFCOTS -R-\n9.12  AU-11 \nDCFFCOTS -R-\n9.13  AU-4 \nDCFFCOTS -R-\n9.14  AC-4(24)  \nDCFFCOTS -R-\n9.15  AC-4(24)  \nDCFFCOTS -R-\n9.16  SC-7(17)  \nDCFFCOTS -R-\n9.17  SA-17 \nDCFFCOTS -R-\n9.18  IA-2(1) \nDCFFCOTS -R-\n9.19  IA-2(1) \nDCFFCOTS -R-\n10 AU-4(1) \nDCFFCOTS -R-\n11 AC-4(7) \nDCFFCOTS -R-\n12 AC-4(7) \nSA-17 \nDCCDTSB -P-1  AC-4(5) \nSA-17 \nDCCDTSB -P-2 AC-4(28)  \nSA-17 \nDCCDTSB -R-1  SA-8(6) \nSA-17 \nDCCDTSB -R-2  AC-3(9) \nAC-4 \nAC-21(1)  \n SA-17 ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}784{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "783", "chunk": "\nTHA -R-1   \nTHA -R-1.1   \nTHA -R-1.2   RTB \nRequirement  NIST \nControl  \nTHA -R-1.3   \nTHA -R-1.4     \nTHA -R-2   \nTHA -R-2.1   \nTHA -R-3   \nTHA -R-3.1   \nTHA -R-4   \nTHA -R-4.1   \nTHA -R-4.2   \nTHA -R-4.3   \nTHA -R-4.4    \nTHA -R-5    \nHWR -1   \nHWR -2   \nHWR -4   \nHWR -4.1   \nHWR -5   \nHWR -6   \nHWR -7   \nHWR -8   \nHWR -9   \nHWR -10    \nHWR -10.1    \nHWR -11    \nHWR -11.2    \nHWR -11.3    \nHWR -12    \nHWR -13    \nHWR -14    \nHWR -15   \nHWR -15.1UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 391 of 397 \n RTB \nRequirement  NIST \nControl  \nHWR -15.2    \nCUCR -1 SC-7(25)  \nCUCR -2 SA-17(9)  \nSC-7(25)  \nCUCR -3 SC-7(25)  \nCUCR -3.1 AC-4(27)  \nSC-49 \nCUCR -3.2 AC-4(27)  \nSC-49 \nCUCR -3.3 SC-7(25)  \nSC-49 \nCUCR -4 SA-17(9)  \nSC-7(25)  \nCUCR -4.1 AC-4(7) \nSC-49 \nCUCR -5 SA-15(5)  \nSC-10 \nVTR-1 SA-11 \nSI-4(9) \nVTR-2 SA-11(5)  \nVTR-3 SA-11 \nVTR-4 SA-11(3)  \nVTR-5 SA-11(7)  \nVTR-5.1 SA-11(7)  \nMSCT -1   \nMSCT -2   \nMSCT -3   \nLBSAR -1 SA-5 \nLBSAR -2   \nLBSAR -3 SA-11(1)  \nLBSAR -4 SA-16 \nLBSAR -5 CA-2 \nLBSAR -6  SA-17(6)  \nLBSAR -7 SA-17(6)  RTB \nRequirement  NIST \nControl  \nLBSAR -7.1   SA-17(6)  \nLBSAR -7.2 SA-17(6", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}785{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "784", "chunk": ")  \nLBSAR -7.3 SA-17(6)  \nLBSAR -8 SA-11 \nSBSAR -1 SA-11 \nSBSAR -2 SA-11 \nSBSAR -3 SA-11 \nSBSAR -3.1 SA-11 \nSBSAR -4 SA-11 \nMLDBR -1  SA-8 \nMLDBR -2 AC-16(8)  \nMLDBR -2.1 AC-16(1)  \nMLDBR -2.2 AC-3(3) \nAC-16 \nMLDBR -3  CA-9 \nMLDBR -3.1  AC-4 \nMLDBR -3.2 SC-7(17)  \nMLDBR -3.3  AC-4 \nMLDBR -3.4 AC-3(7) \nMLDBR -3.5  AC-4(4) \nMLDBR -3.6  AC-4(13)  \nAC-4(25)  \nMLDBR -3.7  AC-4(27)  \nSC-3(4) \nMLDBR -4  AC-3(3) \nAC-3(7) \nMLDBR -4.1  AC-3(3) \nAC-3(7) \nMLDBR -4.2 AC-16 \nMLDBR -4.2.1  AC-16 \nMLDBR -4.2.2  AC-6 \nMLDBR -4.3 AC-3(3) \nAC-3(11)  RTB \nRequirement  NIST \nControl  \nMLDBR -5  AC-3(3) \nAC-16 \nMLDBR -5.1  SC-7(17)  \nSC-8 \nMLDBR -6  N/A \nMLDBR -6.1  AC-6 \nMLDBR -6.2  SC-3 \nMLDBR -6.3  SC-3 \nMLDBR -6.3.1  SC-3 \nMLDBR -6.3.2  SC-7(15)  \nMLDBR -7 AC-3(3) \nAC-3(11)  \nMLDBR -7.1  N/A \nMLDBR -7.1.1  AC-3(3) \nAC-4 \nMLDBR -7.1.2  AC-3(3) \nMLDBR -7.1.3  AC-3(3) \nAC-4(17)  \nMLDBR -7.1.4  AC-3(3) \nAC-4(8) \nMLDBR -7.2  AC-3(3) \nMLDBR -8   AC-4 \nAC-4(20)  \nAC-16(9)  \nMLDBR -9 AC-3(3) \nMLDBR -9.1  AC-3(3) \nMLDBR -10  AC-3(3) \nAC-16(9)  \nMLDBR -10.1  AC-4 \nMLDBR -10.2  SA-11 \nSA-11(7)  \nMLDBR -10.3  AU-2 \nMLDBR -11  AC-3(3) \nAC-16 \nMLDBR -12  SC-7(21)UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL T", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}786{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "785", "chunk": "O USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 392 of 397 \n RTB \nRequirement  NIST \nControl  \nMLDBR -13  SA-4(5) \nMLDBR -14  SC-8 \nMLDBR -15  AU-2 \nAU-9 \nAU-11 \nMLDBR -16  AC-4(8) \nAC-4(19)  \nMLDBR -17  AC-2(11)  \nAC-3(7) \nMLDBR -18  AU-2 \nMLDBR -19  AC-3(2) \nSA-8(15)  \nMLDBR -20  AC-3(7) \nMLDBR -20.1  AC-3(7) \nAC-5 \nMLDBR -20.2  AC-3(2) \nSA-8(15)  \nMLDBR -21  AC-3(7) \nAC-5 \nMLDBR -21.1  AC-3(2) \nSA-8(15)  \nMLDBR -22   SC-32 \nMLDBR -23  SC-32 \nMLSWNR -1  AC-4 \nAC-16 \nMLSWNR -1.1 AC-4 \nMLSWNR -1.2  AC-4 \nAC-16 \nMLSWNR -2 AC-4(1) \nSC-7(17)  \nMLSWNR -2.1  SC-7(17)  \nMLSWNR -2.2  SC-7(17)  \nMLSWNR -3  SC-39(1)  \nMLSWNR -3.1  SC-3(1) \nSC-49 RTB \nRequirement  NIST \nControl  \nMLSWNR -4  SC-37 \nSI-7(6) \nMLSWNR -4.1 SC-37 \nMLSWNR -5  SC-7(17)  \nMLSWNR -6  AC-16(8)  \nSI-7(6) \nMLSWNR -6.1  AC-16(8)  \nMLSWNR -7    \nMLSWNR -8  SA-8(23)  \nSC-7(5) \nMLSWNR -9  AC-3(3) \nAC-4 \nMLSWNR -10  SC-7(5) \nMLSWNR -11  SC-50 \nMLSWNR -\n11.1  AC-3(3) \nAC-16 \nMLSWNR -12 SC-16(1)  \nCMSR -1   N/A \nCMSR -1.1   SA-8 \nCMSR -1.2 SA-8 \nCMSR -2  SC-3 \nCMSR -3  AC-17 \nCM-3(3)  \nCM-11 \nCMSR -3.1 CM-3(3) \nCMSR -3.2 CM-3(3) \nCMSR -4  SC-7(13)  \nSC-37 \nCMSR -4.1  SC-8(1) \nSC-36 \nCMSR -4.1.1  SC-7(21)  \nSC-8(1) \nSC-13 \nCMSR -4.2  SA-17 \nCMSR -4.2.1  SC-13 RTB \nRequirement  NIST \nControl  \nCMSR -4.3 IA", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}787{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "786", "chunk": "-5(2) \nCMSR -4.3.1  CM-14 \nCMSR -5 CM-14 \nCMSR -6 SA-4(9) \nCMSR -7 SA-4(9) \nCMSR -8 SA-4(9) \nCMSR -9 AC-19 \nCMSR -9.1 SC-28(1)  \nCMSR -9.2 IA-2(1) \nCMSR -10 SA-4(9) \nCMSR -11 SA-15(5)  \nSI-4 \nCMSR -12 CM-6 \nCM-7(5) \nCMSR -13 CM-14 \nSC-12 \nCMSR -13.1  SC-17 \nCMSR -14 SI-7(6) \nCMSR -15 IA-5(2) \nCMSR -16 AC-3(2) \nSA-8(15)  \nCMSR -17 AC-3(7) \nCMSR -18 IA-5(2) \nCMSR -19 IA-5(2) \nCMSR -20 AC-3(7) \nCMSR -21 AC-3(7) \nCMSR -22 AU-2 \nCM-3 \nCMSR -23 SA-8(27)  \nACDSR -1 AC-3 \nAC-6(4) \nIA-2UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 393 of 397 \n RTB \nRequirement  NIST \nControl  \nACDSR -2 AC-3 \nAC-4(22)  \nAC-6(4) \nACDSR -3 AC-17 \nIA-2 \nSC-7 \nACDSR -3.1 AC-17 \nIA-7 \nACDSR -3.2 AC-17 \nIA-7 \nSC-7 \nACDSR -4 IA-2(1) \nIA-2(2) \nACDSR -4.1   \nACDSR -5 SC-8(1) \nACDSR -6 SC-28(1)  \nACDSR -7 IA-7 \nACDSR -8 CM-11 \nACDSR -8.1 SA-4(7) \nACDSR -8.2 AC-6 \nSA-15(5)  \nACDSR -8.3 AC-4(8) \nSA-15(5)  \nACDSR -8.4 SA-4(7) \nACDSR -8.5 CM-3(8) \nCM-11 \nACDSR -8.6 CM-6 \nACDSR -8.7 CM-7 \nSA-17(5)  \nACDSR -9 AC-4(8) \nSC-49 \nACDSR -10 MP-7 \nACDSR -10.1  CM-7(9) \nMP-7 \nRHRR -1 AC-4(9) \nRHRR -1.1 AU-10(3)  RTB \nRequirement  NIST \nControl  \nRHRR -2 AC-4", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}788{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "787", "chunk": "(9) \nRHRR -3 N/A \nRHRR -3.1 AC-17 \nRHRR -3.2 IA-2(1) \nRHRR -3.2.1  IA-2(1) \nRHRR -3.3 AC-4(9) \nRHRR -3.4 AC-4(11)  \nRHRR -3.4.1  AC-4(27)  \nRHRR -3.4.2  AC-4(8) \nRHRR -3.4.3  AC-4(8) \nAC-16(5)  \nRHRR -3.4.4  AC-4(26)  \nRHRR -3.4.5  AC-4(26)  \nRHRR -3.4.6  SI-10(1)  \nAC-3(10)  \nRHRR -3.5 CM-5(4) \nRHRR -3.6 SI-7(6) \nRHRR -3.6.1  SI-7(6) \nRHRR -3.6.2  AC-4(26)  \nAU-10(1)  \nRHRR -3.6.3  AC-4(26)  \nRHRR -3.6.4  AU-10(2)  \nAU-10(4)  \nSI-15 \nRHRR -3.7 AC-4(26)  \nRHRR -3.7.1  AC-4(26)  \nRHRR -3.8 AC-3(2) \nRHRR -3.9 AC-6 \nRHRR -3.10  AC-4(11)  \nRHRR -3.10.1  AC-4(11)  \nRHRR -3.11  AC-4(9) \nRHRR -3.12  AC-4(26)  RTB \nRequirement  NIST \nControl  \nRHRR -4 AC-3(10)  \nSI-10(1)  \nRHRR -4.1 SA-17 \nRHRR -4.2 AC-3(2) \nSI-10(1)  \nRHRR -4.3 SI-10(1)   \nRHRR -4.4 AC-3(10)  \nRHRR -4-5 AC-3(10)  \nSI-10(1)  \nRHRR -4.5.1  AC-3(10)  \nSI-10(1)  \nRHRR -4.6 AC-3(10)  \nAU-3(1) \nRHRR -4.7 AU-3(1) \nAU-9 \nSC-8 \nRHRR -4.8 AC-3(10)  \nSI-10(1)  \nRHRR -4.9 CM-6 \nFSR-1 SA-8 \nFSR-1.1 SA-8 \nFSR-2 AC-4(27)  \nAC-4(28)  \nFSR-2.1 SA-17 \nFSR-3 CA-2(3) \nSA-11(3)  \nFSR-4 SA-8 \nFSR-5 SC-5(2) \nFSR-6 SC-3 \nSC-7(13)  \nFSR-7 AC-17 \nCM-11 \nFSR-7.1 AC-17 \nCM-11 \nFSR-7.2 AC-17 \nCM-11UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO ", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}789{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "788", "chunk": "USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 394 of 397 \n RTB \nRequirement  NIST \nControl  \nFSR-8 SA-17 \nFSR-9 N/A \nFSR-9.1 SC-50 \nFSR-9.2 AC-4(26)  \nFSR-9.3 AC-4(31)  \nFSR-9.4 AC-4(9) \nFSR-9.4.1  SC-13 \nFSR-9.5 SC-8(1) \nFSR-10 AC-4(8) \nFSR-11 SA-17 \nSC-39 \nFSR-12 SA-17 \nFSR-13 N/A \nFSR-13.1  SI-10 \nFSR-13.2  SI-10 \nFSR-13.3  SI-10 \nFSR-13.4  SI-10 \nFSR-13.5  SI-10 \nFSR-13.6  SI-10 \nFSR-13.7  SI-10 \nFSR-13.8  SI-10 \nFSR-13.9  SI-10 \nFSR-14 AC-17 \nIA-5(2) \nFSR-15 CA-9 \nFSR-16 AC-4(31)  \nAU-2 \nSA-8(24)  \nFSR-17 SC-39 \nFSR-18 SC-39 \nFSR-19 SC-39 \nFSR-20 SC-7(13)  \nSC-7(21)  RTB \nRequirement  NIST \nControl  \nFSR-21 PL-8 \nFSR-22 SC-7(13)  \nSC-7(21)  \nFSR-23 SC-39 \nFSR-24 AC-4(6) \nFSR-24.1 AC-4(6) \nFSR-24.2 SA-8 \nFSR-24.3 AC-3(15)  \nAC-4(7) \nFSR-25 AU-4(1) \nSC-37 \nFSR-25.1 AU-9(2) \nSC-37 \nFSR-25.2 AU-9(2) \nSC-37 \nFSR-26 SA-17 \nFSR-27 SA-17 \nFSR-28 IA-5(2) \nFSR-29 SC-7 \nFSR-30 AC-3(3) \nFSR-31 SA-17 \nSC-39 \nDFSR -1 SA-8 \nDFSR -1.1 SA-8 \nDFSR -1.1.1  SA-17(8)  \nDFSR -1.1.2  AC-4(21)  \nSC-39 \nDFSR -1.1.3  CM-11 \nSA-17(8)  \nDFSR -1.1.4  SA-17(8)  \nDFSR -1.1.5  CM-11 \nDFSR -1.1.6  CM-8 \nCM-14 \nSI-7(6) RTB \nRequirement  NIST \nControl  \nDFSR -1.1.7  CM-14 \nSI-7(6) \nDFSR -1.1.8  CM-11 \nDFSR -1.1.9  CM-6 \nDFSR -2 AC-4(27)  \nDFSR -3 SC-5(2) \nDFSR -4 CA-2(3) \nSA-11(3)  \nDFSR", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}790{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "789", "chunk": " -5 PL-8 \nDFSR -6 AC-4(7) \nSA-15(5)  \nSC-49 \nDFSR -6.1 PL-8 \nDFSR -7 PL-8 \nSC-7 \nDFSR -8 AC-4 \nPL-8   \nDFSR -9 PL-8 \nDFSR -10 SC-3 \nSC-7(13)  \nDFSR -11 SA-17 \nDFSR -12 N/A \nDFSR -12.1  SC-50 \nDFSR -12.2  AC-4(26)  \nDFSR -12.3  AC-4(31)  \nDFSR -12.4  AC-4(9) \nDFSR -12.4.1  SC-13 \nDFSR -13 AC-4(8) \nDFSR -14 AC-6(4) \nDFSR -15 AC-17 \nCM-11 \nDFSR -15.1  AC-17 \nCM-11UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 395 of 397 \n RTB \nRequirement  NIST \nControl  \nDFSR -15.2  AC-17 \nCM-11 \nDFSR -16 CM-14 \nDFSR -17 AC-17 \nSA-4(9) \nDFSR -18 AU-12(2)  \nDFSR -19 AU-12(2)  \nDFSR -20 AC-17 \nSC-3 \nDFSR -20.1  AC-17 \nSC-3 \nDFSR -21 SA-15(5)  \nSI-4 \nDFSR -22 AU-4(1) \nSC-37 \nDFSR -23 AC-4(26)  \nAU-6(1) \nDFSR -24 SA-17 \nSI-15 \nDFSR -25 SA-17 \nDFSR -25.1  N/A \nDFSR -25.1.1  SA-15 \nDFSR -25.1.2  AC-4(26)  \nDFSR -25.1.3  AC-4(26)  \nDFSR -25.1.4  SI-7 \nDFSR -25.1.5  AC-4(31)  \nDFSR -25.1.6  AC-16(8)  \nDFSR -25.1.7  AC-16(8)  \nDFSR -26 N/A \nDFSR -26.1  SI-10 \nDFSR -26.2  SI-10 \nDFSR -26.3  SI-10 \nDFSR -26.4  SI-10 \nDFSR -26.5  SI-10 RTB \nRequirement  NIST \nControl  \nDFSR -26.6  SI-10 \nDFSR -26.7  SI-10 \nDFSR -27 AC-4(8) \nAC-4(14)  \nDFSR", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}791{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "790", "chunk": " -28 AC-4(8) \nAC-4(14)  \nDFSR -29 AC-4(31)  \nSA-8(24)  \nSI-4(7) \nDFSR -30 AC-4(31)  \nSA-8(24)  \nSI-4(7) \nDFSR -32 AC-4(31)  \nSA-8(24)  \nSI-4(7) \nDFSR -32 SI-7(1) \nDFSR -33 SI-7(1) \nSI-7(6) \nDFSR -34 SI-10 \nDFSR -35 AC-4(19)  \nDFSR -36 AU-9 \nDFSR -37 AC-4(29)  \nDFSR -38 IA-3 \nSC-8(1) \nSC-13 \nDFSR -39 AU-4(1) \nSC-37 \nCDRR -1  SR-12 \nCDRR -2 MP-6 \nSR-12 \nCDRR -3 SR-12 \nCDRR -4 SI-12(3)  \nSR-12 \nCDRR -5 MP-6 \nSR-12 RTB \nRequirement  NIST \nControl  \nHWC -GHR -1  AC-4(21)  \nSC-3(2) \nHWC -GHR -\n1.1 SA-4(2) \nSA-5 \nHWC -GHR -\n1.2 SA-4(2) \nSA-8(6) \nHWC -GHR -2 SA-8(19)  \nHWC -GHR -3 CM-6 \nHWC -GHR -4 AC-4(7) \nSA-17(8)  \nSC-3 \nHWC -GHR -5 SC-41 \nHWC -GHR -6 SC-41 \nHWC -GHR -7 CM-7 \nHWC -GHR -8 SA-15 \nHWC -GHR -9 CM-14 \nSI-7(6) \nHWC -GHR -\n9.1 CM-14 \nSI-7(6) \nHWC -GHR -10 AC-4(27)  \nSC-49 \nHWC -GHR -\n10.1  AC-4(14)  \nHWC -GHR -\n10.2  AC-4(27)  \nSC-49 \nHWC -GHR -\n10.3  SC-49 \nHWC -GHR -\n10.4  AC-4(7) \nSC-49 \nHWC -GHR -11 CM-3(8) \nHWC -GHR -12 SA-17 \nHWC -GHR -13 AC-4(24)  \nSA-17 \nHWC -GHR -\n13.1  AC-4(24)  \nSA-17 \nHWC -GHR -14 SA-17UNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nUNCLASSIFIED//FOR OFFICI AL USE ONLY//REL TO USA, ARE, BHR, FVEY, ISR, JPN, KOR, NATO, NOR, SAU, SWE, QAT  \nPage 396 of 397 \n RTB \nRequirement  NIST \nControl", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}792{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "791", "chunk": "  \nHWC -GHR -15 SA-17 \nHWC -GHR -16 SA-17 \nSC-39(1)  \nHWC -GHR -17 AC-4(14)  \nHWC -GHR -18 SC-7(21)  \nHWC -GHR -19 AU-2 \nHWC -GHR -20 SC-12 \nSR-4(3) \nSR-9 \n HWC -NTR -1  SC-3 \n HWC -NTR -\n1.1  SC-32(1)  \n HWC -NTR -\n1.2  AC-4(14)  \nAC-4(27)  \nAC-4(30)  \n HWC -NTR -\n1.3  SC-49 \n HWC -NTR -\n1.4  SA-17 \nHWC -NTR -2  SA-17 \nSC-3 \nHWC -NTR.3  SA-17 \nSC-37 \nHWC -NTR -4 SA-17 \nSC-37 \nHWC -NTR.5  SI-7(15)  \nHWC -NTR -5.1 SI-7(15)  \nHWC -NTR -6 AC-17(3)  \nSC-7(5) \nHWC -NTR -6.1 SA-4(9) \nHWC -NTR -7 SC-3 \nHWC -NTR -8 AC-4(7) \nSC-49 \nHWC -NTR -8.1  AC-4(7) \nSC-49 RTB \nRequirement  NIST \nControl  \nHWC -NTR -8.2  AC-4(7) \nSC-49 \nHWC -NTR -9 AU-4(1) \nSC-37 \nHWC -NTR -10 AU-4(1) \nSC-37 \nHWC -TR-1  SA-17 \nSR-9 \nHWC -TR-2 SA-17 \nSR-9 \nHWC -TR-3  SC-49 \nHWC -TR-3.1 SA-17 \nSC-49 \nHWC -TR-4  SC-49 \nSI-7(7) \nHWC -TR-5 SA-17 \nHWC -TR-6 SA-17 \nHWC -TR-7 SA-17 \nHWC -TR-8 SA-17 \nHWC -TR-9 SA-17 \nFPGA -1 CM-7 \nSC-41 \nFPGA -2 RA-5 \nSI-4 \nFPGA -3 SC-41 \nFPGA -4 SR-9 \nSFPGA -1 AC-4(4) \nSFPGA -2   \nSFPGA -3 SA-15(5)  \nSFPGA -4 IR-4(3) \nSFPGA -5 SA-15(5)  \nSFPGA -6   RTB \nRequirement  NIST \nControl  \nFPGA -7 SI-2 \nSI-7(9) \nSFPGA -8 SA-15(5)  \nSI-2 \nSFPGA -9 PE-14 \nSFPGA -10  SI-2 \nSFPGA -11 CM-6 \nSFPGA -12 PL-2 \nSC-45 \nSFPGA -13 SR-9 \nSFPGA -14 SI-7(9) \nSFPGA -15 RA-5 \nSFPGA -16 CM-6 \nSFPGA -17 AU-2 \nSFPGA -18", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}793{"doi": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "chunk-id": "792", "chunk": " CM-6 \nSFPGA -19 CM-6 \nWNVFPGA -1  IA-4 \nWNVFPGA -2 PE-14 \nWNVFPGA -3 PE-14 \nWNVFPGA -4   \nWNVFPGA -5 SA-15(5)  \nSI-2 \nWNVFPGA -6 SA-17 \nWNVFPGA -7 CM-3 \nWNVFPGA -8 RA-5 \nSNVFPGA -1  PE-11 \nPL-2 \nSNVFPGA -1.1  PE-11 \nPL-2 \nSNVFPGA -2 SR-9 \nSNVFPGA -3 SR-91", "id": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "title": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "source": "Draft_2023_RTB_CDS_Design_Implementation_Requirements_v5_0_rev_85", "authors": [], "categories": [], "references": []}794{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "0", "chunk": "COMMERCIAL SOLUTION S for  CLASSIFIED  \n(CSfC)  \n \nCampus Wireless Local Area Network  (WLAN)   \nCapability Package V 3.0.1 \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \nVersion 3.0.1 \n23 January  2023i \n CHANGE HISTORY  \n \nTitle  Version  Date  Change Summary  \nCommercial Solutions for \nClassified (CSfC) Campus \nIEEE 802.11 Wireless Local \nArea Network (WLAN) \nCapability Package   0.9 December 14, 2012  \uf0b7 Initial release of CSfC Campus IEEE 802.11 \nWireless Local Area Network (WLAN) guidance.  \nCommercial Solutions for \nClassified (CSfC) Campus \nIEEE 802.11 Wireless Local \nArea Network (WLAN) \nCapability Package   1.0 August 20, 2013  \uf0b7 Official release of CSfC Campus WLAN guidance.  \n\uf0b7 Revised content to be consistent with VPN CP \nversion 2.0.  \n\uf0b7 Removed compo und requirements for \nimproved testability.  \n\uf0b7 Merged sections to reduce duplicate \nrequirements.  \nCommercial Solutions for \nClassified (CSfC) Campus \nIEEE 802.11 Wireless Local \nArea Network (WLAN) \nCapability Package   1.1 March 4, 2014  \uf0b7 Corrected minor errors .  \n\uf0b7 Removed redundant requirements .  \n\uf0b7 Added Solution testing section .  \n\uf0b7 Added Appendix F to state summary of changes \nin requirements between the versions . \nCommercial Solutions for \nClassified (CSfC) Campus \nWireless Local Area \nNetwork (WLAN) Capability \nPackag", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}795{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "1", "chunk": "e   1.8 September 17, 2015  \uf0b7 Initial release of CSfC Campus WLAN guidance \nfor use of a Shared Outer WPA2 layer and single \nGray Network with networks of multiple \nsecurity levels.  \n\uf0b7 Improvements of Continuous Monitoring and \nrevised content to be consistent with VPN CP \nversion 3.2 and MA CP version 1.1.  \n\uf0b7 Added new Cryptography standards in \naccordance with CNSSP 15.  \n\uf0b7 Added Gray Firewall .  \n\uf0b7 Added Continuous Monitoring Requirements  \n\uf0b7 Updated requirement WLAN -PS-10 \nCommercial Solutions for \nClassified (CSfC) Campus \nWireless Local Area \nNetwork (WLAN) Capability \nPackage   2.0 March 18, 2016  \uf0b7 Added EUD requirement (WLAN -EU-40) to \nisolate the management and control of the EUD \nconnection to the WLAN system from other \nEUD fu nctions.  \n\uf0b7 Added IDS requirements for the Gray Network . \nCommercial Solutions for \nClassified (CSfC) Campus \nWireless Local Area \nNetwork (WLAN) Capability \nPackage   2.1 February 2018  \uf0b7 Removed references to CNSS AM 02 -15 as \nCNSSP -15 was updated and signed.  \n\uf0b7 Removed references to Suite -B encryption \nalgorithms.  Updated to reference the \nCommercial National Security Algorithm (CNSA) \nSuite.  \n\uf0b7 Changed WLAN -PS-9 to Objective.  \n\uf0b7 Changed WLAN -EU-23 minimum password \nlength.  \n\uf0b7 Updated Continuous Monitoring section to beii \n co", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}796{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "2", "chunk": "ns istent with other DIT CPs.  \n\uf0b7 Updated Testing Requirements and created a \nTesting Requirements Annex.  \n\uf0b7 Updated template IAD -> IAC . \n\uf0b7 Added requirement WLAN -PS-6 for selecting a \nCertification Authority from the CSfC \nComponents list.  \n\uf0b7 Removed Threat section \u2014in a se parate \ndocument available on the CSfC webpage.  \n\uf0b7 Modified Table 9 to change the Objective \nrequirement for AES -256-GCMP to AES -256-\nCCMP; removed  inaccurate RFC references.  \n\uf0b7 Added wording (from the Mobile Access CP) at \nthe end of Section 2 to address case -by-case \napprovals for TS systems.  \nCommercial Solutions for \nClassified (CSfC) Campus \nWireless Local Area \nNetwork (WLAN) Capability \nPackage   2.2 June  26, 2018  \uf0b7 Relocated Key Management Requirements \nfrom the CP and created a separate Key \nManagement Requ irements Annex.  \n\uf0b7 Updated requirements to use \u201cmust\u201d instead of \n\u201cshall.\u201d  \n\uf0b7 Minor administrative changes were made in \nformatting.  \n\uf0b7 Changed WLAN PS -12 to \u2018Objective.\u2019  \n\uf0b7 Changed WLAN PS -14 to \u2018Threshold=Objective.\u2019  \nCommercial Solutions for \nClassified (CSfC) Campus \nWireless Local Area \nNetwork (WLAN) Capability \nPackage   2.3 April 2021  \uf0b7 Relocated WIDS Requirements from the CP and \ncreated a separate WIDS/WIPS Annex.  \n\uf0b7 Relocated Continuous  Monitoring \nRequirements f", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}797{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "3", "chunk": "rom the CP and created a \nseparate Continuous  Monitoring Annex.  \n\uf0b7 Inner Encryption Component must function \nusing Tunnel Requirement.  \nCommercial Solutions for \nClassified (CSfC) Campus \nWireless Local Area \nNetwork (WLAN) Capability \nPackage   2.8 May  2021  \uf0b7 Initial  v2.8 draft release of the CSfC Campus \nWLAN CP v3. 0, feeding into final WLAN CP v3.0 \nupdates.  \nCommercial Solutions for \nClassified (CSfC) Campus \nWireless Local Area \nNetwork (WLAN) Capability \nPackage   3.0 04 May  2022  \uf0b7 Updated  to WPA3 standard for 802.11 \nencryption , deprecating WPA2 in this \ndocument.  \n\uf0b7 Added Campus WLAN Tactical Appendix.  \n\uf0b7 Added Objective Virtualization requirements.  \n\uf0b7 Added Objective Two Factor requirements.  \n\uf0b7 Rewrote sections for consistency with other \nCSfC CPs.  \n\uf0b7 Added inner firewall requirement.  \n\uf0b7 Increased EUD m inimum password to 14 \ncharacters.  \n\uf0b7 Added 802.11w requirement.  \nCommercial Solutions for \nClassified (CSfC) Campus 3.0.1  23 January 2023  \uf0b7 Fixed Requirement Alternative Reference in \nTactical Appendixiii \n  \nTABLE OF CONTENTS  \n \n1 Introduction  ................................ ................................ ................................ ................................ ..........  1 \n2 Purpose and Use  ................................ .......", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}798{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "4", "chunk": "......................... ................................ ................................ ... 1 \n3 Legal Disclaimer  ................................ ................................ ................................ ................................ .... 2 \n4 Description of  the Campus WLAN Solution  ................................ ................................ ..........................  2 \n4.1 Implementing CSfC in a High Assurance GOTS Environment  ................................ .......................  3 \n4.2 Rationale for Layered Encryption  ................................ ................................ ................................ . 4 \n4.3 Networks  ................................ ................................ ................................ ................................ .......  4 \n4.3.1  Red Network  ................................ ................................ ................................ .........................  4 \n4.3.2  Gray Network  ................................ ................................ ................................ ........................  5 \n4.3.3  Black Network  ................................ ................................ ................................ .......................  5 \n4.3.4  Data, Management, and Con", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}799{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "5", "chunk": "trol Plane Traffic  ................................ ................................ ..... 5 \n4.4 High -Level Design  ................................ ................................ ................................ ..........................  7 \n4.4.1  End Us er Devices  ................................ ................................ ................................ ...................  7 \n4.4.2  Multiple Security Levels  ................................ ................................ ................................ ........  8 \n4.5 Rationale for Layered Encryption  ................................ ................................ ...............................  10 \n4.6 Authentication  ................................ ................................ ................................ ............................  10 \n4.6.1  Traditional Authentication  ................................ ................................ ................................ .. 11 \n4.6.2  Two Factor Authentication  ................................ ................................ ................................ . 11 \n4.7 Other Protocols  ................................ ................................ ................................ ...........................  12 \n4.8 Availabili ty ............", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}800{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "6", "chunk": ".................... ................................ ................................ ................................ ... 12 \n5 Infrastructure Components  ................................ ................................ ................................ ................  12 \n5.1 WLAN Access System  ................................ ................................ ................................ ..................  13 \n5.2 Gray Firewall  ................................ ................................ ................................ ...............................  14 \n5.3 Inner Firewall  ................................ ................................ ................................ ..............................  14 \n5.4 Gray Management Services  ................................ ................................ ................................ ........  14 Wireless Local Area \nNetwork (WLAN) Capability \nPackage   \n \uf0b7 Higher Resolution Diagram for Figure 5iv \n 5.4.1  Gray Administration Workstation  ................................ ................................ .......................  15 \n5.4.2  Gray Security Information and Event Management (SIEM)  ................................ ...............  16 \n5.4.3  Gray Authentication Server ................................ ", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}801{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "7", "chunk": "................................ ................................ . 16 \n5.5 Inner Encryption Components  ................................ ................................ ................................ .... 17 \n5.5.1  Inner VPN Gateway  ................................ ................................ ................................ .............  17 \n5.6 Red Management Services ................................ ................................ ................................ ..........  17 \n5.6.1  Red Administration Workstations  ................................ ................................ .......................  18 \n5.6.2  Red Security Information and Event Management (SIEM)  ................................ .................  18 \n5.7 Public Key Infrastructure Components  ................................ ................................ .......................  18 \n6 End User Device Components  ................................ ................................ ................................ .............  19 \n6.1 End User Device  ................................ ................................ ................................ ..........................  19 \n6.1.1  End User Device  ................................ ................................ .....................", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}802{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "8", "chunk": "........... ..................  20 \n6.2 WLAN Client  ................................ ................................ ................................ ................................  20 \n6.3 VPN Client  ................................ ................................ ................................ ................................ ... 21 \n6.4 Enhanced Isolation  ................................ ................................ ................................ ......................  21 \n6.4.1  Software Virtualization  ................................ ................................ ................................ .......  21 \n7 Campus WLAN Configuration and Management  ................................ ................................ ................  22 \n7.1 Solution Infrastructure Component Provisioning  ................................ ................................ .......  22 \n7.2 EUD Provisioning  ................................ ................................ ................................ .........................  22 \n7.3 Management of Campus WLAN Solution Components  ................................ ..............................  23 \n7.4 EUDs for Different Classification Domains  ................................ ................................ ...........", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}803{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "9", "chunk": ".......  24 \n8 Continuous Monitoring  ................................ ................................ ................................ .......................  24 \n8.1 Wirele ss Intrusion Detection System (WIDS)  ................................ ................................ ..............  25 \n9 Key Management  ................................ ................................ ................................ ................................  25 \n10 Requirements Overview  ................................ ................................ ................................ .....................  25 \n10.1  Threshold and Objective Requirements  ................................ ................................ .....................  25 \n10.2  Requirements Designators  ................................ ................................ ................................ ..........  26 \n11 Requirements for Selecting Components  ................................ ................................ ...........................  27 \n12 Configuration Requirements  ................................ ................................ ................................ ...............  28 \n12.1  Overall Solution Requirements  ................................ ................................ .............", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}804{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "10", "chunk": "................... ... 29 \n12.2  End User Device Requirements  ................................ ................................ ................................ ... 30v \n 12.3  Enhanced Virtualization Requirements  ................................ ................................ ......................  33 \n12.4  WLAN Client Configuration Requirements  ................................ ................................ .................  34 \n12.5  VPN Components and VPN Client Configuration Requirements  ................................ ................  36 \n12.6  WLAN Access System Configuration Requirements  ................................ ................................ ... 37 \n12.7  Port Filtering Requirements  ................................ ................................ ................................ ........  40 \n12.8  End User Device Provisioning Requirements  ................................ ................................ ..............  41 \n12.9  Configuration Requirements for Wireless Intrusion Detection System (WIDS)  .........................  42 \n12.10  Configuration Change Detection Requirements  ................................ ................................ .........  42 \n12.11  Device Management Requiremen ts ................................ ........", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}805{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "11", "chunk": "........................ ...........................  42 \n12.12  Continuous Monitoring Requirements  ................................ ................................ .......................  44 \n12.13  Auditing Requirements  ................................ ................................ ................................ ...............  44 \n12.14  Key Management Requirements  ................................ ................................ ................................  44 \n12.15  Gray Firewall Requirements  ................................ ................................ ................................ ........  44 \n12.16  EUD to Infrastructure Two -Factor Authentication Requirements  ................................ ..............  45 \n12.17  User to EUD for Two Factor Authentication Requirements  ................................ .......................  46 \n13 Requirements for Solution Operation, Maintenance, and Handling  ................................ ..................  47 \n13.1  Use and Handling of Solutions ( GD) Requirements  ................................ ................................ .... 47 \n13.2  Requirements for Incident Reporting  ................................ ................................ .........................  49 \n14 Role -Based Personne", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}806{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "12", "chunk": "l Requirements  ................................ ................................ ................................ .. 51 \n15 Information to Support AO  ................................ ................................ ................................ .................  52 \n15.1  Solution Testing  ................................ ................................ ................................ ..........................  53 \n15.2  Risk Assessment  ................................ ................................ ................................ ..........................  54 \n15.3  Registration of Solutions  ................................ ................................ ................................ .............  54 \nAppendix A. Glossary of Terms  ................................ ................................ ................................ ...................  56 \nAppendix B. Acronyms  ................................ ................................ ................................ ................................  60 \nAppendix C. References  ................................ ................................ ................................ ..............................  63 \nAppendix D. Tactical Solution Implementations  ................................ .............", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}807{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "13", "chunk": "................... .........................  66 \n \nTable of Figures  \n \nFigure 1. Overview of Campus WLAN CP  ................................ ................................ ................................ ...... 3vi \n Figure 2. Campus WLAN Single C lassification Implementation  ................................ ................................ .... 7 \nFigure 3. Campus WLAN Solution for Two Networks of the Same Classification Level  ................................  9 \nFigure 4. Campus WLAN Solution for Networks Operating at Different Classification Levels  ...................  10 \nFigure 5. Overview of Gray Management Services  ................................ ................................ .....................  15 \nFigure 6. Overview of Red Management Services  ................................ ................................ ......................  18 \nFigure 7. Campus WLAN End User Device Architecture  ................................ ................................ .............  20 \nFigure 8. Enhanced Software Virtualization Architecture  ................................ ................................ ..........  21 \nFigure 9. Campus WLAN Continuous Monitoring Points  ................................ ................................ ............  25 \nList  of Tabl", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}808{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "14", "chunk": "es  \n \nTable 1. Requirement Digraph  ................................ ................................ ................................ ....................  26 \nTable 2. Production Selection Requirements  ................................ ................................ .............................  27 \nTable 3. Overall Solution Requirements (SR)  ................................ ................................ ..............................  29 \nTable 4. End User Device (EU) Requirements  ................................ ................................ .............................  30 \nTable 5. Enhanced Virtualization  Requirements  ................................ ................................ .........................  33 \nTable 6. WLAN Client (WC) Configuration Requirements  ................................ ................................ ...........  34 \nTable 7. Wireless Link (WL) Requirements  ................................ ................................ ................................ . 35 \nTable 8. IPSec Encryption (Approved Algorithms for Classified)  ................................ ................................  35 \nTable 9. WPA3 Encryption and EAP -TLS (Approved Algorithms)  ................................ ................................  36 \nTable", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}809{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "15", "chunk": " 10. VPN Components Configuration Requirements (CR)  ................................ ................................ .. 36 \nTable 11. WLAN Access System (WS) Configuration Requirements  ................................ ...........................  37 \nTable 12. Wireless Infrastructure Au thentication (IA) Requirements  ................................ ........................  38 \nTable 13. Wireless Authentication and Authorization (AA) Requirements  ................................ ................  39 \nTable 14. Wireless Authentication Server (WA) Requirements  ................................ ................................ .. 39 \nTable 15. Solution Components Port Filtering (PF) Requirements  ................................ .............................  40 \nTable 16. EUD Provisioning Requirements (PR)  ................................ ................................ ..........................  41 \nTable 17. WIDS/WIPS Requirements  ................................ ................................ ................................ ..........  42 \nTable 18. Device Management (DM) Requirements  ................................ ................................ ..................  43 \nTable 19. Continuous Monitoring Requirements  ................................ ..............", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}810{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "16", "chunk": ".................. .......................  44 \nTable 20. Key Management Requirements ................................ ................................ ................................ . 44 \nTable 21. Gray Firewall (FW) Requirements  ................................ ................................ ...............................  45 \nTable 22. EUD to Infrastructure Two Factor Authentication Requirements  ................................ ..............  45 \nTable 23. User -to-EUD for Two Factor Authentication Requirements  ................................ .......................  46vii \n Table 24. Use and Handling of Solutions Requirements  ................................ ................................ .............  47 \nTable 25. Incident Reporting Requirements (RP)  ................................ ................................ .......................  49 \nTable 26. Role -Based Personnel Requirements  ................................ ................................ ..........................  52 \nTable 27. Test Requirement  ................................ ................................ ................................ ........................  54 \nTable 28. T actical Implementation Overlay Requirements  ................................ ................................", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}811{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "17", "chunk": " ........  661 \n 1 INTRODUCTION  \nThe Commercial Solutions for Classified (CSfC) program within the National Security Agency (NSA) \nCybersecurity Directorate  (CSD) uses a series of Capability Packages (CP) to provide configurations that \nallow customers to independently implement secure solutions using layered Commercial Off -the-Shelf \n(COTS) products.  The CPs are vendor -agnostic and provide high -level security  and configuration \nguidance for customers and/or Integrators.  \nNSA delivers a generic CSfC Campus Wireless Local Area Network (WLAN) CP to meet the demand for \ncommercial End User Devices (EUD) (tablets, smartphones, and laptop computers) to access secure \nenterprise services over a campus wireless network.  Cryptographic algorithms, known as Commercial \nNational Security Algorithms (CNSA), are used to protect classified data using layers of COTS products.  \nIn WLAN CP Version 3.0 .1, the Continuous Monitoring (C M) and Wireless Intrusion Detection System \n(WIDS) Requirements have been relocated from the CP to separate corresponding Annexes.  \n2 PURPOSE AND USE  \nThis CP provides reference architecture and corresponding configuration information that allows \ncustomers to  select COTS products from the CSfC Components List for their Campus WLAN solution and \nthen to ", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}812{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "18", "chunk": "properly configure those products to achieve a level of assurance sufficient for protecting \nclassified data while in transit.  Throughout this CP, requirements i mposed on the Campus WLAN \nsolution are identified by a label consisting of the prefix \u201cWLAN,\u201d a two -letter category, and a sequence \nnumber (e.g., WLAN -KM-11).  To successfully implement a solution based on this CP, all Threshold \nrequirements, or the corres ponding Objective requirements, must be implemented as described in \nSection 10.1.  \nPlease provide comments on usability, applicability, and/or shortcomings to your NSA/CSD Client \nAdvocate and the Campus WLAN  CP maintenance team at Wi-Fi@nsa.gov . \nCNSS Policy No. 15, Use of Public Standards for Secure Information Sharing, identifies additional public \nalgorithms to protect  information within NSS.  Specifically, the following algorithms will be required to \nprotect all NSS up to Top Secret:  \n\uf0b7 AES 256 (confidentiality)   \n\uf0b7 RSA 3072 or ECDSA P -384 (digital signature and authentication)  \n\uf0b7 RSA 3072, DH 3072 or ECDH P -384 (key exchange)  \n\uf0b7 SHA-384 (hashing and integrity)  \nCampus WLAN CP solutions must comply with Committee on National Security Systems, (CNSS) policies \nand instructions.  Any conflicts identified between this CP and NSS or local policy sho", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}813{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "19", "chunk": "uld be provided to \nthe Campus WLAN CP Maintenance team.  \nCustomers and integrators must adhere to all applicable data transfer policies for their organization \nwhen designing and implementing Cross Domain Solutions (CDS) capabilities within their CSfC solution \narchitecture. For example, DoD cus tomers must follow DoDI 8540.01, \u201cCross Domain (SD) Policy\u201d, when2 \n deploying a CDS within a CSfC solution. Any discrepancies found between the guidance in this document \nand DoDI 8540.01 should be reported to the CSfC PMO office at csfc@nsa.gov . \nFor any additional information on CDSs, contact the National Cross Domain Strategy Management Office  \n(NCDSMO) at ncdsmo@nsa.gov . \n3 LEGAL DISCLAIMER  \nThis CP is provided \u201cas is.\u201d  Any express or imp lied warranties, including but not limited to, the implied \nwarranties of merchantability and fitness for a particular purpose are disclaimed.  In no event must the \nUnited States Government be liable for any direct, indirect, incidental, special, exemplary or \nconsequential damages (including, but not limited to, procurement of substitute goods or services, loss \nof use, data, or profits, or business interruption) however caused and on any theory of liability, whether \nin contract, strict liability, or tort (in cluding negligence or otherwis", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}814{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "20", "chunk": "e) arising in any way out of the use of \nthis CP, even if advised of the possibility of such damage.  \nThe user of this CP agrees to hold harmless and indemnify the United States Government, its agents and \nemployees from every cl aim or liability (whether in tort or in contract), including attorney\u2019s fees, court \ncosts, and expenses, arising in direct consequence of Recipient\u2019s use of the item, including, but not \nlimited to, claims or liabilities made for injury to or death of perso nnel of User or third parties, damage \nto, or destruction of, property of User or third parties, and infringement or other violations of \nintellectual property or technical data rights.  \nNothing in this CP is intended to constitute an endorsement, explicit or  implied, by the U.S. Government \nof any particular manufacturer\u2019s product or service.  \n4 DESCRIPTION OF THE C AMPUS WLAN SOLUTION  \nThe solution described within this CP is supported by the use of wireless devices to access sensitive data \nand enterprise services  while minimizing the risk when connecting to existing Government enterprise \nnetworks.  Government -managed campus -area wireless networks provide controlled connectivity \nbetween mobile users and the broader Government enterprise.  The term \u201cCampus\u201d is used in this \ndocument to re", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}815{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "21", "chunk": "fer to any area that is physically protected to the highest classification level of the \nenterprise network where multiple enclaves are supported.  This physical area includes secure facilities \nand tactical environments when the Author izing Official (AO) deems the physical controls appropriate.  \nThe Campus WLAN solution uses two layers of cryptography, Internet Protocol Security (IPsec) using AES \n256 and WPA3 using AES 256, to protect the confidentiality and integrity of the data as it t ransits the \nuntrusted network.  The Virtual Private Network (VPN) Client and WLAN Client running on an EUD \ngenerate the two layers protecting data flow.  Figure 1 shows at a high level  the basic segments of the \nCampus WLAN architecture.  A customer impleme nting a WLAN solution that uses two layers of IPsec \nencryption has the option of complying and registering with the latest Mobile Access CP instead of this3 \n CP. \n \nFigure 1. Overview of Campus WLAN CP  \nCampus WLAN solutions are composed, layered, and built using products from the CSfC Components \nList.  Customers who are concerned that their desired products are not yet on the CSfC Components List \nare encouraged to contact the vendors and urge them to sig n a Memorandum of Agreement (MOA) \nwith NSA and start the National Informatio", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}816{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "22", "chunk": "n Assurance Partnership (NIAP) evaluation process, which \nenables them to be listed on the CSfC Components List.  Products listed on the CSfC Components List are \nnot guaranteed to b e interoperable with all other products on the Components List.  Customers and \nIntegrators should perform interoperability testing to ensure the components selected for their Campus \nWLAN solution are interoperable.  Customers needing assistance obtaining v endor POC information \nshould email csfc_components@nsa.gov . \nWhile CSfC encourages industry innovation, tr ustworthiness of the components is paramount. \nCustomers and their Integrators are advised that modifying a NIAP -evaluated component in a CSfC \nsolution may invalidate its certification and trigger a revalidation process.  To avoid delays, customers or \nInteg rators who feel it is necessary to modify a component should engage the component vendor and \nconsult NIAP through their Assurance Continuity Process (see http://www.nia p-\nccevs.org/Documents_and_Guidance/ccevs/scheme -pub-6.pdf ) to determine whether such a \nmodification will affect the component\u2019s certification.  If a component is modified, NSA\u2019s CSfC PMO \nOffice requires a statement from NIAP that the modification does not alter the certification or security \nof the component.  M", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}817{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "23", "chunk": "odifications which trigger the revalidation process include, but are not limited to \nthe following: modifying the original equipment manufacturers\u2019 code (to include digitally signing the \ncode) or not l everaging the baseline NIAP -evaluated configuration.  \n4.1 IMPLEMENTING CSFC IN A HIGH ASSURANCE GOTS  ENVIRONMENT  \nCustomers have the option to use a blended solution that combines a CSfC solution with a High \nAssurance GOTS solution.  While CSfC uses two layers o f encryption, this is not required with High \nAssurance GOTS, where a single layer of encryption is sufficient.  For example, a CSfC Campus WLAN \nsolution can be employed in an infrastructure where network High Assurance Internet Protocol4 \n Encryptors (HAIPE) are also being used.  The WLAN solution is segmented, and its protection is provided \nby CSfC, while the protection of the network that the information transits is provided by a High \nAssurance GOTS solution.  For additional details or questions about this p rocess, please contact the CSfC \nPMO office at csfc@nsa.gov .  \n4.2 RATIONALE FOR LAYERED ENCRYPTION  \nA single layer of CNSA encryption, properly implemented, is sufficient to protect classified data in \ntransit.  However, a CSfC  Campus WLAN solution uses two layers of CNSA encryption to mitigate the risk ", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}818{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "24", "chunk": "\nof a failure in one of the cryptographic components. Accidental misconfiguration, operator error, or \nmalicious exploitation of a vulnerability, could result in the exposure of cl assified information if a single \nlayer is used.  The use of multiple layers, implemented with components meeting the CSfC vendor \ndiversity requirements, reduces the likelihood that a single vulnerability can be exploited to reveal \nprotected information.  \nDiversity of implementation is needed between the components in each layer of the solution in order to \nreduce the likelihood that both layers share a common vulnerability.  The CSfC Program recognizes two \nways to achieve this diversity.  The first is to impl ement each layer using components produced by \ndifferent manufacturers.  The second is to use components from the same manufacturer, where the \nmanufacturer has provided NSA with sufficient evidence that the implementations of the two \ncomponents are independ ent of one another.  The CSfC web page \n(https://www.nsa.gov/resources/commercial -solutions -for-classified -program ) contains details on how \na manufacturer submits this evidence to NSA and what documentation must be provided.  Customers \nthat wish to use products from the same manufacturer in both layers must contact their NSA Client", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}819{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "25", "chunk": " \nAdvocate to confirm that NSA has accepted the manufacturer\u2019s claims before implementing their \nsolution.  \n4.3 NETWORKS  \nThis CP uses the following terminology to describe the various networks that comprise a Campus WLAN \nsolution and the types of traffic present on each.  The terms Red, Gray, and Black refer to the level of \nprotection applied to the data as described below.  \n4.3.1  RED NETWORK  \nRed data consists of unencrypted classified data and a Red Network contains only Red data.  Red \nNetworks are under the control of the solution owner or a trusted third party.   \nThe Red Network begins at the internal interface(s) of Inner Encryp tion Components located between \nthe Gray Firewall and Inner Firewall.  EUDs access the Red Network through the two layers of nested \nencryption described in this CP.  For example, an Inner VPN Gateway located between the Gray Firewall \nand Inner Firewall ter minates the Inner layer of IPsec encryption from a VPN EUD.  Once a successful \nIPsec connection is established, the EUD is given access to classified services such as web, email, Virtual \nDesktop Infrastructure (VDI), voice, etc.  \nRed Networks may only commu nicate with an EUD through the WLAN solution if both operate at the \nsame security level.5 \n 4.3.2  GRAY NETWORK  \nGray data is", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}820{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "26", "chunk": " classified data that has been encrypted once.  Gray Networks are composed of Gray data \nand Gray Management Services.  Gray Networks are under  the physical and logical control of the \nsolution owner or a trusted third party.  \nThe Gray Network is physically treated as a classified network even though all classified data is singly \nencrypted.  If a solution owner\u2019s classification authority determine s that data on a Gray Network is \nclassified, perhaps by determining the Internet Protocol (IP) addresses are classified at some level, then \nthe WLAN solution described in this CP cannot be implemented, as it is not designed to provide two \nlayers of protect ion for any data/traffic on the Gray Network.  \nGray Network components consist of the WLAN Access System, Gray Firewall, and Gray Management \nServices.  All Gray Network components are physically protected at the same level as the Red Network \ncomponents of t he WLAN infrastructure.  Gray Management Services are physically connected to the \nGray Firewall and include, at a minimum, an administration workstation.  The Gray Management \nServices also include a Security Information and Event Management  (SIEM) unless t he SIEM is \nimplemented in the Red Network in conjunction with a CDS. See the Continuous Monitoring Annex  for \nmor", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}821{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "27", "chunk": "e information.  The WLAN CP requires the management of Gray Network components through the \nGray administration workstation.  As a result, neithe r Red nor Black Administration Workstations are \npermitted to manage the WLAN Access System, Gray Firewall, or Gray Management Services.  \nAdditionally, the Gray administration workstation is prohibited from managing Inner Encryption \nComponents.  These Inner  Encryption Components must be managed from a Red Administration \nWorkstation.   \nThe Gray Network may be extended and shared through different sites using the Enterprise Gray \nImplementation Requirements Annex .  This Annex allows for Gray Management Services  to be shared \nbetween different CSfC deployments.  For more information see the Enterprise Gray Implementation \nRequirements Annex . \n4.3.3  BLACK NETWORK  \nA Black Network contains classified data that has been encrypted twice.  The wireless network between \nthe EUD a nd the WLAN Access System in which data is protected with two layers of encryption (the \nIPsec and the WPA3 layers) is a Black Network.  Depending on which vendor product is chosen from the \nCSfC Comp onents List, the WPA3 layer can  terminate on either the Ac cess Point(s) (AP) or Wireless \ncontroller.  For WPA3 tunnels terminating at the AP, encryption stand", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}822{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "28", "chunk": "ards such as IPsec, Secure Shellv2 \n(SSHv2), Transport Layer Security  (TLS), or TLS/  Hypertext Transfer Protocol  Secure (HTTPS) must be \nused to encrypt data between the AP and the wireless controller.   \n4.3.4  DATA, MANAGEMENT , AND CONTROL PLANE TRAFFIC  \nData plane traffic is encrypted or unencrypted classified information that is being passed through the \nCampus WLAN solution.  The Campus WLAN solution exists to encry pt and decrypt data plane traffic.  All \ndata plane traffic within the Black Network must be encapsulated within the Encapsulating Security \nPayload (ESP) protocol and WPA3 Enterprise.  \nManagement plane traffic is used to configure and monitor solution compon ents.  It includes the \ncommunications between a system administrator and a component, as well as the logs and other status6 \n information forwarded from a solution component to a log server, SIEM or similar repository.  \nManagement plane traffic on Red and Gra y Networks must be encapsulated within the SSHv2, ESP, or \nTLS protocol.  \nControl plane traffic consists of standard protocols necessary for the network to function.  Control plane \ntraffic is typically not initiated directly on behalf of a user (unlike data traffic) or a system administrator \n(unlike management traffic).  Many, but not all, co", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}823{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "29", "chunk": "ntrol plane protocols operate at Layer 2 or Layer 3 of \nthe Open Systems Interconnection (OSI) model.  Examples of control plane traffic include, but are not \nlimited to, t he following:  \n\uf0b7 Network address configuration (i.e., Dynamic Host Configuration Protocol (DHCP), Neighbor \nDiscovery Protocol (NDP), etc.)  \n\uf0b7 Address resolution (i.e., Address Resolution Protocol (ARP), NDP, etc.)  \n\uf0b7 Name resolution (e.g., Domain Name System (DNS))  \n\uf0b7 Time synchronization (i.e., Network Time Protocol (NTP), Precision Time Protocol (PTP), etc.)  \n\uf0b7 Route advertisement (i.e., Routing Information Protocol (RIP), Open Shortest Path First (OSPF), \nIntermediate System to Intermediate System (IS -IS), Border Gatewa y Protocol (BGP), etc.)  \n\uf0b7 Certificate status distribution (i.e., Online Certificate Status Protocol (OCSP), Hypertext \nTransfer Protocol (HTTP) download of Certificate Revocation Lists (CRLs), etc.)  \nIn general, this CP does not impose detailed requirements on  control plane traffic, although control \nplane protocols may be used in order to implement certain requirements.  For example, requirements \nWLAN -SR-2 and WLAN -SR-3 (see Section  12.1 ), require that time synchronization be performed, but do \nnot require the u se of any particular time synchronization protocol or technique", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}824{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "30", "chunk": ".  Notable exceptions \nare for IPsec session establishment and for certain certificate status distribution scenarios. This CP \nprovides detailed requirements in those cases due to the impact on t he security of the solution.  Unless \notherwise specified in this CP, the usage of specific control plane protocols is left to the Solution Owner \nto approve, but any control plane protocols not approved by the solution owner should be disabled.  \nData plane a nd management plane traffic are generally required to be separated from one another \nusing physical or cryptographic separation.  Use of a Virtual Local Area Network (VLAN) alone is not \nsufficient to separate data plane and management plane traffic.  As a r esult, a solution may have a Gray \nData network and a Gray Management network which are separate from one another, where the \ncomponents on the Gray Management network are used to manage the components on the Gray Data \nnetwork.7 \n 4.4 HIGH-LEVEL DESIGN  \n \nFigure 2. Campus WLAN Single Classification Implementation  \nDepending on the needs of the customer implementing the solution, the Campus WLAN CSfC solution is \nadaptable to support multiple capabilities.  If a customer does not have to support multiple classified \nnetworks, then those elements do not need be included as par", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}825{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "31", "chunk": "t of the implementation as seen in  Figure \n2.  The Black/Gray boundary in Figure 2 can be at the Access Point(s) or Controller, depending on the \nvendor.  Similarly, a cu stomer may choose to implement a solution where classified information is \nprotected as it travels over -the-air between a WLAN -enabled EUD and a WLAN infrastructure attached \nto a wired network of the same classification level.  However, any implementation o f the Campus WLAN \nsolution must satisfy all of the applicable requirements specified in this CP.  \n4.4.1  END USER DEVICES  \nThis CP uses the concept of an EUD, which is a single Computing Device, such as a smart phone, laptop, \nor tablet.  The EUD provides two layers  of protection for data in transit to access classified data on the \nRed Network.  EUDs are dedicated to a single classification level and can only be used to access a Red \nNetwork of the same classification.  \nThe Campus WLAN CP allows three different deploym ent options pertaining to the use and handling of \nan EUD while powered off:  \n\uf0b7 EUD with DAR:  To implement Data -at-Rest (DAR) protection on an EUD, the DAR sol ution \nmust be approved by NSA, either as a tailored solution or compliant with NSA\u2019s Data -at-Rest \nCP. Specification of such a DAR solution is outside the scope of this CP", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}826{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "32", "chunk": ", but can be found in the \nDAR CP.  The NSA requires implementing organizations to define the  circumstances in which \nan EUD is to be considered outside of the continuous physical control o f authorized users (i.e., \n\u201clost\u201d).  AOs will define \u201ccontinuous physical control\u201d and that definition should align with the \nintended mission and threat environment for which the solution will be deployed.  \nOrganizations must also define the circumstances i n which an EUD that is a part of that \norganization\u2019s solution is to be considered recovered back into the continuous physical control \nof authorized users (i.e., \u201cfound\u201d).8 \n \uf0b7 Thin EUD:  The EUD can be designed to prevent any classified information from being saved to \nany persistent storage media on the EUD.  Possible techniques for implementing this include, \nbut are not limited to: using Virtual Desktop Infrastructure (VDI) configured to  not allow data \nfrom the associated Red Network to be saved on the EUD, restricting the user to a non -\npersistent virtual machine on the EUD, and/or configuring the EUD\u2019s operating system to \nprevent the user from saving data locally.  This option is not per mitted if any of the private \nkeys or certificates stored on the EUD are considered classified by the AO.  Continuous \nphysical control of th", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}827{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "33", "chunk": "e EUD must be maintained at all times.   \n \n\uf0b7 Classified EUD:  The EUD can be used exclusively with physical security meas ures approved by \nthe AO.  EUDs are not subject to special physical handling restrictions beyond those applicable \nfor classified devices since they can rely on the environment they are in for physical \nprotection.  If this design option is selected, the EUDs  must be treated as classified devices at \nall times.  The EUD in this case must enable the native platform DAR protection to protect the \nprivate keys stored on it from disclosure and to increase the difficulty of tampering with the \nsoftware and configurati on.  Continuous physical control of the EUD must be maintained at all \ntimes.   \n \nThe intent of a continuous physical control requirement for the WLAN CP is to prevent potential attacks \nvia brief, undetected physical access of an EUD by any adversary.  When used and stored within a \nprotected campus environment, the inherent security controls are sufficient to meet this requirement.  \nWhen a WLAN EUD is transported or stored outside of the protected campus, a user must maintain \ncontinuous physical control of th e EUD such that an adversary cannot obtain brief, undetected physical \naccess.   \nWhile powered on, an EUD is classified at the same leve", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}828{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "34", "chunk": "l of th e Red Network that it accesses through \nthe Campus WLAN solution, since classified data may be present in volatile memory and/or displayed on \nscreen.  To mitigate the risk of accidental disclosure of classified information to unauthorized personnel \nwhile the EUD is in use, the customer must define and implement an EUD user agreement that specifies \nthe rules of use for the system.  The customer must only grant a user access to an EUD after they \ncomplete the user agr eement and receive training on the use and protection of the EUD.  \n4.4.2  MULTIPLE SECURITY LEVELS  \nA single implementation of the WLAN solution may support multiple R ed Networks of different security \nlevels.  The WLAN solution provides secure connectivity between EUDs and the Red Network of the \nsame security level while preventing EUDs from accessing Red Networks of different security levels.  This \nenables a customer t o use the same physical infrastructure to carry traffic from multiple networks.  \nEUDs operating as part of a Multiple Security Level solution are still dedicated to a single classification \nlevel.  Although each Red Network still requires its own Inner Encr yption Component(s), a site may use a \nsingle WLAN Access System in the infrastructure to encrypt and transport traffic that has ", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}829{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "35", "chunk": "been \nencrypted by Inner Encryption Components of varying security levels.  As shown in Figure 4, a SECRET \nCoalition EUD is only capable of communicating with and authenticating to the Inner Encryption9 \n Components for the  \u2013 SECRET Coalition network.  This EUD does not have any connectivity to the Inner \nEncryption Components of the TS or Unclassified networks.  \nThere is no limit to th e number of different security levels that a WLAN solution may support.  \nIn all cases, separate CAs and management devices are needed to manage the Inner Encryption \nComponents and Inner Firewall at each security level.  For example, Figure 4 shows an indepe ndent site \nwith multiple security levels.  Network 1, Network 2, and Network 3 each have their own CA and \nmanagement devices which prevent EUDs from being able to authenticate with the incorrect network.  \nIn addition to separate Inner Encryption Components  and CAs, an authentication server must be used to \nallow the use of a single Outer Virtual Private Network (VPN) Gateway for multiple security levels.  The \nauthentication server resides within the Gray Management network and validates that Outer Tunnel \ncertificates are signed by the Outer Tunnel CA, are still within their validity period, and have not been \nrevoked.  The authentica", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}830{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "36", "chunk": "tion server also parses the certificate for information assigned to a specific \ninner network (e.g., Organizational Unit (OU) fiel d or policy Object Identifiers (OIDs)) to determine which \ninner network the EUD is authorized to connect.  After successful authentication, the authentication \nserver provides an  accept message to the WLAN Access System along with a Vendor -Specific Attribut e \n(VSA).  The WLAN Access System uses the VSA to assign the proper network and firewall rules such that \nan EUD can only reach the appropriate Inner Encryption Components.  \n4.4.2.1  Networks Operating at the Same Classification Level  \nWhen Red Networks operate at the same classification level but at different security levels, the \ncryptographic separation provided by the Inner VPN Gateways is sufficient to protect against \nunintended data flows between security levels.  Two Inner VPN Gateways for networks of different \nsecurity levels will be unable to mutually authenticate with each other because they trust different CAs \nwhich do not have a trust relationship with one another.  This prevents the establishment of an IPsec \ntunnel between the two components.  \n \nFigure 3. Campus WLAN Solution for Two Networks of the Same Classification Level  \n4.4.2.2  Networks Operating at Different Classifi", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}831{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "37", "chunk": "cation Levels  \nFor Red Networks of different classification levels, the cryptographic separation of their traffic on a Gray \nNetwork (as described in Section  4.4.2.1 ) is still present.  However, because the consequences of an10 \n unintended data flow between different classification levels are more severe than one with a single \nclassification level, an additional mechanism is necess ary to further guard against such a flow from \noccurring.  \n \n \nFigure 4. Campus WLAN Solution for Networks Operating at Different Classification \nLevels  \nIn this scenario packet filtering is required within Gray Networks as an addition al mechanism to prevent \ndata flows between networks of different classification levels.  Any physical path through a Gray \nNetwork between multiple Inner VPN Gateways supporting Red Networks of different classification \nlevels must include at least one filte ring component.  This filtering component restricts the traffic \nflowing through it based primarily on the Gray Network source and destination addresses.  Packets are \npassed only if the source and destination components are intended to communicate with one another \nand are dropped otherwise.  \nWhen multiple classification levels are used, it is critical to enforce proper IP address assignment and \nfirewall r", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}832{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "38", "chunk": "ule sets.  The IP address assigned must be unique to that classification level such that the EUD \nis only a ble to send and receive traffic to and from their respective VPN Gateway.  Proper assignment of \nIP address and firewall rule sets is done at both the Authentication Server (AS) and WLAN access system \nbased on either an allowlist or X.509 Certificate.  \n4.5 RATIO NALE FOR LAYERED ENCRYPTION  \n4.6 AUTHENTICATION  \nThe WLAN solution provides mutual device authentication between WLAN Access System and between \nInner Encryption Components via public key certificates.  This CP requires that all authentication \ncertificates issued  to WLAN Access System and Inner Encryption Components be Non -Person Entity \n(NPE) certificates.  In addition, NPE certificates issued to WLAN Access Systems may need to assert the \nIP address of the WLAN Access System in either the Common Name field of the certificate Distinguished11 \n Name, or in the Subject Alternative Name certificate extension.  The EUD may be required to check the \nIP address asserted in the WLAN Access System certificate and ensure it is the same IP address \nregistered in the EUD.  \n4.6.1  TRADITIONA L AUTHENTICATION  \nFollowing the two layers of device authentication, EUDs require the user to authenticate to the network \nbefor", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}833{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "39", "chunk": "e gaining access to any classified data (e.g., username/password, user certificate).  When a device \ncertificate is used, the user must also authenticate to the Red Network before gaining access to any \nclassified data in the same manner as a EUD (e.g., username/password, user certificate).  In this latter \ncase, it is recommended that additional access controls, such as allowlists, be implemented in \nconjunction with the user certificate to control access to Red Network services.  \nIn addition to authentication for the Outer and Inner layer of encryption, the WLAN CP requires user -to-\ndevice authentication.  This authentication occurs betwe en the user and the Computing Device (which \nprocesses Red data) of an EUD.  The WLAN CP requires EUD components use a minimum of a 14 -\ncharacter, case -sensitive, alphanumeric password to authenticate to the device.  This password can be \nused both for decryp ting the platform encryption as well as for unlocking the screen.  EUD components, \nwhich are selected from the Mobile Platform section of the CSfC Components List, are able to use a \nrelatively short authentication factor since they use a hardware based roo t encryption key which is \nevaluated during the NIAP certification.  \n4.6.2  TWO FACTOR AUTHENTICATION  \nFor this CP, the curren", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}834{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "40", "chunk": "t two -factor authentication options are, \u201csome thing you know\u201d and \u201csomething \nyou have.\u201d   There are tw o scenarios within the WLAN CP for whi ch two-factor authentication has been \ntested.   The areas are \u201cUser -to-EUD\u201d and \u201cEUD -to-Infrastructure.\u201d   The authentication token must be \nstored in a physically separate storage container from the EUD when both devices are securely stored.  \nCurrently, the CSfC Program anticipates two factor authentication requirements will become threshold, \nonce the NIAP Protection Profiles are updated to support two factor capabilities.  \n4.6.2.1  User to EUD  \n\u201cUser -to-EUD\u201d is defined as using a second factor of authentication to lo gin to the device.   This could be \naccomplished using a smart card with an identity PKI cert (something -you-have) and a passphrase \n(something -you-know).   This could also be accomplished with a passphrase (something -you-know) and \nthe second factor will be a \u201csomething you have\u201d factor manifesting as a physically separate token from \nthe EUD, supplying a one -time password for the user to enter.  The passphrase in both cases must still \nmeet the complexity and length requirement specified in WLAN -EU-23.  For futu re versions of the WLAN \nCP, transferring this one -time password via a short -range RF communica", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}835{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "41", "chunk": "tion will be examined.   \n4.6.2.2  EUD to Infrastructure  \nThis use  case applies  to EUD authentication.   \u201cEUD -to-infrastructure\u201d is defined as using a second factor \nof authentication to the Inner VPN tunnel.  This could be accomplished as follows: The first factor will be \nthe certificate that is on the device.   The second factor will be a \u201csomething you have\u201d factor \nmanifesting as a physically separate token from the VPN EUD supplying a one -time password for the \nuser to enter.  Adding a second factor of authentication to the solution prevents continued access to a12 \n network if an EUD is com promised as a result of an attack.   If a device has been compromised, it can be \nassumed that the certificates used to authenticate to the enterprise would be accessible to an adversary \nto be  used on a legitimate device or  extracted and used on a different device, masquerading as the \nuser.   If an adversary has managed to compromise the certificates on an EUD, adding a second \nauthentication factor prevents persistent access to a network.  \n4.7 OTHER PROTOCOLS  \nThroughout this document, when IP traffic is discussed, it can refer to either IPv4 or IPv6 traffic, unless \notherwise specified, as the WLAN solution is agnostic to most named data handling protocols.  \nPublic standar", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}836{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "42", "chunk": "ds conformant Layer 2 control protocols are allowed as necessary to ensure the \noperational usability of the network.  This CP is agnostic with respect to Layer 2; specifically, it does not \nrequire Ethernet.  Public standards conformant Layer 3 control protocols may be allowed based on local \nAO p olicy, but the default configuration of this solution is for all Layer 3 control protocols to be disabled. \nRed and Gray Network multicast messages and Internet Group Management Protocol (IGMP) or \nMulticast Listener Discovery (MLD) may also be allowed, depe nding on local AO policy.   \nIt is expected that the WLAN solution can be implemented in such a way as to take advantage of \nstandards -based routing protocols that are already being used in the Red Network.  For example, \nnetworks that currently use Generic R outing Encapsulation (GRE) or Open Shortest Path First (OSPF) \nprotocols can continue to use these in conjunction with the Inner Firewall solution to provide routing as \nlong as the AO approves their use.  \nFuture iterations of this CP will discuss using diffe rent wireless standards other than 802.11 Wi -Fi if the \nstandard still implements the WPA3 standard.  \n4.8 AVAILABILITY  \nThe high -level designs described in Section 4.2 are not designed to automatically provide high ", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}837{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "43", "chunk": "\navailability.  Supporting solution implementatio ns for which high availability is important is not a goal of \nthis version of the CP.  However, this CP does not prohibit adding redundant components in parallel to \nallow for component failover or to increase the throughput of the WLAN solution, as long as each \nredundant component adheres to the requirements of this CP.  The CP does not limit the number of \nWLAN Access Systems or Inner Encryption Components that can be implemented for high availability in \na WLAN Solution.  \n5 INFRASTRUCTURE COMPO NENTS  \nIn the high -level design discussed in the previous section, at least two layers of encryption, implemented \nusing WPA3 and an Inner layer of IPsec encryption, protect all communications flowing across a Black \nNetwork.  Mandatory aspects of the solution infrastructure also include administration workstations, \nIDS/IPS, SIEM, firewalls, and CAs for key management using PKI.  \nEach infrastructure component is described in more detail below.  The descriptions include information \nabout the security provided by the components a s evidence for why they are deemed necessary for the \nsolution.  Components are selected from the CSfC Components List and configured per NIAP13 \n configuration guidance in accordance with the Product Selec", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}838{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "44", "chunk": "tion requirements of this CP (see Section  \n11). \nSection 11 also provides details on additional components that can be added to the solution to help \nreduce the overall risk.  Where indicated in the text, these are not considered mandatory components \nfor the security of the solution; therefore, this CP does not p lace configuration requirements on those \noptional components.  \n5.1 WLAN  ACCESS SYSTEM  \nIn the context of this solution, the AP and the WLAN Controller, compose the \u201cWLAN Access System.\u201d \nThese components are grouped together in this document to maintain vendor ne utrality; there are a \nvariety of WLAN Access System implementations across the vendor community. The WLAN Access \nSystem must be configured to use WPA3 Enterprise 192 -bit mode, using AES 256, for CNSA compliance.  \nAn AP is the media converter providing a lin k between the WLAN Client and the WLAN Controller.  The \nlevel of functionality contained within the APs is vendor -dependent.  Some solutions use \u201csmart\u201d or \n\u201cthick\u201d APs that incorporate a significant amount of functionality, including cryptographic operatio ns.  In \nthis case, the APs would be considered part of the Gray Network.  Other solutions implement \u201cthin\u201d APs \nthat merely perform the wireless/wired media conversion and push all functionali", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}839{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "45", "chunk": "ty to the WLAN \nController.  In this case, the APs would be consid ered part of the Black Network.  If the access point is in \nthe Black Network it has to be physically protected and access to the console port may need to be \nlimited (e.g., tamper tape), or the port deactivated.  Some vendors may produce both solutions.  If  \nWPA3 terminates on APs rather than on the WLAN Controller, then the connection between the APs and \nthe WLAN Controller must be encrypted in a manner leveraging IPsec, SSHv2, TLS, or TLS/HTTPS.  If \nWPA3 terminates on the WLAN Controller, then the WPA3 encr yption is used to protect the connection \nbetween the APs and the WLAN Controller.  \nThe WLAN Access System must be capable of initiating and terminating multiple cryptographic tunnels \nto and from numerous Wireless Clients.  It must also be capable of transla ting EAP -TLS over 802.1X \nmessages to EAP -TLS over Remote Authentication Dial in User Service (RADIUS) messages to pass \nauthentication information between the WLAN Client and WLAN Authentication Server.  This exchange \ninvolves a Pairwise -Master Key (PMK) th at is negotiated between the WLAN Client and the WLAN \nAuthentication Server.  The WLAN Authentication Server passes the PMK to the WLAN Access System \nover an IPsec tunnel or TLS/RADsec tun", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}840{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "46", "chunk": "nel.  The Wireless Controller and the WLAN Client use the PMK \nto neg otiate a session key to protect the subsequent user traffic exchanged between the WLAN Client \nand the WLAN Access System.  As mentioned above, the WLAN Access System should operate on its \nown separate hardware and/or virtual device(s), depending on the ven dor implementation.  This \nseparation may include isolating the switches and wiring between the APs and the controller from any \nexisting network.  At the very least, the WLAN Access System and the VPN Gateway must operate on \nseparate hardware.  Since the WL AN Access System is deployed between the Black Network and the \nGray Network, it is essential to implement port filtering on the WLAN Access System\u2019s Gray Network \ninterface to prevent unauthorized traffic.  Traffic should be restricted using configuration r equirements \nstated in Section  12.7 .14 \n 5.2 GRAY FIREWALL  \nThe Gray Firewall is located between the WLAN Access System and Inner Encryption Components.  In \naddition to filtering EUD traffic, the Gray Firewall also provides packet filtering for the Gray \nManagement S ervices.  \nThe external interface of the Gray Firewall should only accept packets with a source address of the \nWLAN Access System\u2019s IP pool assigned to EUDs.  The internal interfa", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}841{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "47", "chunk": "ce of the Gray Firewall should only \naccept packets with a source address of th e Inner VPN Gateway as part of an established \ncommunication session.  When supporting multiple security levels the Gray Firewall must also ensure \nthat only EUDs and Inner Encryption Components of the same security level are able to communicate. \nOnce succes sfully authenticated, the Authentication Server then passes the attribute information \nassociated with the EUD\u2019s enclave to the WLAN Access System as part of the EAP -success packet.  The \nWLAN Controller uses the attribute information received from the Authe ntication Server to ensure they \nare placed on the proper Gray Network for their enclave and receive the correct Firewall Access Control \nList (ACL) rules.  \nIn addition to EUD data traffic, the Gray Firewall adjudicates traffic related to both the management of \nthe Gray boundary and EUD control plane traffic.  As shown in Figure 5, the Gray Firewall, selected from \nthe CSfC Components List, must be physically separate from the WLAN Access System and Inner \nEncryption Components.  \n5.3 INNER FIREWALL  \nThe Inner Firewall  is located between the Inner Encryption Components and the Red Network.  The \nexternal interface of the Inner Firewall should only accept inbound traffic with a source add", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}842{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "48", "chunk": "ress of the \nInner VPN Component.  The internal interface of the Inner Firewall should  only allow outbound traffic \nfrom the Red enclave to the Inner VPN Component.  \nThe Inner Firewall, selected from the CSfC Components List, must be physically separate from the Inner \nEncryption Components.  \n5.4 GRAY MANAGEMENT SERVICES  \nSecure administration of c omponents in the Gray Network and continuous monitoring of the Gray \nNetwork are essential roles provided by the Gray Management Services.  The Gray Management \nServices are composed of multiple components that provide distinct security to the solution.  The  WLAN \nCP allows flexibility in the placement of some Gray Management Services.  All components within the \nGray Management Services are either directly or indirectly connected to the Gray Firewall (i.e., multiple \nGray Management Services connected to a swit ch which is connected to the Gray Firewall).  The Gray \nManagement Services are physically protected as classified devices.15 \n  \nFigure 5. Overview of Gray Management Services  \nFigure 5 shows the infrastructure components of the Gray Management Services in the  WLAN Solution.  \nWithin the Gray Network, which is between the WLAN Access System and Inner Encryption \nComponents, there is an Administration workstation, SIEM, ", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}843{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "49", "chunk": "Authentication Server, and DNS.  \nComponents within the Gray Network are further described below . \n5.4.1  GRAY ADMINISTRATION WORKSTATION  \nGray administration workstations maintain, monitor, and control all security functions for the WLAN \nAccess System, Gray Firewall, and all Gray Management service components.  These workstations are \nnot permitted to maintai n, monitor, or control Inner Encryption Components or Red Management \nServices.  All WLAN solutions will have at least one Gray administration workstation.  Section 7 provides \nmore detail on management of WLAN solution components.  \nThe WLAN Access System, WL AN Authentication Server, and the WLAN Client must have an \nadministration workstation on the Gray Management network to maintain, monitor, and control all \nsecurity functionality for those devices.  The administration devices for the VPN are located on the Red \nNetwork.  These administration devices must also allow for logging and configuration management, as \nwell as reviewing audit logs.  Given the architecture of the solution, there are distinct administration \nnetworks for the WLAN Access System and VPN Gat eway devices.  Layer 3 routing between \nmanagement and data networks must be prohibited to maintain strict separation between management \nand data traffic.", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}844{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "50", "chunk": "  \nAdministration Workstations must be dedicated for the purposes given in the CP, and must not be used \nto manage any non -CSfC solutions.  As such, a dedicated virtual machine on an administration device \nused for non -CSfC solutions cannot be used to manage CSfC solutions.16 \n 5.4.2  GRAY SECURITY INFORMATION AND EVENT MANAGEMENT (SIEM)   \nThe Gray SIEM collects and analy zes log data from the WLAN Access System, Gray Firewall, and other \nGray Management Service components.  Log data may be encrypted between the originating \ncomponent and the Gray SIEM with SSHv2, TLS, or IPsec to maintain confidentiality and integrity of the  \nlog data.  At a minimum, an auditor reviews the Gray SIEM alerts and dashboards daily.  The SIEM is \nconfigured to provide alerts for specific events including if the WLAN Access System or Gray Firewall \nreceives and drops any unexpected traffic which could  indicate a compromise of the WLAN Access \nSystem.  These functions can also be performed on a Red SIEM if a CDS is used as described in the CSfC \nContinuous Monitoring Annex . \n5.4.3  GRAY AUTHENTICATION SERVER  \nThe Authentication Server is used to authenticate EUDs  attempting to gain access to a Campus WLAN \nsolution.  The WLAN Authentication Server performs device authentication during the 802.1", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}845{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "51", "chunk": "X exchange.  \nThe Wireless Client and WLAN Authentication Server perform an EAP -TLS over RADIUS exchange using \nthe 802.1X pr otocol, with the WLAN Access System acting as a pass -through.  As part of this exchange, a \nPMK is negotiated between the WLAN Client and the WLAN Authentication Server.  The WLAN \nAuthentication Server passes this key to the WLAN Access System in accordance  with Wireless \nInfrastructure Authentication requirements (WLAN -IA-1 and WLAN -IA-2) to protect the subsequent user \ntraffic exchanged between the WLAN Client and the WLAN Access System.  The WLAN Authentication \nServer must operate on a separate hardware dev ice from the WLAN Access System.  \nCampus WLAN solutions that support more than one enclave include additional requirements on the \nauthentication Server to ensure that EUDs are only permitted access to the correct network that directs \nthe traffic to the appr opriate Inner VPN Gateway.  There are two acceptable approaches to ensure that \nEUDs are only permitted access to their assigned domain.  The first is to maintain an allowlist of devices \nand the enclave for which each device is provisioned.  This allowlist can be saved in a database on the \nAuthentication Server or can be retrieved from a separate server that resides in the Gray Network", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}846{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "52", "chunk": ".  The \nsecond approach is to use information in the certificate of each EUD to make the access decision.  \nSpecifically, custo mers can use fields in the Distinguished Name of the Certificate (e.g., Organizational \nUnit Field) or use registered Policy Object Identifiers to assign EUDs to the appropriate domain.  Use of \nPolicy Object Identifiers (OIDs) is the preferred approach if s upported by the Authentication Server and \nPKI. \nThe Gray authentication server is only required for solutions supporting multiple security levels.  The \nauthentication server is responsible for performing mutual authentication with EUDs using the WLAN \nAccess  System as an EAP pass -through.  In addition to verifying that certificates are signed by the correct \nCA, are within their validity period, and are not revoked, the authentication server parses the certificate \nfor information (e.g., OU field or Policy OID)  that is associated with the Red Network with which the EUD \nis permitted to establish an Inner IPsec connection.  Upon successful authentication of the EUD, the \nauthentication server sends an Access -Accept packet to WLAN Access System.  The Access -Accept \npacket includes an attribute derived from the OU or policy OID which the WLAN Access System uses to \napply ACLs and route the EUDs t", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}847{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "53", "chunk": "raffic to the proper Inner Encryption Component.17 \n 5.5 INNER ENCRYPTION COMPONENTS  \nThe WLAN CP allows for the use of one type of Inn er Encryption Component: Inner VPN Gateway.   Inner \nVPN Gateways are always located between the Gray Firewall and Inner Firewall.  An Inner VPN Gateway \nwill always have at least two interfaces, one external interface connected to the Gray Firewall and one \ninternal interface connected to the Inner Firewall.  \nAn Inner VPN Gateway with multiple interfaces has one external interface connected to the Gray \nFirewall and one internal interface connected to the Inner Firewall.  If implemented with a single data \nplane interface, then that interface establishes the Inner layer of encryption and provides the classified \ndata to the EUD.  Inner VPN Gateways are always managed from the Red Management Services.  The \nmanagement interface of the Inner VPN Gateway can either be connected to the Inner Firewall or run \ndirectly to a standalone Red Management Services enclave.  \nMultiple Inner Encryption Components are acceptable, provided they comply with the requirements of \nthis CP.  \n5.5.1  INNER VPN  GATEWAY  \nThe Inner VPN Gateway provides authentication of peer VPN Components, cryptographic protection of \ndata in transit, and configuration and enforcem", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}848{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "54", "chunk": "ent of network packet handling rules.  The Inner VPN \nGateway is located between the Gray firewall and the Inner Firewall.  The Inner VPN Gatew ay is required \nto be implemented if supporting VPN EUDs.  \nThe external interface of the Inner VPN Gateway is connected to the internal interface of the Gray \nFirewall.  The VPN Gateway establishes an IPsec tunnel with peer Inner VPN Components.  The external  \ninterface of the Inner VPN Gateway only permits the egress of IPsec traffic and AO -approved control \nplane traffic.  The internal interface of the Inner VPN Gateway is configured to only permit traffic with \nan IP address and port associated with Red Networ k services.  \nThe Inner VPN Gateway cannot route packets between Red and Gray Networks.  Any packets received \non a Red Network interface and sent to a Gray Network interface must be transmitted within an IPsec \nVPN tunnel that is configured according to this CP.  The Inner VPN Gateway, selected from the CSfC \nComponents List, must be physically separate from the Gray Firewall and Inner Firewall.  \n5.6 RED MANAGEMENT SERVICES  \nSecure administration of Inner Encryption Components and continuous monitoring of the Red Ne twork \nare essential roles provided by the Red Management Services.  Red Management Services are composed \nof", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}849{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "55", "chunk": " a number of components that provide distinct security to the solution.  The WLAN CP allows flexibility \nin the placement of some Red Management Servi ces as described below.18 \n  \nFigure 6. Overview of Red Management Services  \nFigure 6 shows the infrastructure components of the Red Management Services in the WLAN Solution.   \nThe Red Network, located beyond the Inner Encryption Components, has management services \ncomponents.  Each of the management services components are described below.  \n5.6.1  RED ADMINISTRATION WORKSTATIONS  \nThe Red administration workstation maintains, monitors, and controls all security functionality for the \nInner E ncryption Components, Inner Firewall, and all Red Management service components.  The Red \nadministrative workstations are not permitted to maintain, monitor, or control Outer Encryption \nComponents or Gray Management Services.  All WLAN solutions will have at least one Red \nadministrative workstation.  Section 7 provide s more detail on management of WLAN solution \ncomponents.  \n5.6.2  RED SECURITY INFORMATION AND EVENT MANAGEMENT (SIEM)   \nRed SIEMs collect and analyze log data and flow data from the Inner Encryption Com ponents, the Inner \nFirewall, and other Red Management Service components.  Log data may be encrypted between the \nori", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}850{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "56", "chunk": "ginating component and the Red SIEM with SSHv2, TLS, or IPsec to ensure confidentiality and \nintegrity.  The SIEM is configured to provide al erts for specific events.  Customers are encouraged to \nleverage existing Enterprise SIEM capabilities to monitor log data from Inner Encryption Components, \nthe Inner Firewall, and Red Management Services.  A Red SIEM may also be used to analyze log data \nfrom Gray Network components when used in conjunction with an approved CDS, as described in the \nCSfC Continuous Monitoring Annex . \n5.7 PUBLIC KEY INFRASTRUCTURE COMPONENTS  \nKey Management Requirements have been relocated to a separate CSfC Key Management Requireme nts \nAnnex .19 \n 6 END USER DEVICE COMP ONENTS  \n6.1  END USER DEVICE  \nThe EUD is a commercial tablet, laptop computer, smartphone, or similar computing device that \nsupports Wi -Fi connectivity options.  \nFigure 7 shows the software architecture of a typical EUD.  The VPN C lient and WLAN Client run as \noperating system processes and exist to perform authentication and key establishment for the IPsec \nmodule and WPA3 driver respectively.  \nEUDs use WPA3 using a WLAN Client (also known as WPA supplicant) to provide the Outer laye r of \nencryption.  The WLAN Client establishes an encrypted connection to the WLAN Access System", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}851{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "57", "chunk": ".  The \nconnection can be configured to automatically be established as part of the EUD\u2019s power -on process.  \nOnce connected to the WLAN Access system, the EUD can  establish the Inner IPsec tunnel.  The private \nkeys and certificates used for the authentication of the WLAN Access System are considered Controlled \nUnclassified  Information (CUI) and must be, at a minimum, protected by enabling the native platform \nDAR pr otection.  \nA VPN Client must be used as the Inner VPN Component for EUDs.  The Inner VPN Client establishes an \nIPsec tunnel to the Inner VPN Gateway of the WLAN Solution Infrastructure.  The tunnel can be \nconfigured to automatically be established as part of the EUD\u2019s power -on process.  A combination of the \nVPN Client and the Operating System on which it is installed, provides configuration and enforcement of \nnetwork packet handling rules for the Inner layer of encryption.  The Inner VPN Client is selected from \nthe IPsec VPN Client section of the CSfC Components list.  The VPN Client is installed on the Computing \nDevice selected from the Mobile Platform  section of the CSfC Components List.  The private keys and \ncertificates used for the authentication of the  Inner VPN Gateway are considered CUI and must be, at a \nminimum, protected by enabling the nat", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}852{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "58", "chunk": "ive platform DAR protection.  \nVirtualization should be used when a WLAN Client and Inner VPN Client both reside on the same \nComputing Device.  Use of virtualizati on ensures that two separate IP stacks are used.20 \n  \n Figure 7. Campus WLAN End User Device Architecture  \n6.1.1  END USER DEVICE  \nThe EUD consists of the hardware and software components (Operating System (OS), VPN client, WLAN \nClient, and applications) that provide a variety of security services.  The EUD is to be used exclusively \nwithin physically secure environments, such as facil ities and tactical environments with physical controls \nconsidered appropriate by the AO.  \n6.2 WLAN  CLIENT  \nThe WLAN Client is a software application running on the EUD that provides management and control of \nthe wireless connection.  The products chosen to imp lement the WLAN Client services must provide a \nbase level of protection and should be able to interoperate with products from other vendors.  The \nproducts must also provide cryptographic and functional services that meet or exceed the requirements \nlisted i n Section 12 for the WLAN Client.  The WLAN Client automatically establishes the WPA3 tunnel \nbetween the EUD and the WLAN Access System using EAP -TLS over 802.1X to pass Public Key device \ncertificates for mutual a", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}853{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "59", "chunk": "uthentication between the WLAN Client and W LAN Authentication Server.21 \n 6.3 VPN  CLIENT  \nThe VPN Client is a software application running on the EUD.  The products chosen to implement the \nVPN services must provide cryptographic and functional services that meet or exceed the requirements \nlisted in Section 12 for the VPN Client.  \nThe VPN Client establishes an IPsec tunnel to the VPN Gateway.  The VPN Client first performs an \nInternet Key Exchange (IKE) with the VPN Gateway to authenticate both parties and exchange session \nkeys for the IPsec tunnel.  Authentication is performed via mutual authentication of Public Key device \ncertificates.  When IKE completes, the IPsec tunnel is secured using the ESP.  The Inner VPN Tunnel must \nuse Tunnel Mode IPsec or Transport Mode IPsec using an associated IP tunneli ng protocol (e.g., \nTransport Mode IPsec with GRE).  \n6.4 ENHANCED ISOLATION     \nIn this CP, the EUD relies on a single operating system to conn ect to the WLAN Access System, the Inner \nEncryption Component and user space.   To create an additional layer of securit y, this function of the \nEUD may be isolated on the EUD.  This isolation is achieved through the use of hypervisor and virtual \nmachine technologies on the EUD.   \n \nFigure 8. Enhanced Software Virtualization ", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}854{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "60", "chunk": "Architecture  \n6.4.1  SOFTWARE VIRTUALIZATION  \nVirtualized EUDs use a type 1 hypervisor running directly on the hardware to create multiple isolated \nand stand -alone domains on a single EUD.  The most common form of one of these domains is a virtual \nmachine (VM).  The isolated domains all ow multiple parts of a Campus WLAN EUD to be built securely22 \n into a single piece of hardware.  They also ensure that separate IP stacks are used for each connection \nlayer.  The hypervisor also provides the virtual networks that are used by the domains for t he internal \nnetwork connectio ns required for the dual layer WLAN connection.  \nEach isolated domain should include the following subdomains: 1) a user domain where the user can \ninteract with the EUD and, 2) a transport domain  to connect the WLAN Access Syste m and, 3)  a \ntransport domain to connect to the Inner VPN Gateway.  \nEnd users should only be able to access end user domains.  Other domains should be managed by an \nadministrator.  Additional domains/VMs can also be added for device management functions.  \n7 CAMPUS WLAN CONFIGURAT ION AND MANAGEMENT  \nThe Campus WLAN CP includes design details for the provisioning and management of Solution \nComponents.  The CSfC solution owner must identify authorized Security Administrator", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}855{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "61", "chunk": "s (SAs) to \nperform con figuration and manag ement tasks .  The following sections describe the design in detail and \nSection 12 articulates specific configuration requirements that must be met to comply with the WLAN \nCP. \n7.1 SOLUTION INFRASTRUCTURE COMPONENT PROVISIONING  \nProvisioning is an out -of-band pro cess performed in a physically secured area (e.g., Red Network), \nthrough which WLAN solution infrastructure components are configured and initialized before their first \nuse.  During the provisioning process, the SA configures the WLAN Access System, Gray M anagement \nServices, Inner Encryption Components, and Red Management Services in accordance with the \nrequirements of this CP.  \nDuring provisioning, the WLAN Access System and Inner Encryption Components generate a \npublic/private key pair and output the publ ic key in a Certificate Signing Request (CSR).  The SA delivers \nthe WLAN Access System\u2019s CSR to the Outer CA and the Inner Encryption Components\u2019 CSR to the Inner \nCA.  The appropriate CA processes the CSR for each encryption component and returns a signed X.509 \ncertificate.  The SA then installs the unique signed certificate and the certificate chain, which consists of \nthe signing CA's certificate and the Trust Anchor certificate (e.g., Root CA certificate). ", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}856{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "62", "chunk": " The SA may also \ninstall an initial Certificate R evocation List (CRL).  \n7.2  EUD  PROVISIONING  \nInitial provisioning of campus EUD will be performed using enrollment capabilities hosted in the Red \nNetwork and leveraging the Outer and Inner CAs.  To support different device types, it may be necessary \nto support both wireless and wired connection capabilities to the EUD being provisioned.  Since keying \nand secure applications needed to connect to the operational WLAN Access System have not yet been \nestablished, wireless provisioning connectivity must be performed on a separate WLAN Access System in \na shielded enclosure.  The provisioning process includes assigning identifiers to the devices, installing \nrequired applications, configuring the device\u2019s policy and settings (especially WPA3 and IPsec settings), \nand load ing certificates and keying material.  Prior to provisioning devices, configuration profiles are \ncreated and required device applications are obtained.   \nInitial provisioning (for all device types) should include the following, in no specific order:23 \n \uf0b7 Device  registration .  Collect identifying information from the EUD, assign Government device \nidentities for the Gray and Red domains, and update data stores (directory, inventory, and/or \nauthorization) ", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}857{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "63", "chunk": "to include new EUD.  \n\uf0b7 Settings configuration .  Load configurat ion (within the limitations of what is supported by each \ndevice type) that implement policies on allowed and disallowed services (such as Bluetooth) and \nuser authentication parameters (such as password length and when to lock the device).  Supply \nother set tings such as network parameters.  \n\uf0b7 Application installation .  Load required applications, including the VPN client and enterprise \nclient applications (there is no current support for an online application store, so all applications \nshould be loaded during i nitial provisioning).  If possible, unneeded applications should be \nremoved from the device.  \n\uf0b7 Certificate request and issuance .  Using the assigned Government device identifiers, connect to \nthe Gray Network, request certificates from the Outer CA, and load received material into the \nEUD.  Disconnect the device from the Gray Network, connect to the Red Network, request \ncertificates from the Inner CA, and load received material into the EUD.  Note: It is possible for \nboth CAs to reside on the Red Network.  \nDepe nding on the capabilities of the EUD, the device either connects and interacts with the CAs in order \nto be issued certificates, or the certificates are generated and loaded onto a devi", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}858{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "64", "chunk": "ce storage medium \nfrom a provisioning workstation for transfer to the EU D.  There will also be differences based on \nwhether the EUD generates and provides a private key for the certificate or is issued one from the CA \n(more secure handling and transfer is required for the latter case).  Finally, some devices may require \nthat c ertificate provisioning be performed using a wireless connection.  In the event that a device can \nonly support wireless certificate provisioning, the certificate provisioning must be performed in a \nshielded enclosure deemed appropriate by the AO.  \nOnce the  EUD is properly configured and certificates/keying material is in place, it is ready to be issued \nto a user with the final steps of establishing user login and associating the user with the device in the \nregistration data.  Once the device is connected to  the Red Network, the device is classified.  \n7.3 MANAGEMENT OF CAMPUS WLAN  SOLUTION COMPONENTS  \nManagement of all Campus WLAN solution components is always encrypted to protect confidentiality \nand integrity, except in the case where components are locally manage d through a direct physical \nconnection (e.g., serial cable from the Gray Administration Workstation to the WLAN Controller).  \nManagement traffic must be encrypted with SSHv2, TLS", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}859{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "65", "chunk": ", or IPsec.  \nThe requirements for configuring the EUDs in Section 12.2  can be accomplished through a variety of \nmechanisms.  First, the EUDs can be configured using Mobile Device Management (MDM) selected from \nthe CSfC Components List.  Alternatively, the EUD can be configured using a provisioning tool which \nenforces configuration p olicies during initial setup, and must be brought back to a Security \nAdministrator to be updated.  Customers can also configure the EUD using an existing Enterprise Policy24 \n enforcement mechanism.  Finally, customers can choose to use a hybrid approach with more than one \nof the above options.  \n7.4 EUD S FOR DIFFERENT CLASSIFICATION DOMAINS  \nAs specified in this CP, an EUD is only authorized to communicate with Red Networks operating at the \nsame classification level.  Implementation of the Multiple Security Levels d esign does not change the \nrequirement for EUDs to be dedicated to a single classification level.  However, the CP does not preclude \nthe possibility that an approved CDS can be used within an infrastructure to provide cross domain \ntransfer of data between E UDs operating at differing classification levels.  It also does not preclude the \nuse of an EUD as an access CDS for multiple enclaves operating at different classification", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}860{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "66", "chunk": " levels if \napproved through the appropriate CDS approval process.  \nThe requirements fo r a CDS capable of providing separation between enclaves of two or more \nclassification levels are outside the scope of this CP.  If developing a WLAN solution with a CDS \ncapability, the solution owner must register against this CP and use the appropriate C DS approval \nprocesses.  \n8 CONTINUOUS MONITORIN G \nThe Campus WLAN CP allows customers to use EUDs from physical environments residing within a \ngovernment secure facility.  Today\u2019s technology provides increased accessibility to various networks, \nwhich creates a need to continuously monitor network traffic and system log data within the solution \ninfrastructure.  This monitoring allows customers to detect, react to, and report any attacks which occur \non or against their solution.  This continuous monitoring also en ables the detection of any configuration \nerrors in solution infrastructure components.   \nContinuous Monitoring requirements have been relocated to the CSfC Continuous Monitoring Annex .  \nFigure 9 shows the monitoring points in the CSfC Continuous Monitoring  Annex  for Campus WLAN CP.25 \n  \nFigure 9. Campus WLAN Continuous Monitoring Points  \n8.1 WIRELESS INTRUSION DETECTION SYSTEM (WIDS)  \nA  Wireless Intrusion Detection", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}861{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "67", "chunk": " System consists of a group of sensors (preferably some dedicated) and a \ncentral controller working together to provide 24/7 monitoring of the wireless spectrum to detect \nunauthorized or malicious WLAN activity.  WIDS require ments have been relocated to the CSfC Wireless \nIntrusion Detection System/Wireless Intrusion Prevention System (WIDS/WIPS) Annex.   \n9 KEY MANAGEMENT  \nKey Management Requirements have been relocated to a separate CSfC Key Management Requirements \nAnnex . \n10 REQUIREM ENTS OVERVIEW  \nThe following five sections (Section 11 through Section  15, and the CSfC Key Management Requirements \nAnnex ) specify requirements for implementations of WLAN solutions compliant with this CP.  However, \nnot all requirements in the following sec tions will apply to each compliant solution.  \n10.1 THRESHOLD AND OBJECTIVE REQUIREMENTS  \nIn some cases, multiple versions of a requirement may exist in this CP.  Such alternative versions of a \nrequirement are designated as being either a Threshold requirement or an Objective requirement:  \n\uf0b7 A Threshold (T) requirement specifies a feature or function that provides the minimal acceptable \ncapability for the security of the solution.26 \n \uf0b7 An Objective (O) requirement specifies a feature or function that provides the preferred  \ncap", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}862{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "68", "chunk": "ability for the security of the solution.  \nIn general, when separate Threshold and Objective versions of a requirement exist, the Objective \nrequirement provides a higher degree of security for the solution than the corresponding Threshold \nrequirement.  However, in these cases meeting the Objective requirement may not be feasible in some \nenvironments or may require components to implement features that are not yet widely available.  \nSolution owners are encouraged to implement the Objective version of a re quirement, but in cases \nwhere this is not feasible solution owners may implement the Threshold version of the requirement \ninstead.  These Threshold and Objective versions are mapped to each other in the \u201cAlternatives\u201d \ncolumn.  Objective requirements that h ave no related Threshold requirement are marked as \u201cOptional\u2019 \nin the \u201cAlternatives\u201d column.  \nIn most cases, there is no distinction between the Threshold and Objective versions of a requirement.  In \nthese cases, the \u201cThreshold/Objective\u201d column indicates th at the Threshold equals the Objective (T=O).  \nRequirements listed as Objective in this CP may become Threshold requirements in a future version of \nthis CP.  Solution owners are encouraged to implement Objective requirements where possible in order \nto facil itat", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}863{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "69", "chunk": "e compliance with future versions of this CP.  \n10.2 REQUIREMENTS DESIGNATORS  \nEach requirement defined in this CP has a unique identifier consisting of the prefix \u201cWLAN,\u201d a digraph \nthat groups related requirements together (e.g., \u201cKM\u201d), and a sequence number (e.g., 11).  \nTable 1 lists the digraphs used to group together related requirements and identifies the sections in \nwhich those requirement groups can be found.  \nTable 1. Requirement  Digraph  \nDigraph  Description  Section  Table  \nPS Product Selection Requirements  Section 11 Table 2 \nSR Overall Solution Requirements  Section 12.1  Table 3  \nEU End User Device Requirements  Section 12.2  Table 4  \nVZ Enhanced Virtualization Requirements  Section 12.3  Table 5  \nWC WLAN Client Configuration Requirements  Section 12.4  Table 6  \nWL Wireless Link Requirements  Section 12.4  Table 7  \nCR VPN Components Configuration Requirements  Section 12.5  Table 10  \nWS WLAN Access System Configuration Requirements  Section 12.6  Table 11  \nIA Wireless Infrastructure Authentication Requirements  Section 12.6  Table 12  \nAA Wireless Authentication and Authorization Requirements  Section 12.6  Table 13  \nWA Wireless Authentication Server to WLAN Client \nRequirements  Section 12.6  Table 14  \nPF Solution Components Port Filtering Requirem", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}864{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "70", "chunk": "ents  Section 12.7  Table 15  \nPR End User Device Provisioning Requirements  Section 12.8  Table 16  \nDM Device Management Requirements  Section 12.11  Table 18  \nFW Gray Firewall Requirements  Section 12.15  Table 21  \n2F Two Factor Authentication Requirements  \n(EUD -to-Infrastructure)  Section 12 .16 Table 2227 \n Digraph  Description  Section  Table  \n2F Two Factor Authentication Requirements  \n(User -to-EUD)  Section 12.1 7 Table 23  \nGD Use and Handling of Solutions Requirements  Section 13.1  Table 24  \nRP Incident Reporting Requirements  Section 13.2  Table 25  \nGD Role -Based Personnel Requirements   Section 14 Table 26  \nTR Test Requirement  Section 15 .1 Table 27  \nKM Key Management Requirements (See Key Management Requirements Annex ) \nWIDS  Wireless Intrusion Detection Sy stem Requirements (See WIDS/WIPS Requirements Annex)  \nCM Continuous Monitoring Requirements (See Continuous Monitoring Requirements Annex)  \n11 REQUIREMENTS FOR SEL ECTING COMPONENTS  \nIn this section, a series of requirements are given for maximizing  the independence between the \ncomponents within the solution.  This will increase the level of effort required to compromise this \nsolution.  \nTable 2. Production Selection Requirements  \nReq #  Requirement Description  Threshold / \nObjective  Alterna", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}865{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "71", "chunk": "tive  \nWLAN -PS-1 The product used for the VPN Gateway(s) must be \nchosen from the list of IPsec VPN Gateways on the CSfC \nComponents List.  T=O  \nWLAN -PS-2 The products used for any WLAN Access System must be \nchosen from the list of WLAN Access Systems on the \nCSfC Components List.  T=O  \nWLAN -PS-3 The products used for any WLAN Client must be chosen \nfrom the list of Mobile Platforms on the CSfC \nComponents List.  All validated Mobile Platform \ncomponents include validated WLAN Client \nimplemen tations.  T=O  \nWLAN -PS-4 Products used for Mobile Platform EUDs must be \nchosen from the list of Mobile Platforms on the CSfC \nComponents List.  T=O  \nWLAN -PS-5 The products used for the Inner VPN Client must be \nchosen from the list of IPsec VPN Clients on the CSfC \nComponents List.  T=O  \nWLAN -PS-7 Withdrawn    \nWLAN -PS-8 Products used for the Gray Firewall and Inner Firewall \nmust be chosen from the list of Stateful Traffic Filtering \nFirewalls (TFFW) on the CSfC Components List.  T=O  \nWLAN -PS-9 Products used for the Authentication Server must be \nchosen from the list of Authentication Servers on the \nCSfC Components List.  T=O  \nWLAN -PS-10 The Inner VPN Gateway and the WLAN Access System \nmust either:  \n\uf0b7 come from different manufacturers, where neither \nmanufacturer is a ", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}866{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "72", "chunk": "subsidiary of the other; or,  T=O28 \n Req #  Requirement Description  Threshold / \nObjective  Alternative  \n\uf0b7 be different products from the same manufacturer, \nwhere NSA has determined that the products meet \nthe CSfC criteria for implementation independence.  \nDifferences between Service Packs (SP) and version \nnumbers for a particul ar vendor\u2019s OS do not provide \nadequate diversity.  \nWLAN -PS-11 The WLAN Access System, Gray Firewall, Inner VPN \nGateway and Inner Firewall must use physically separate \ncomponents, such that no component is used for more \nthan one function.  T=O  \nWLAN=PS -12 Requirement has been relocated to the CSfC Key \nManagement Requirements Annex .   \nWLAN -PS-13 The EUD\u2019s VPN Client and WLAN Client must either:  \n\uf0b7 come from different manufacturers, where neither \nmanufacturer is a subsidiary of the other; or,  \n\uf0b7 be different products from the same manufacturer, \nwhere NSA has determined that the products meet \nthe CSfC criteria for implementation independence.  T=O  \nWLAN -PS-14 The cryptographic libraries used by the WLAN Access \nSystem and the Inner VPN Gateway must either:  \n\uf0b7 come from different manufacturers, where neither \nmanufacturer is a subsidiary of the other; or,  \n\uf0b7 be different libraries from the same manufacturer, \nwhere NSA has determine", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}867{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "73", "chunk": "d that the libraries meet \nthe CSfC criteria for implementation independence.  T=O  \nWLAN -PS-15 Each component that is selected from the CSfC \nComponents List must go through a Product Supply \nChain Threat Assessment to determine the appropriate \nmitigations for the intended application of the \ncomponent per the organization\u2019s AO -approved Product \nSupp ly Chain Threat Assessment process (see CNSSD \n505 SCRM for additional guidance).  T=O  \nWLAN -PS-16 All solution components must be configured to use the \nNIAP -certified evaluated configuration from the CSfC \nComponents List.  T=O  \n12 CONFIGURATION REQUIR EMENTS  \nOnce the products for the solution are selected, the next step is setting up the components and \nconfiguring them in a secure manner.  This section consists of generic guidance on how to configure the \ncomponents of the WLAN solution.  \nCPs provide architectur e and configuration information that allows customers to select COTS products \nfrom the CSfC Components List for their solution and then to properly configure those products to \nachieve a level of assurance sufficient for protecting classified data.  The CSf C Components List consists \nof eligible COTS products identified by model/version numbers that have met appropriate Protection \nProfile requirements.29 \n T", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}868{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "74", "chunk": "his section contains requirements applicable to the Campus WLAN solution components.  In this \nsection, a se ries of overarching architectural requirements are given for maximizing the independence \nbetween the components within the solution.  This independence will increase the level of effort \nrequired to compromise this solution.  \nThe products that are approved f or use in this solution will be listed on the CSfC Components List on the \nCSfC website ( https://www.nsa.gov/resources/commercial -solutions -for-classified -program ).  No single \ncommercial product must  be used to protect classified information.  The only approved methods for \nusing COTS products to protect classified information in transit on a Campus WLAN follow the \nrequirements outlined in this CP.  \nOnce the products for the solution are selected, each product must go through a Product Supply Chain \nThreat Assessment to determine the appropriate mitigations for the intended application of the \ncomponent per the organization\u2019s AO -approved Product Supply Chain Threat Assessment process.  (See \nCNSSD 505 Suppl y Chain Risk Management (SCRM) for additional guidance.)  \n12.1 OVERALL SOLUTION REQUIREMENTS  \nTable 3. Overall Solution Requirements (SR)  \nReq #  Requirement Description  Threshold / \nObjective  Alter", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}869{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "75", "chunk": "native  \nWLAN -SR-1 Default accounts, passwords, community strings and other \ndefault access control mechanisms for all Campus WLAN \ncomponents must be changed or removed.  T=O  \nWLAN -SR-2 The time of day on Inner Encryption Endpoints, Inner \nFirewall, and Red Management Services must be \nsynchronized to a time source located in the Red Network.  T=O  \nWLAN -SR-3 The time of day on the WLAN Authentication Server, the \nWLAN Controller and Gray Network components must be \nsynchronized to a time source located in the Gray \nManagement network.  T=O  \nWLAN -SR-4 All components must be properly configured in accordance \nwith local policy and applicable U.S. Government guidance.  \nIn the event of conflict between the requirements in this CP \nand local policy, this CP takes precedence.  T=O  \nWLAN -SR-5 Solutio n components must receive virus signature updates \nas required by the local agency policy and the AO.  T=O  \nWLAN -SR-6 The only approved physical paths leaving the Red Network \nmust be through a WLAN solution in accordance with this \nCP or via an AO -approved s olution for protecting data in \ntransit. 1 T=O  \nWLAN -SR-7 All Infrastructure components must implement a \npassword/authentication with entropy of at least 95 bits.  T WLAN -SR-8 \n                                        ", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}870{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "76", "chunk": "                   \n1 In some cases, the customer will need to communicate with other sites that have NSA -certified Government off -the-\nShelf (GOTS) product .  In particular, it is acceptable for a given site to have both an egress path via an NSA -\ncertified product  and an egress path via  a CSfC Solution conforming to a CP.30 \n Req #  Requirement Description  Threshold / \nObjective  Alternative  \nWLAN -SR-8 All infrastructure components must use an authentication \nservice on their respective network/domain in order to \naccess the Infrastructure component of the respective \nnetwork/domain.  O WLAN -SR-7 \nWLAN -SR-9 When multiple Inner Encryption Components are placed \nbetween the Gray Firewall and Inner Firewall, they must be \nplaced in parallel.  T=O  \nWLAN -SR-10 Inner Encryption Components must not perform switching \nor routing for other Encryption Components.  T=O  \nWLAN -SR-11 Infrastructure components must only be configured over an \ninterface dedicated for management.  T=O  \nWLAN -SR-12 DNS lookup services on network devices must be disabled.  O Optional  \nWLAN -SR-13 DNS server addresses on infrastructure devices must be \nspecified or DNS services must be disabled.  T=O  \nWLAN -SR-14 Automatic remote boot -time configuration services must be \ndisabled (e.g., automatic", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}871{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "77", "chunk": " configuration via Trivial File \nTransfer Protocol on boot).  T=O  \n12.2 END USER DEVICE REQUIREMENTS  \nTable 4. End User Device (EU) Requirements  \nReq #  Requirement Description  Threshold / \nObjective  Alternative  \nWLAN -EU-1 The EUD must restrict configuration (Service Set Identifier \n(SSID) and authentication mechanism) of authorized \nWLANs to authorized administrators.  T=O  \nWLAN -EU-2 The EUD must be configured with separate authentication \nand privileges for administrator and user roles.  T=O  \nWLAN -EU-3 The EUD must be loaded with only AO -approved software.  T=O  \nWLAN -EU-4 The EUD must restrict installation and removal of software \nto authorized administrators.  T=O  \nWLAN -EU-5 The EUD must require a user to log  in prior to granting \naccess to any EUD functionality.  T=O  \nWLAN -EU-6 The EUD must be configured to limit the number of \nincorrect logins per an AO -approved period of time either \nby erasing the configuration and data stored on the device \nor by prohibiting login attempts for a AO -approved period \nof time.  T=O  \nWLAN -EU-7 Rekeying of an EUD\u2019s certificates and associated private \nkeys must be done through re -provisioning prior to \nexpiration of keys.  T WLAN -EU-8 \nWLAN -EU-8 Rekeying of an EUD\u2019s certificates and associated private \nkeys must be do", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}872{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "78", "chunk": "ne over the WLAN solution network prior \nto expiration of keys.  O WLAN -EU-7 \nWLAN -EU-9 An EUD must be deauthorized from the network and \nsubmitted for forensic analysis if suspected of being \ncompromised.  T=O31 \n Req #  Requirement Description  Threshold / \nObjective  Alternative  \nWLAN -EU-10 An EUD should be destroyed only if it has been determined \nto be compromised through forensic analysis.  T=O  \nWLAN -EU-11 Users of EUDs must successfully authenticate themselves \nto the services they access on their respective Red Network \nusing an AO -approved me thod.  T=O  \nWLAN -EU-12 Red Network services must not transmit any classified data \nto EUDs until user authentication succeeds.  T=O  \nWLAN -EU-13 The EUD must lock the screen and require user re -\nauthentication after an AO -approved period of inactivity.  T=O  \nWLAN -EU-14 All EUD users must sign an organization -defined user \nagreement before being authorized to use an EUD.  T=O  \nWLAN -EU-15 All EUD users must receive an organization -developed \ntraining course for operating an EUD prior to use.  T=O  \nWLAN -EU-16 At a minimum, the organization -defined user agreement \nmust include each of the following:  \nConsent to monitoring Operations Security (OPSEC) \nguidance  \n\uf0b7 Required physical protections to employ when \noperat", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}873{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "79", "chunk": "ing and storing the EUD  \n\uf0b7 Restrictions for when, where, and under what \nconditions the EUD may be used  \n\uf0b7 Responsibility for reporting security incidents  \n\uf0b7 Verification of IA Training  \n\uf0b7 Verification of appropriate clearance  \n\uf0b7 Justification for Access  \n\uf0b7 Requester information and organization  \n\uf0b7 Account Expiration Date  \n\uf0b7 User Respo nsibilities  T=O  \nWLAN -EU-17 EUDs must be dedicated for use solely in the WLAN \nsolution, and not used to access any resources on networks \nother than the Red Network it communicates with through \nthe two layers of encryption.  T=O  \nWLAN -EU-18 The EUD must disable all transmitted Global Positioning \nSystem (GPS) and location services except Enhanced 9 -1-1 \n(E911) or those authorized by the AO.  T=O  \nWLAN -EU-19 If the E UD has cellular capability then cellular service  must \nbe disabled.  T=O  \nWLAN -EU-20 The EUD must have all network and wireless interfaces \ndisabled except for 802.11 while in operation.  T=O  \nWLAN -EU-21 Withdrawn    \nWLAN -EU-22 All EUDs must have their certificates revoked and resident \nimage removed prior to disposal.  T=O  \nWLAN -EU-23 Passwords for user to device (EUD selected from Mobile \nPlatform section of CSfC Components List) authentication  \nmust have an entropy of at least 95 bits.  T=O32 \n Req #  Requ", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}874{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "80", "chunk": "irement Description  Threshold / \nObjective  Alternative  \nWLAN -EU-24 The native platform DAR protection must be enabled 2.  T=O  \nWLAN -EU-25 Withdrawn    \nWLAN -EU-26 Withdrawn    \nWLAN -EU-27 The EUD maximum password lifetime must be less than \n181 days.  T=O  \nWLAN -EU-28  The EUD screen must lock after an AO approved period of \ninactivity.  T=O  \nWLAN -EU-29 The EUD must perform a wipe of all protected data after 10 \nor more authentication failures.  T=O  \nWLAN -EU-30 During provisioning, all unnecessary keys must be \ndestroyed from the EUD secure key storage.  T=O  \nWLAN -EU-31 During provisioning, all unnecessar y X.509 certificates must \nbe removed from the EUD Trust Anchor Database.   T=O  \nWLAN -EU-32 All display notifications must be disabled while in a locked \nstate.  T=O  \nWLAN -EU-33 USB mass storage mode must be disabled on the EUDs.  T=O  \nWLAN -EU-34 USB data transfer must be disabled on the EUDs.  T=O  \nWLAN -EU-35 Prior to installing new applications, the application digital \nsignature must be verified.  T=O  \nWLAN -EU-36 The EUD must be configured to only permit connections to \nallowlisted SSIDs.  T=O  \nWLAN -EU-37 The EUD must be configured to only permit connection to \nSSIDs using certificates signed by the Outer CA.  T=O   \nWLAN -EU-38 The EUD must only di", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}875{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "81", "chunk": "splay allowlisted SSIDs to the user.  T=O   \nWLAN -EU-39  The end user must only be able to access the  applications \nthat are necessary for the EUDs intended purpose.  T=O  \nWLAN -EU-40 The management and control of the EUD connection to the \nWLAN System must be isolated from other EUD functions.  O Optional  \nWLAN -EU-41 EUDs must prohibit the use of removable media through \nconfiguration, policy, or physical modification.  T=O  \nWLAN -EU-42 If the Basic Input/Output System (BIOS) configuration \nsettings are accessible by the EUD, then the EUD must \nimplement the  BIOS security guidelines specified in NIST SP \n800-147.  T=O  \nWLAN -EU-43 If the BIOS configuration settings are accessible by the EUD, \nthen the  BIOS/Unified Extensible Firmware Interface (UEFI) \nmust be configured to require a password before \ncontinuing the boot process.  O Optional  \nWLAN -EU-44 If the BIOS configuration settings are accessible by the EUD, \nthen the  EUD must have the BIOS/UEFI password enabled.  T=O  \nWLAN -EU-45 If the BIOS configuration settings are accessible by the EUD, \nthen the  PXE Boot feature must be disabled in the BIOS.  T=O  \nWLAN -EU-46 If the BIOS configuration settings are accessible by the EUD, \nthen the  boot from removable media feature must be \ndisabled in the BIOS.  T=O  \n  ", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}876{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "82", "chunk": "                                                         \n2 If the WLAN Solution is implemented in conjunction with a NSA approved DAR Solution, then all applicable DAR \nCP requirements must also be implemented.33 \n 12.3 ENHANCED VIRTUALIZATION REQUIREMENTS  \nThe following requirements are not considered threshold but may be implemented if the AO decides \nthat virtualization is necessary  for the security of their WLAN solution.  \nTable 5. Enhanced Virtualization Requirements  \nReq #  Requirement Description  Threshold/ \nObjective  Alternative  \nWLAN -VZ-1 The EUD and virtualization architecture must be able to \nsecurely isolate hardware components so that only \nauthorized domains can access required components.  O Optional  \nWLAN -VZ-2 The virtualization software must have the ability to create \nvirtual TPMs (vTPMs).  O Optional  \nWLAN -VZ-3 Each VM in this solution must perform a boot integrity \ncheck via a vTPM.  O Optional  \nWLAN -VZ-4 The Wi -Fi drivers and hardware on the underlying host \nEUD mus t only be accessible to the WLAN domain. The \nother domains (Inner VPN, and User VPN) must not have \naccess to the Wi -Fi drivers and hardware.  O Optional  \nWLAN -VZ-5 The end user may only have access to the User domain and \nmust not have access to any domains.  O Optional  \nWLAN", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}877{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "83", "chunk": " -VZ-6 The hypervisor must allow the configuration of virtual \nnetwork infrastructure to other domains within the EUD to \nsupport the secure connections between each domain.  O Optional  \nWLAN -VZ-7 The Inner VPN and the WLAN connections must all be \nimplemented on separate IP stacks by using separate \ndomains for each connection on the EUD.  O Optional  \nWLAN -VZ-8 Rekeying of each domains\u2019 certificates and associated \nprivate keys must be done through re -provisioning prior to \nthe expiration of keys . O WLAN -VZ-9 \nWLAN -VZ-9 Rekeying of a domain\u2019s certificates and associated private \nkeys must be done over the WLAN solution network prior \nto expiration of keys.  O WLAN -VZ-8 \nWLAN -VZ-\n10 All domains must have their certificates revoked and \nresident image removed prior to disposal.  O Optional  \nWLAN -VZ-\n11 If an NSA -approved DAR Solution is not implemented on \nthe user domain, the native platform DAR protection must \nbe enabled.  O Optional  \nWLAN -VZ-\n12 The WLAN domain must use a unique X.509 v3 device \ncertificate, signed by the Outer CA, for mutual \nauthentication with WLAN Access System.  O Optional  \nWLAN -VZ-\n13 The Inner VPN domain must use a unique X.509 v3 device \ncertificate, signed by the Inner CA, for mutual \nauthentication with Inner VPN Gateways.  O Optiona", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}878{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "84", "chunk": "l  \nWLAN -VZ-\n14 The User domain password lifetime must be less than 181 \ndays.  O Optional  \nWLAN -VZ-\n15 The end user must not be able to change security relevant \nsettings on any of the domains.  O WLAN -VZ-17 \nWLAN -VZ-\n16 User domain must display a consent prompt that requires \nuser to accept prior to using the device.  O Optional34 \n Req #  Requirement Description  Threshold/ \nObjective  Alternative  \nWLAN -VZ-\n17 The User domain must use MAC policy to prevent end \nusers from changing security relevant settings.  O MA-VZ-15 \nWLAN -VZ-\n18 Passwords for User domain authentication must be  a \nminimum of 14 alpha -numeric case -sensitive characters.  O Optional  \nWLAN -VZ-\n19 All domains must generate logs and send to a central SIEM \nin the enterprise network of the same classification label.  O Optional  \nWLAN -VZ-\n20 The hypervisor must be configured with an administrative \npassword.  O Optional  \nWLAN -VZ-\n21 The End User must not be able to change any \nadministrative settings in the hypervisor.  O Optional  \nWLAN -VZ-\n22 The End User must not be able to create nor remove \nvirtual machines on the EUD.  O Optional  \nWLAN -VZ-\n23 The hypervisor must not allow any of the domains to \naccess any cellular technologies that are integrated into \nthe EUD.  O Optional  \nWLAN -VZ-\n24 T", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}879{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "85", "chunk": "he user domain virtual/physical disk must be encrypted. \nThis can be accomplished either by the hypervisor or by \nthe OS running in the user domain.  O Optional  \n12.4 WLAN  CLIENT CONFIGURATION REQUIREMENTS  \nTable 6. WLAN Client (WC) Configuration Requirements  \nReq #  Requirement Description  Threshold / \nObjective  Alternative  \nWLAN -WC-1 The WLAN Client tunnel must be established at EUD start -\nup. O  \nWLAN -WC-2 The WLAN Client must authenticate the identity of the \nWLAN Authentication Server by verifying that the WLAN \nAuthentication Server's certificate chain is rooted by the \nWLAN Trusted Ro ot Certificate Authority.  T=O  \nWLAN -WC-3 The WLAN Client must be configured to authenticate only \nspecific servers through setting the client to accept only a \nWLAN Authentication Server certificate that contains a \nparticular Distinguished Name or Subject Alternate Name \n(i.e., the client looks for the specified server name in the \ncertificate during verification).  T=O  \nWLAN -WC-4 A unique device certificate must be loaded into the WLAN \nClient along with the corresponding CA (signing) certificate.  T=O  \nWLAN -WC-5 The device certificate must be used for WLAN Client \nauthentication during EAP -TLS. T=O  \nWLAN -WC-6 The WLAN Client must provide the user with advance \nwarning t", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}880{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "86", "chunk": "hat the WLAN Client's device certificate is due to \nexpire.  T=O  \nWLAN -WC-7 The WLAN Client must negotiate new session keys with the \nWLAN Access System at least once per hour.  T=O  \nWLAN -WC-8 The WLAN Client must be prevented from using ad hoc \nmode (client -to-client connections).  T=O  \nWLAN -WC-9 The WLAN Client must be prevented from usin g network \nbridging.  T=O35 \n Req #  Requirement Description  Threshold / \nObjective  Alternative  \nWLAN -WC-10 The WLAN Client must only associate with authorized \nAccess Points based on attributes such as SSID or allowlists \nand enforce based on the certificate presented by the \nAuthentication Server during mutual authentication.   T=O  \nWLAN -WC-11 The WLAN Client must verify that the WLAN \nAuthentication Server X.509 v3 certificate contains the TLS \nWeb Server Authentication Object Identifier (OID) (id -kp-\nserverAuth 1.3.6.1.5.5.7.3.1) in the Extended Key Usage \nextension.   T=O  \nWLAN -WC-12 The device certificate for the WLAN Client must contain an \nextendedKeyUsage field indicating support for Client \nAuthentication (OID 1.3.6.1.5.5.7.3.2).  T=O  \nWLAN -WC-13 The WLAN Client must be managed from the Gray \nManagement Network.  T=O  \n \nTable 7. Wireless Link (WL) Requirements  \nReq #  Requirement Description  Threshold / \nObjectiv", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}881{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "87", "chunk": "e  Alternative  \nWLAN -WL-1 The WLAN Client and the WLAN Access System must use \nprotocols and algorithms selected from Table 9 that are \napproved  to protect the highest classification level of the \nRed Network data.  T=O  \nWLAN -WL-2 The WLAN Client and the WLAN Access System must \noperate in WPA3 -Enterprise 192 -bit mode  only . T=O  \nWLAN -WL-3 The WLAN Client and the WLAN Access System must use \nintegrity algorithms that implements NIST AES Key Wrap \nwith Hash -based Message Authentication Code (HMAC) -\nSHA-384-128 as specified in Section 11 of IEEE 802.11 -\n2020.  T=O  \nWLAN -WL-4 If WPA3 terminates on  APs then all data between the \nAccess Point(s) and Wireless controller must be encrypted \nusing IPsec, SSHv2, TLS, or TLS/HTTPS.  T=O  \nWLAN -WL-5 The WLAN Client and the WLAN Access System must \noperate with 802.11w (management frame protection) \nenabled.  T=O  \nWLAN -WL-6 Disable WPA3 transition mode for the WLAN Client and the \nWLAN Access System.  T=O  \n \nTable 8. IPSec Encryption (Approved Algorithms for Classified)  \nSecurity Service  Algorithm Suite  Specifications  \nConfidentiality (Encryption)  AES-256 FIPS PUB 197  \nIETF RFC 6239  \nIETF RFC 6379  \nIETF RFC 6380  \nIETF RFC 646036 \n Security Service  Algorithm Suite  Specifications  \nAuthentication (Digital Signatur", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}882{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "88", "chunk": "e)  \n(Threshold \u2013 Unclassified Only)  RSA 3072  FIPS PUB 186 -4 \nAuthentication (Digital Signature)  \n(Objective)  \n(Threshold \u2013 All Classified NSS)  RSA 3072  \nor,  \nECDSA over the curve  \nP-384 with SHA -384  FIPS PUB 186 -4 \nFIPS PUB 186 -4 \nIETF RFC 6239  \nIETF RFC 6380  \nIETF RFC 6460  \nKey Exchange/ Establishment  ECDH over the curve  P -384 (DH \nGroup 20)  \nor,  \nDH 3072  NIST SP 800 -56A \nIETF RFC 7296  \nNIST SP 800 -56A \nIntegrity (Hashing)  SHA-384 FIPS PUB 180 -4 \nIETF RFC 6239  \nIETF RFC 6379  \nIETF RFC 6380  \nIETF RFC 6460  \nCan protect  Up to Top Secret   \nTable 9. WPA3 Encryption and EAP -TLS (Approved Algorithms)  \nSecurity Service  Algorithm Suite  Specifications  \nConfidentiality  \n(Encryption)   \nAES-256-CCMP  FIPS PUB 197  \nEAP-TLS Cipher Suite  TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384  \n IETF RFC 5216  \n \nIETF RFC 5246  \n12.5 VPN  COMPONENTS AND VPN  CLIENT CONFIGURATION REQUIREMENTS  \nTable 10. VPN Components Configuration Requirements (CR)  \nReq #  Requirement Description  Threshold / \nObjective  Alternative  \nWLAN -CR-1 The VPN Components must use protocols and algorithms \nfor creating all VPN tunnels selected from an Algorithm \nSuite in Table 8 that are approved to protect the highest \nclassification level of the Red Network data.  T=O  \nWLAN -CR-2 Default", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}883{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "89", "chunk": ", self -signed, or proprietary device certificates, \nwhich are frequently preinstalled by the vendor, for any \nWLAN Access  System and VPN Gateway components must \nnot be used for establishing Security Associations (SAs).  T WLAN -CR-3 \nWLAN -CR-3 Default, self -signed, or proprietary device certificates, \nwhich are frequently preinstalled by the vendor, for any \nWLAN Access System a nd VPN Gateway components, \nmust be removed.  O WLAN -CR-237 \n Req #  Requirement Description  Threshold / \nObjective  Alternative  \nWLAN -CR-4 All IPsec connections must use IETF standards compliant \nwith IKE implementations ( RFC 7296 ).  T=O  \nWLAN -CR-5 All Access Systems and VPN Gateway components must \nuse Cipher Block Chaining fo r IKE encryption.  T WLAN -CR-16 \nWLAN -CR-6 All Access Systems and VPN Gateway components must \nuse Cipher Block Chaining for ESP encryption with a Hash -\nbased Message Authentication Code for integrity.  T WLAN -CR-7 \nWLAN -CR-7 All Access Systems and VPN Gateway  components must \nuse Galois Counter Mode (GCM) for ESP encryption.  O WLAN -CR-6 \nWLAN -CR-8 All Access Systems and VPN Gateway components must \nset the IKE SA lifetime to at most 24 hours.  T=O  \nWLAN -CR-9 All Access Systems and VPN Gateway components must \nset the ESP SA lifetime to at most 8 hours.  T=", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}884{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "90", "chunk": "O  \nWLAN -CR-10 Each VPN Client must use a unique private key for \nauthenticating to the VPN Gateway.  T=O  \nWLAN -CR-11 The VPN Client must provide the user with advance \nwarning that the VPN client certificate is due  to expire.  T=O  \nWLAN -CR-12 The VPN Client must be configured to prohibit split \ntunneling.  T=O  \nWLAN -CR-13 A unique device certificate must be loaded into the VPN \nClient along with the corresponding CA (signing) \ncertificate.  T=O  \nWLAN -CR-14 The device certificate must be used for VPN Client \nauthentication during IPsec.  T=O  \nWLAN -CR-15 The Inner VPN Component must use Tunnel Mode IPsec or \nTransport Mode IPsec using an associated IP tunneling \nprotocol (e.g., Transport Mode IPsec with GRE).  T=O  \nWLAN -CR-16 All Access Systems and VPN Gateway components must \nuse Galois Counter Mode (GCM) for IKE encryption.  O WLAN -CR-5 \n12.6 WLAN  ACCESS SYSTEM CONFIGURATION REQUIREMENTS  \nThe WLAN Access System is involved in establishing two encrypted channels.  Once the WLAN \nAuthentication Server passes the PMK to the WLAN Access System, the WLAN Access System establishes \nan encrypted channel with the WLAN Client for passing data.  The WLAN Access System acts as a pass -\nthrough for the initial authentication exchange betwe en the WLAN Client and the WLAN Au", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}885{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "91", "chunk": "thentication \nServer during which the PMK is securely negotiated.  \nTable 11. WLAN Access System (WS) Configuration Requirements  \nReq #  Requirement Description  Threshold / \nObjective  Alternative  \nWLAN -WS-1 The WLAN Access System must act as an EAP -TLS pass -\nthrough between the WLAN Client and WLAN \nAuthentication Server for authentication and key \nestablishment.  T=O  \nWLAN -WS-2 The WLAN Access System must negotiate new session keys \nwith the WLAN Clients at least once per hour.  T=O  \nWLAN -WS-3 Requirement has been relocated to the Key Management \nRequirements Annex .38 \n Req #  Requirement Description  Threshold / \nObjective  Alternative  \nWLAN -WS-4 A unique device certificate must be loaded into the \nAuthentication Server along with the corresponding CA \n(signing) certif icate.  T=O  \nWLAN -WS-5 When supporting multiple enclaves, the WLAN Access \nSystem must assign a firewall ACL to EUDs based on the \nattribute information provided by the Authentication \nServer.  T=O  \nWLAN -WS-6 When supporting multiple enclaves, the WLAN Access \nSystem must route EUD traffic over the appropriate \ninterface based on attribute information provided by the \nAuthentication Server.  T=O  \nWLAN -WS-7 When supporting multiple enclaves, the WLAN Access \nSystem  must use unique physical int", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}886{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "92", "chunk": "ernal interfaces for \neach enclave of the solution (i.e., VLAN Trunking of \nmultiple enclaves is not permitted).  T=O  \n \nTable 12. Wireless Infrastructure Authentication (IA) Requirements  \nReq #  Requirement  Description  Threshold / Objective  Alternative  \nWLAN -IA-1 The WLAN Access System and the WLAN authentication \nserver must be physically co -located in the same rack and \ndirectly connected to each other.  T WLAN -IA-2 \nWLAN -IA-2  Communications between the WLAN Access System and \nthe WLAN Authentication Server must be established with \neither an IPsec tunnel (using either IKEv2) or TLS/RADsec \nconnection.  O  WLAN -IA-1 \nWLAN -IA-3 The IKE exchange and IPsec tunnel between the WLAN \nAccess System and the WLAN Authentication Server must \nuse protocols and algorithms selected from the Algorithm \nSuite in Table 6.  T=O  \nWLAN -IA-4 The ESP SA tunnel between the WLAN Access System and \nthe WLAN Authentication Server must be ESP using AES in \nCipher Block Chaining (CBC) mode with a SHA -based HMAC \nfor integrity.  T WLAN -IA-5 \nWLAN -IA-5 The ESP SA tunnel between the WLAN Access System and \nthe WLAN Authentication Server must be ESP use AES in \nGCM mode.  O WLAN -IA-4 \nWLAN -IA-6 The lifetime of the IKE S A between the WLAN Access \nSystem and the WLAN Authentication Server", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}887{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "93", "chunk": " must be set \nto 24 hours.  T=O  \nWLAN -IA-7 The lifetime of the ESP SA between the WLAN Access \nSystem and the WLAN Authentication Server must be set \nto 8 hours or less.  T=O  \nWLAN -IA-8 The WLAN Access System and the WLAN Authentication \nServer must authenticate one another using X.509 v3 \ncertificates.  O WLAN -IA-9 \nWLAN -IA-9 The WLAN Access System and the WLAN Authentication \nServer must authenticate one another using pre -shared \nkeys.  T WLAN -IA-839 \n Req #  Requirement  Description  Threshold / Objective  Alternative  \nWLAN -IA-10 Composition rules for a pre -shared key between the WLAN \nAccess System and the WLAN Authentication Server must \nbe set by the Security Administrator.  T=O  \nWLAN -IA-11 The entropy of a pre -shared key between the WLAN Access \nSystem and the WLAN  Authentication Server must be a \nminimum of 256 bits.  T=O  \nWLAN -IA-12 The IKE exchange between the WLAN Access System and \nthe WLAN Authentication Server must use algorithms \nselecte d from Table 8 . T=O  \n \nTable 13. Wireless Authentic ation and Authorization (AA) Requirements  \nReq #  Requirement Description  Threshold / Objective  Alternative  \nWLAN -AA-1 The WLAN Authentication Server and WLAN Client must \nperform mutual authentication using EAP -TLS with device \ncertificates.  T=O  \nWLAN -", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}888{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "94", "chunk": "AA-2 The WLAN Client and the WLAN Authentication Server \nmust use the AES key size and mode for WPA 3 Enterprise \nfrom the Threshold Section o f Table 9 . T WLAN -AA-3 \nWLAN -AA-3 The WLAN Client and the WLAN Authentication Server \nmust use the AES key size and mode for WPA3 Enterprise \nfrom the Objective Section of  Table 9.  O WLAN -AA-2 \nWLAN -AA-4 The WLAN Client and WLAN Authentication Server must \nuse the EAP -TLS Cipher suite from the Threshold section of  \nTable 9 . T WLAN -AA-5 \nWLAN -AA-5 The WLAN Client and WLAN Authen tication Server must \nuse the EAP -TLS Cipher suite from the Objective section of  \nTable 9 . O WLAN -AA-4 \n \nTable 14. Wireless Authentication Server (WA) Requirements  \nReq #  Requirement Description  Threshold / Objective  Alternative  \nWLAN -WA-1 The WLAN Authentication Server must use the most \ncurrent CRL to check revocation status of the WLAN Client \nCertificate.  If CRL does not exist, is invalid or has expired, \nauthentication of the EUD will fail.  T=O  \nWLAN -WA-2  Requirement has been relocated to the Key Management \nRequirements Annex .   \nWLAN -WA-3 The WLAN Authentication Server must only successfully \nauthenticate a WLAN Client if the WLAN Client's certificate \ncontains an extendedKeyUsage certificate extension \nindicating support for Cli", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}889{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "95", "chunk": "ent Authentication (OID \n1.3.6.1.5.5.7.3.2).  T=O  \nWLAN -WA-4 The WLAN AS must use the Distinguished Name or the \nSubject Alternate Name contained in the WLAN Client's \ncertificate to authenticate the identity of the WLAN Client.  T=O  \nWLAN-WA-5 The WLAN Authentication Server must verify that the \nWLAN Client\u2019s certificate is not expired.   T=O40 \n Req #  Requirement Description  Threshold / Objective  Alternative  \nWLAN -WA-6 The WLAN AS must ensure that the WLAN Client\u2019s \ncertificate chain is rooted by the WLAN trusted root \nCertificate Authority.  T=O  \nWLAN -WA-7 Withdrawn    \nWLAN -WA-8 The WLAN Authentication Server must authenticate the \nidentity of the WLAN Client by verifying that the WLAN \nClient\u2019s certificate is not revoked.  T=O  \nWLAN -WA-9 When supporting multiple enclaves, the AS must verify \nthat th e Common Name presented by the EUD certificate \nis included on an allowlist tied to an enclave.    T WLAN -WA-\n10 \nWLAN -WA-10 When supporting multiple enclaves, the AS must verify \nthat the certificate presented includes information in the \nDistinguished Name or Policy OIDs that ties the device to a \nsingle enclave.  O WLAN -WA-9 \nWLAN -WA-11 When supporting multiple enclaves, the AS must provide \nattribute information on the appropriate enclave for the \nEUD to the ", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}890{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "96", "chunk": "Wireless Access System.  T=O  \nWLAN -WA-12 The AS must log all successful authentication attempts.  T=O  \nWLAN -WA-13 The AS must log all failed authentication attempts.  T=O  \n12.7 PORT FILTERING REQUIREMENTS  \nPort Filtering is composed of a component configured with ACLs.  The system ensures that the traffic \nflowing to and from each component on the network is appropriate for the functionality of the \ncomponent within the Campus WLAN solution.  \nTable 15. Solution Components Port Filtering (PF) Requirements  \nReq #  Requirement Description  Threshold / Objective  Alternative  \nWLAN -PF-1 All components within the solution must have all \nnetwork interfaces restricted to the fewest address \nranges, ports, and protocols possible.  T=O  \nWLAN -PF-2 All components within the solution must have all unused \nnetwork interfaces disabled.  T=O  \nWLAN -PF-3 For all interfaces connected to a Gray Network, traffic \nfiltering rules must be applied to both inbound and \noutbound traffic, such that only EAP -TLS, IKE, IPsec, and \ncontrol plane protocols (as d efined in this Capability \nPackage) approved by policy are allowed.  All packets not \nexplicitly allowed must be blocked.  T=O  \nWLAN -PF-4 Any service or feature that allows a EUD to contact a \nthird party server (such as one maintained", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}891{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "97", "chunk": " by the \nmanufacturer) mu st be blocked.  T WLAN -PF-5 \nWLAN -PF-5 Any service or feature that allows a EUD to contact a \nthird party server (such as one maintained by the \nmanufacturer) must be disabled.  O WLAN -PF-4 \nWLAN -PF-6 The WLAN Access System must block all data ports and \nIP addresses on their Gray Management network \ninterface that are not necessary for the management of \nthe WLAN Access System.  T=O41 \n Req #  Requirement Description  Threshold / Objective  Alternative  \nWLAN -PF-7 Interfaces of the WLAN Access System must be based on \nknown MAC addresses of EUDs to further protect against \nunknown W LAN Clients.   T=O  \nWLAN -PF-8 Traffic filtering rules on the EUD must be applied based \non known VPN Gateway addresses or address range to \nfurther protect against unknown IPsec traffic.  T=O  \nWLAN -PF-9 The internal interface of the Inner VPN Gateway must \nprohibit all management plane traffic (e.g., SSHv2, \nRemote Desktop Protocol (RDP), Telnet) originating from \nEUDs destined for the Red Network.  T=O  \nWLAN -PF-10 The internal interface of the Inner VPN Gateway must \nprohibit traffic destined for the Red Manag ement \nNetwork (e.g., Red Management Network IP addresses) \noriginating from End User Devices.  T=O  \nWLAN -PF-11 CDPs must only allow inbound HTTP traffic", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}892{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "98", "chunk": ".  T=O  \nWLAN -PF-12 For the Inner VPN Gateway interface connected to a \nGray Network, traffic filtering rules must be applied to \nboth inbound and outbound traffic, such that only IKE, \nESP, and management and control plane protocols (as \ndefined in this CP) approved by organization -defined \npolicy are allowed.  T=O  \nWLAN -PF-13 The Inner Firewall must implement an ACL which only \npermits ingress/egress traffic from/to Inner Encryption \nendpoints.  T=O  \nWLAN -PF-14 Multicast messages received on any interfaces of the \nWLAN Access System, Gray Firewall, and Inner \nEncryption Components must be dropped.  T=O  \nWLAN -PF-15 Management plane traffic must only be initiated from \nthe Gray administrative work stations with the exception \nof logging or authentication traffic which may be \ninitiated from WLAN Access System.  T=O  \nWLAN -PF-16 The Gray Firewall must only permit EUDs traf fic to the \nInner Encryption Component associated with the \nappropriate classification level.  T=O  \nWLAN -PF-17 EUDs must prohibit ingress and egress of routing \nprotocols.   T=O  \n12.8 END USER DEVICE PROVISIONING REQUIREMENTS  \nTable 16. EUD Provisioning Requirements (PR)  \nReq #  Requirement Description  Threshold / Objective  Alternative  \nWLAN -PR-1 A Provisioning WLAN using WPA3 -PSK authenticati", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}893{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "99", "chunk": "on \nand encryption must be established on the Red Network \nto support wireless provisioning of EUDs.  T  \nWLAN -PR-2 The Provisioning WLAN on the Gray Management \nNetwork must be contained within a shielded enclosure \nthat provides 100 dB of attenuation across the frequency \nrange from 2 to 6 GHz.  T42 \n Req #  Requirement Description  Threshold / Objective  Alternative  \nWLAN -PR-3 The Provisioning WLAN on the Red Network must be \ncontained within a shielded enclosure that provides 100 \ndB of attenuation across the frequency range from 2 to 6 \nGHz.  T  \nWLAN -PR-4 EUDs must be provisioned over the provisioning WLANs.  T WLAN -PR-5 \nWLAN -PR-5 EUDs must be provisioned over wired connections.  O WLAN -PR-4 \nWLAN -PR-6 When a EUD has been successfully provisioned, its \nidentity (ITU -T X.509v3 Distinguished Name or Subject \nAlternate Name) must be recorded in authorization \ndatabases accessible to the WLAN Authentication Server \nand VPN Gat eway.  T=O  \nWLAN -PR-7 EUDs must be provisioned to be disabled by having their \ncertificates revoked.  T=O  \nWLAN -PR-8 The EUD must be loaded with an authorized software \nbuild during provisioning.  T=O  \nWLAN -PR-9 The EUD must be loaded with WLAN and VPN \nconfiguration profiles during provisioning.  T=O  \nWLAN -PR-10 Strong passwords for the", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}894{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "100", "chunk": " EUD must be used to comply \nwith the requirements of the policy established by the \nAO.  T=O  \nWLAN -PR-11 Services not authorized by the AO must be disabled \nduring the provisioning of the EUD.  T=O  \n12.9 CONFIGURATION REQUIREMENTS FOR WIRELESS INTRUSION DETECTION SYSTEM \n(WIDS)  \nConfiguration Requirements for WIDS have been relocated to the Wireless Intrusion Detection \nSystem/Wireless Intrusion Prevention System (WIDS/WIPS) Annex.  \nTable 17. WIDS/WIPS Requirements  \nReq #  Requirement Description  Threshold/ \nObjective  Alternative  \nWLAN -WIDS -\n0 Meet all requirements defined in the CSfC  Wireless \nIntrusion Detection System/Wireless Intrusion Prevention \nSystem (WIDS/WIPS) Requirements Annex that apply to \nthe WLAN CP for government private wireless.  T=O  \n12.10  CONFIGURATION CHANGE DETECTION REQUIREMENTS  \nConfiguration Change Detection Requirements  have been relocated  to the Continuous Monitoring \nRequirements Annex.  \n12.11  DEVICE MANAGEMENT REQUIREMENTS  \nOnly authorized Security Administrators will be allowed to administer the components.  The WLAN \nsolution will be used as transport for the SSHv2, IPsec, or TLS data from the Administration Workstation \nto the component.43 \n Table 18. Device Management (DM) Requirements  \nReq #  Requirement Description  Thresh", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}895{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "101", "chunk": "old / \nObjective  Alternative  \nWLAN -DM-1 Administration Workstations must be dedicated for the \npurposes given in the CP and must be physically \nseparated from workstations used to manage non -CSfC \nsolutions.  T=O  \n \n \n \n \nWLAN -DM-2 Withdrawn     \nWLAN -DM-3 Antivirus software must be running on all Administration \nWorkstations.  T=O  \nWLAN -DM-4 All components must be configured to restrict the IP \naddress range for the network administration device to \nthe smallest range possible.  T=O  \nWLAN -DM-5 The Gray Management network must not be directly \nconnected to Non -secure Internet Protocol Router \nNetwork (NIPRNet) or any other Unclassified network \nnot dedicated to the administration of CSfC solutions.  T=O  \nWLAN -DM-6 All administration of solution components must be \nperformed from an Administration Workstation \nremotely using one of SSHv2, IP sec, or TLS 1.2 or later \nversion; or by managing the solution components locally.  T=O  \nWLAN -DM-7 Security Administrators must authenticate to solution \ncomponents before performing administrative functions.  T WLAN -DM-8 \nWLAN -DM-8 Security Administrators mu st authenticate to solution \ncomponents with Commercial National Security \nAlgorithm (CNSA) Suite -compliant certificates before \nperforming administrative functions rem", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}896{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "102", "chunk": "otely.  O WLAN -DM-7 \nWLAN -DM-9 Security Administrators must establish a security policy \nfor EUDs per the implementing organization\u2019s local \npolicy to include procedures for continuous physical \ncontrol.  T=O  \nWLAN -DM-10 Withdrawn    \nWLAN -DM-11 Security Administrators must initiate certificate signing \nrequests for solution components as part of their initial \nkeying within the solution.  T=O  \nWLAN -DM-12 Devices must use Enrollment over Secure Transport \n(EST) as detailed in IETF RFC 7030 for certificate \nmanagement.  O Optional  \nWLAN -DM-13 Withdrawn    \nWLAN -DM-14 Withdrawn    \nWLAN -DM-15 Withdrawn    \nWLAN -DM-16 When managing solution components over the Black \nNetwork, the management traffic must be encrypted \nwith a CNSA Suite algorithm (See Table 8).  T=O  \nWLAN -DM-17 The CSfC solution owner must identify authorized SAs to \ninitiate certificate requests.  T=O44 \n Req #  Requirement Description  Threshold / \nObjective  Alternative  \nWLAN -DM-18 Authentication of SAs must be enforced by either \nprocedural or technical controls.  T=O  \nWLAN -DM-19 The same administration workstation must not be used \nto mana ge Inner Encryption Components and the WLAN \nAccess System.  T=O  \nWLAN -DM-20  The Gray Management Network must be used \nexclusively for all management of th", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}897{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "103", "chunk": "e Outer Encryption \nComponent, Gray Firewall, if present, and Solution \nComponents within the Gray Netwo rk. T=O   \nWLAN -DM-21  The Gray Management Network must not be directly \nconnected to the Non -secure Internet Protocol Router \nNetwork (NIPRNet) or any other Unclassified network \nnot dedicated to the administration of CSfC solutions.  T=O   \nWLAN -DM-22 The Gray Management and Gray Data Networks must be \nat minimum logically separated by the Gray Firewall \nusing ACL.  T=O   \n12.12  CONTINUOUS MONITORING REQUIREMENTS  \nContinuous Monitoring Requirements have been relocated to the Continuous Monitoring Requirements \nAnnex.  \nTable 19. Continuous Monitoring Requirements  \nReq #  Requirement Description  Threshold/ \nObjective  Alternative  \nWLAN -CM-0 Meet all requirements defined in the Continuous \nMonitoring Annex  that apply to the WLAN CP.  T=O  \n12.13  AUDITING  REQUIREMENTS  \nAuditing Requirements have been moved to the Continuous Monitoring Requirements Annex.  \n12.14  KEY MANAGEMENT REQUIREMENTS  \nKey Management Requirements have been relocated to a separate CSfC Key Management Requirements \nAnnex.  \nTable 20. Key Management Requirements  \nReq #  Requirement Description  Threshold/ \nObjective  Alternative  \nWLAN -KM-0 Meet all requirements defined in the CSfC Key Manage", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}898{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "104", "chunk": "ment \nRequirements Annex that apply to the WLAN CP.  T=O  \n12.15  GRAY FIREWALL REQUIREMENTS45 \n Table 21. Gray Firewall (FW) Requirements  \nReq #  Requirement Description  Threshold / \nObjective  Alternative  \nWLAN -FW-1 Gray Network Firewall must permit IKE and IPsec traffic \nbetween the EUDs VPN Client and VPN Gateway protecting \nnetw orks of the same classification level.  T=O  \nWLAN -FW-2 Gray Network Firewall must allow HTTP traffic between the \nAuthentication Server and the Gray CDP or OCSP responder.  T WLAN -FW-3 \nand \nWLAN -FW-4 \nWLAN -FW-3 Gray Network Firewall must allow HTTP GET requests from \nthe Authentication Server to the Gray CDP or OCSP \nresponder for the URL of the CRL OCSP Response needed by \nthe VPN Gateway, and block all other HTTP requests.  O WLAN -FW-2 \nWLAN -FW-4 Gray Network Firewall must allow HTTP responses from the \nGray CDP or OCSP responder to the Authentication Server \nthat contain a well -formed CRL per IETF RFC 5280 or OCSP \nResponse per RFC 6960, and block all other HTTP responses.  O WLAN -FW-2 \nWLAN -FW-5 Gray Network Firewall must only accept management traffic \non the  physical ports connected to the Gray Management \nnetwork.  T=O  \nWLAN -FW-6 Gray Network Firewall must only permit packets whose \nsource and destination IP addresses match t", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}899{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "105", "chunk": "he external \ninterfaces of the VPN Components that support Red \nNetworks of the same classification level.  T=O  \nWLAN -FW-7 Gray Network Firewall must block all packets whose source \naddress does not match a list of addresses or address \nranges known to be reachable from the interface on which \nthe packet was received.  T=O  \nWLAN -FW-8 Gray Net work Firewall must deny all traffic that is not \nexplicitly allowed by requirements WLAN -FW-1, WLAN -FW-\n2, WLAN -FW-3, WLAN -FW-4, or WLAN -FW-5. T=O  \nWLAN -FW-9 Gray Network Firewall must allow control plane traffic (NTP, \nDHCP, DNS).  T=O  \n \n12.16  EUD  TO INFRASTRUCTURE TWO-FACTOR AUTHENTICATION REQUIREMENTS  \nTable 22. EUD to Infrastructure Two Factor Authentication Requirements  \nReq #  Requirement Description  Threshold/ \nObjective  Alternative  \nWLAN -2F-1 The VPN EUD must implement a second authentication \nfactor to prevent persistent access.  O Optional  \nWLAN -2F-2 The second factor of authentication must use a physically \nseparate token.  O Optional  \nWLAN -2F-3 The second factor of authentication must only be \nimplemented on the Inner tunnel.  O Optional  \nWLAN -2F-4 The second factor of authentication must not be used as a \nreplacement for the primary authentication method on the \nInner layer of encryption.  O Optional46", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}900{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "106", "chunk": " \n Req #  Requirement Description  Threshold/ \nObjective  Alternative  \nWLAN -2F-5 The second factor of authentication must implement a \ncombi ned user generated password and a token generated \none-time pass.  O Optional  \nWLAN -2F-6 The management server for the second factor of \nauthentication must be located in Red Management \nservices.  O Optional  \nWLAN 2F -7 The token generated one -time pass must  implement a time -\nbased algorithm.  O Optional  \nWLAN -2F-8 In the event of loss of continuous physical control the token \nmust be considered compromised, reported to the AO/DAA, \nand must not be reused.  O Optional  \nWLAN -2F-9 If the second factor of authent ication\u2019s seed file is \ncompromised, all tokens are considered compromised and \nmust be replaced.  O Optional  \nWLAN -2F-10 During procurement, the vendor must not be permitted to \nstore backups of seed files.  O Optional  \nWLAN -2F-11 All seed files must be encrypted during transport.  O Optional  \nWLAN -2F-12 Authentication tokens must be physically secured in a \nseparate storage container from the EUD.  O Optional  \n12.17   USER TO EUD  FOR TWO FACTOR AUTHENTICATION REQUIREMENTS  \nTable 23. User -to-EUD for Two Factor Authentication Requirements  \nReq #  Requirement Description  Threshold/ \nObjective  Alternative  \nWLAN", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}901{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "107", "chunk": " -2F-13 The EUD must implement a second authentication factor for \nlogging into the device.  O Optional  \nWLAN -2F-14 The second factor of authentication must use a physically \nseparate token.  O Optional  \nWLAN -2F-15 The second factor of authentication must implement a \ncombined user generated password and PKI based smart \ncard.  O Optional  \nWLAN -2F-16 The second factor of authentication must  implement a \ncombined user generated password and a token generated \none-time pass.  O Optional  \nWLAN -2F-17 The management server for the second factor of \nauthentication must be located in a Red Management \nservices.  O Optional  \nWLAN -2F-18 The system genera ted one -time pass must implement a \ntime -based algorithm.  O Optional  \nWLAN -2F-19 In the event of loss of continuous physical control the token \nmust be considered compromised, reported to the AO/DAA, \nand must not be reused.  O Optional  \nWLAN -2F-20 If the second factor of authentication\u2019s seed file is \ncompromised, all tokens are considered compromised and \nmust be replaced.  O Optional  \nWLAN -2F-21 During procurement, the vendor must not be permitted to \nstore backups of seed files.  O Optional47 \n Req #  Requirement Description  Threshold/ \nObjective  Alternative  \nWLAN -2F-22 All seed files must be encrypted during t", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}902{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "108", "chunk": "ransport.  O Optional  \nWLAN -2F-23 Authentication tokens must be physically secured in a \nseparate storage container from the EUD.  O Optional  \n13 REQUIREMENTS FOR SOL UTION OPERATION, MAI NTENANCE, AND \nHANDLING  \n13.1 USE AND HANDLING OF SOLUTIONS (GD)  REQUIREMENTS  \nThe following requirements must be followed regarding the use and handling of the solution.  \nTable 24. Use and Handling of Solutions Requirements  \nReq #  Requirement Description  Threshold / \nObjective  Alternative  \nWLAN -GD-1 All solution infrastructure components must be physically \nprotected as classified devices, classified at the highest \nclassification level of the Red Network.  T=O  \nWLAN -GD-2 Only authorized and appropriately cleared (or escorted) \nadministrators and security personnel must have physical \naccess to the solution Infrastructure components.  T=O  \nWLAN -GD-3 Only authorized and appropriately cleared users, \nadministrators, and security personnel must have physical \naccess to EUDs.  T=O  \nWLAN -GD-4 All components of the solution must be disposed of as \nclassified devices, unless declassified using AO -approved \nprocedures.  T=O  \nWLAN -GD-5 EUDs using a NSA -approved DAR solution must be disposed \nof in accordance with the disposal requireme nts for the DAR \nsolution.  T=O  \nWLAN -GD-6 ", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}903{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "109", "chunk": "All EUDs must have their certificates revoked prior to \ndisposal.  T=O  \nWLAN -GD-7 Users must periodically inspect the physical attributes of \nEUDs for signs of tampering or other unauthorized changes.  T=O  \nWLAN -GD-8 Acquisition and procurement documentation must not \ninclude information about how the equipment will be used, \nto include that it will be used to protect classified \ninformation.  T=O  \nWLAN -GD-9 The solution owner must allow, and fully cooperate with, \nNSA or  its authorized agent to perform an IA compliance \naudit (including, but not limited to, inspection, testing, \nobservation, interviewing) of the solution implementation \nto ensure it meets the latest version of the CP.  T=O  \nWLAN -GD-10 As part of the annual solution re -registration process, the \nAO will ensure that a compliance audit must be conducted \nevery year against the latest version of the WLAN CP.  T=O  \nWLAN -GD-11 Results of the compliance audit must be provided to and \nreviewed by the AO.  T=O48 \n Req #  Requirement Description  Threshold / \nObjective  Alternative  \nWLAN -GD-12 Customers interested in registering their solution against \nthe WLAN CP must register with NSA and receive approval \nprior to AO authorization to operate.  T=O  \nWLAN -GD-13 The implementing organization must complete ", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}904{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "110", "chunk": "and submit a \nWLAN CP requiremen ts compliance matrix to their \nrespective AO.  T=O  \nWLAN -GD-14 Registration and re -registration against the WLAN CP must \ninclude submission of WLAN CP registration forms and \ncompliance matrix to NSA.  T=O  \nWLAN -GD-15 When a new approved version of the WLAN CP is published \nby NSA, the AO must ensure compliance against this new CP \nwithin six months or by the next re -registration date \n(whichever is greater).  T=O  \nWLAN -GD-16 Solution implementation information, which was provided \nto NSA during solution registra tion, must be updated \nannually (in accordance with Section 15.3 ) as part annual \nsolution re -registration process.  T=O  \nWLAN -GD-17 Audit log data m ust be maintained for a minimum of 1 year.  T=O  \nWLAN -GD-18 The amount of storage remaining for audit events must be \nassessed quarterly in order to ensure that adequate \nmemory space is available to continue recording new audit \nevents.  T=O  \nWLAN -GD-19 Audit data must be frequently off -loaded to a backup \nstorage medium.  T=O  \nWLAN -GD-20 A set of procedures must be developed by the \nimplementing organization to provide guidance for \nidentifying and reporting security incidents associated with \nthe audit events to the proper authorities and to the data \nowners.  T=O  \nWL", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}905{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "111", "chunk": "AN -GD-21 The implementing organization must develop a continuity of \noperations plan for auditing capability, which includes a \nmechanism or method for determining when the audit log is \nreachin g its maximum storage capacity.  T=O  \nWLAN -GD-22 The implementing organization must develop a continuity of \noperations plan for auditing capability, which includes a \nmechanism or method for off -loading audit log data for \nlong - term storage.  T=O  \nWLAN -GD-23 The implementing organization must develop a continuity of \noperations plan for auditing capability, which includes a \nmechanism or method for responding to an overflow of \naudit log data within a product.  T=O  \nWLAN -GD-24 The implementing organiza tion must develop a continuity of \noperations plan for auditing capability which includes a \nmechanism or method for ensuring that the audit log can be \nmaintained during power events.  T=O  \nWLAN -GD-25 Strong passwords must be used that comply with the \nrequir ements of the AO.  T=O49 \n Req #  Requirement Description  Threshold / \nObjective  Alternative  \nWLAN -GD-26 Security critical patches must be tested and subsequently \napplied to all components in the solution in accordance with \nlocal policy and this CP.  T=O  \nWLAN -GD-27 Local policy must dictate how the Security Admin", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}906{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "112", "chunk": "istrator \nwill install patches to solution components.  T=O  \nWLAN -GD-28 Solution components must comply with local TEMPEST \npolicy.  T=O  \nWLAN -GD-29 Software, settings, keys, and all other configuration data \npersistently stored on EUDs must be handled as controlled \nunclassified information or higher classification.  T=O  \nWLAN -GD-30 All hardware components must be tracked through an AO -\napproved inventory management process that identifies \neach component as part of a CSfC solution.  T=O  \nWLAN -GD-42 If a CDS is being leveraged within the solution, then it must \nadhere with all applicable organizational policy and be on \nthe NCDSMO CDS Baseline. (For example, DoD customers \nmust also adhere to DoDI 8540.01 and the DISN Connection \nProcess Guide).  T=O  \nAdditional WLAN -GD re quirements can be found in Section 1 4. \n13.2 REQUIREMENTS FOR INCIDENT REPORTING  \nTable 25 lists requirements for reporting security incidents to NSA to be followed in the event that a \nsolution owner identifies a security incident that affects the solution.  Thes e reporting requirements are \nintended to augment, not replace, any incident reporting procedures already in use within the Solution \nOwner\u2019s organization.  It is critical that Security Administrators  and Auditors are familiar with \nmai", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}907{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "113", "chunk": "ntaining the solution i n accordance with this CP.  Familiarity with the approved configuration of  the \nsolution will better equip  operat ions and maintenance personnel to identify reportable incidents.  \nFor the purposes of incident reporting, \u201cmalicious activity\u201d includes not only events that have been \nattributed to activity by an adversary, but also any events that are unexplained.  In other words, an \nactivity is assumed to be malicious unless it has been determined to be the result of known non -\nmalicious activity.  \nTable 25 only pr ovides requirements directly related to the incident reporting process.  See Section \n12.12 for requirements supporting the detection of events that may reveal that a reportable incident \nhas occurred.  \nTable 25. Incident Reporting Requirements (RP)  \nReq #  Requirement Description  Threshold / \nObjective  Alternative  \nWLAN -RP-1 Solution owners must report confirmed incidents meeting \nthe criteria in WLAN -RP-3 through  \nWLAN -RP-15 within 24 hours of detection via Joint Incident \nManagement System (JIMS) or contacting NSA as specified \nin the CSfC Registration Letter issued for the solution.  T=O50 \n Req #  Requirement Description  Threshold / \nObjective  Alternative  \nWLAN -RP-2 At a minimum, the organization must provide the following ", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}908{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "114", "chunk": "\ninformation when reporting security incidents:  \n\uf0b7 CSfC Registration Number  \n\uf0b7 Point of  Contact (POC) name, phone, email  \n\uf0b7 Alternate POC name, phone, email  \n\uf0b7 Classification level of affected solution  \n\uf0b7 Name of affected Network(s)  \n\uf0b7 Affected component(s) manufacturer/vendor  \n\uf0b7 Affected component(s) model number  \n\uf0b7 Affected component(s) version number  \n\uf0b7 Date and time of incident  \n\uf0b7 Description of incident  \n\uf0b7 Description of remediation activities  \n\uf0b7 Is Technical Support from NSA requested? (Yes/No)  T=O  \nWLAN -RP-3 Solution owners must report a security failure in any of the \nCSfC solution components.  T=O  \nWLAN -RP-4 Solution owners must report any evidence of a compromise \nor spillage of classified data caused by a failure of the CSfC \nsolution.  T=O  \nWLAN -RP-5 For Gray Network interfaces, solution owners must report \nany malicious inbound and outbound traffic.  T=O  \nWLA N-RP-6 Solution owners must report any evidence of an \nunauthorized device/user gaining access to the classified \nnetwork via the solution.  T=O  \nWLAN -RP-7 Solution owners must report if a solution component sends \ntraffic with an unauthorized destination address.  T=O  \nWLAN -RP-8 Solution owners must report any malicious configuration \nchanges to the components.  T=O  \nWLAN -RP-9 Solutio", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}909{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "115", "chunk": "n owners must report any unauthorized escalation of \nprivileges to any of the CSfC solution components.  T=O  \nWLAN -RP-10 Solution owners must report if two or more simultaneous \nVPN connections from different IP addresses are established \nusing the same EUD device certificate.  T=O  \nWLAN -RP-11 Solution owners must report any evidence of malicious \nphysical tampering with soluti on components.  T=O  \nWLAN -RP-12 Solution owners must report any evidence that one or both \nof the layers of the solution failed to protect the data.  T=O  \nWLAN -RP-13 Solution owners must report any significant degradation of \nservices provided by the solution.  T=O  \nWLAN -RP-14 Solution owners must report malicious discrepancies in the \nnumber of connections established the WLAN Access \nSystem.  T=O  \nWLAN -RP-15 Solution owners must report malicious discrepancies in the \nnumber of VPN connections establishe d by the Inner VPN \nGateway.  T=O51 \n 14 ROLE -BASED PERSONNEL  REQUIREMENTS  \nThe roles required to administer and maintain the solution, along with doctrinal requirements for these \nroles are defined below.  \nSecurity Administrator  \u2013 The Security Administrator must be  responsible to maintain, monitor, and \ncontrol all security functions for the entire suite of products composing the WLAN s", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}910{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "116", "chunk": "olution.  Security \nAdministrator duties include, but are not limited to, the following:  \n1) Ensure the latest security -critical software patches and updates (such as Information Assurance \nVulnerability Alerts (IAVAs)) are applied to each product.  \n2) Document and report security -related incidents to the appropriate authorities.  \n3) Coordinate and support product logistic support activities includin g integration and maintenance.  \nSome logistic support activities may require that the Security Administrator escort uncleared \npersonnel.  \n4) Employ adequate defenses of auxiliary network devices to enable proper and secure functionality of \nthe WLAN solution.  \n5) Ensure that the implemented WLAN solution remains compliant with the latest version of this CP.  \n6) Provision and maintain EUDs in accordance with this CP for implementations that include them.  \nAuditor  \u2013 The Auditor must be responsible to review the actions per formed by the Security \nAdministrato r and events recorded in the audit logs to ensure that no action or event represents a \ncompromise to the security of the WLAN solution.  Auditor duties include, but are not limited to:  \n1) Review, manage, control, and maintai n security audit log data.  \n2) Document and report security -related incidents to the appro", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}911{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "117", "chunk": "priate authorities.  \n3) The Auditor will only be authorized access to Outer and Inner administrative components.  \nSolution Integrator  \u2013 In certain cases, an external integrator may be hired to implement a WLAN \nsolution based on this CP.  Solution Integrator duties may include, but are not limited to, the following:  \n1) Acquire the products that compose the solution.  \n2) Configure the WLAN solut ion in accordance with this CP.  \n3) Document, test, and maintain the solution.  \n4) Respond to incidents affecting the solution.  \nEnd User  \u2013An End User may operate an EUD from physical locations not owned, operated, or controlled \nby the government.  The End User mus t be responsible for operating the EUD in accordance with this CP52 \n and an organization -defined user agreement.  Remote User duties include, but are not limited to the \nfollowing:  \n\uf0b7 Ensure the EUD is only operated in physical spaces which comply with the end us er agreement.  \n\uf0b7 Alert the Security Administrator immediately upon a EUD being lost, stolen, or suspected of \nbeing tampered with.  \nAdditional requirements related to the personnel that perform these roles in a WLAN solution are as \nfollows:  \nTable 26. Role -Based Personnel Requirements  \nReq #  Requirement Description  Threshold / \nObjective  Alternati", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}912{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "118", "chunk": "ve  \nWLAN -GD-31 The Security Administrator,  Auditor, EUD User, and \nsolution Integrators must be cleared to the highest level of \ndata protected by the solution.  When an Enterprise CA is \nused in the solution, the administrator  for that system may \nalso support this solution, provided they meet this \nrequirement.  T=O  \nWLAN -GD-32 The Security Administrator  and Auditor roles must be \nperformed by different people.  T=O  \nWLAN -GD-33 All Security Administrators, EUD Users, and Auditors must \nmeet local IA training requirements.  T=O  \nWLAN -GD-35 Upon discovering an EUD is lost, stolen or altered, an EUD \nUser must immediately report the incident to their Security \nAdministrator.  T=O  \nWLAN -GD-36 Requirement has been relocated to the Key Management \nRequirements Annex.    \nWLAN -GD-37 The Security Administrator(s) for the Inner Encryption \nEndpoints and supporting components on Enterprise/Red \nNetworks must be different individuals from the Security \nAdministrator(s) for the WLAN Access System and \nsupporting components on Gray Networks.  T=O  \nWLAN -GD-38 Administrators must periodically inspect the physical \nattributes of infrastructure hardware for signs of \ntampering or other unauthorized changes.  T=O  \nWLAN -GD-39 Withdrawn    \n15 INFORMATION TO SUPPO RT AO  \nThis se", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}913{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "119", "chunk": "ction details items that likely will be necessary for the customer to obtain approval from the \nsystem AO.  The customer and AO have obligations to perform the following:  \n\uf0b7 The customer, possibly with support from a System Integrator, instantiates a solution \nimplementation that follows the NSA -appr oved CP.  \n\uf0b7 The customer has a testing team develop a test plan and perform testing of the WLAN solution \nas described in Section  15.1 .53 \n \uf0b7 The customer has system certification and accreditation performed using the risk assessment \ninformation referenced in Section  15.2 . \n\uf0b7 The customer provides the results from testing and system certification and accreditation to the \nAO for use in making an approval decision.  The AO is ultimately responsible for ensuring that all \nrequirements from the CP have been properly im plemented in accordance with the CP.  \n\uf0b7 The customer registers the solution with NSA and re -registers yearly to validate its continued \nuse as detailed in Section  15.3 . \n\uf0b7 Customers who want to use a variant of the solution detailed in this CP will contact their \nNSA/CSD Client Advocate to determine ways to obtain NSA approval.  \n\uf0b7 The AO will ensure that a compliance audit must be conducted every year against the latest \nversion of the WLAN CP, and the result", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}914{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "120", "chunk": "s must be provided to the AO.  \n\uf0b7 The AO will ensure that certifi cate revocation information is updated on all the solution \ncomponents in the solution in the case of a compromise.  \n\uf0b7 The AO will ensure that any Layer 2 or Layer 3 control plane protocols that are used in the \nsolution are necessary for the operation of the n etwork and that local policy supports their use.  \n\uf0b7 The AO will report incidents affecting the solution in accordance with Section  13.2 . \nThe system AO maintains configuration control of the approved solution implementation over the \nlifecycle of the solution.  Additionally, the AO must ensure that the solution remains properly configured \nwith all required security updates implemented.  \n15.1 SOLUTION TESTING  \nThis section provides a framework for a Test and Evaluation (T&E) plan and procedures to validate the \nimplement ation of a WLAN solution.  This T&E will be a critical part of the approval process for the AO, \nproviding a robust body of evidence that shows compliance with this CP.  \nThe security features and operational capabilities associated with the use of the soluti on must be tested. \nThe following is a general high -level methodology for developing the test plan and procedures and for \nthe execution of those procedures to validate the imple", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}915{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "121", "chunk": "mentation and functionality of the WLAN \nsolution.  The entire solution, to inclu de each component described in Section 6, is addressed by this \ntest plan including the following:  \n1) Set up the baseline network and configure all comp onents.  \n2) Document the baseline network configuration.  At a minimum, include product model and serial \nnumbers, and software version numbers.  \n3) Develop a test plan for the specific implementation using the test requirements from the CSfC \nCampus WLAN CP  Test Annex .  Any additional requirements imposed by the local AO should also54 \n be tested, and the test plan must include tests to ensure that these requirements do not \ninterfere with the security of this solution as described in this CP.  \n4) Perform testing using the  test plan derived in Step 3.  Network testing will consist of both Black \nbox testing and Gray box testing.  A two -person testing approach should be used to administer \nthe tests. During test execution, security and non -security related discrepancies with t he \nsolution must be documented.  \n5) Compile findings, to include comments and vulnerability details as well as possible \ncountermeasure information, into a Final Test Report to be delivered to the AO for approval of \nthe solution.  \nThe following test requirement h", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}916{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "122", "chunk": "as been developed to ensure that the WLAN solution functions \nproperly and meets the configuration requirements from Section 11.  Testing of these requirements \nshould be used as a minimum framework for the development of the detailed test plan and procedur es \nTable 27. Test Requirement  \nReq #  Requirement Description  Threshold / \nObjective  Alternative  \nWLAN -TR-1 The organization implementing the CP must perform all tests \nlisted in the CSfC WLAN CP Test Annex . T=O  \n15.2 RISK ASSESSMENT  \nThe risk assessment of the WLAN solution presented in this CP focuses on the types of attacks that are \nfeasible against this solution and the mitigations that can be employed.  Customers should contact their \nNSA/CSD Client Advocate to request this document, or  visit the Secret Internet Protocol Router Network \n(SIPRNet) CSfC site for information.  The process for obtaining the risk assessment is available on the \nSIPRNet CSfC website.  The AO must be provided a copy of the NSA risk assessment for their \nconsiderat ion in approving the use of the solution.  \n15.3 REGISTRATION OF SOLUTIONS  \nAll customers using CSfC solutions to protect information on National Security Systems must register \ntheir solution with NSA prior to operational use.  This registration will allow NSA to track whe", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}917{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "123", "chunk": "re WLAN \nCP solutions are instantiated and to provide the AOs at those sites with appropriate information, \nincluding any significant vulnerabilities that may be discovered in components or high -level designs \napproved for these solutions.  The CSfC solution registration process is available at \n(https://www.nsa.gov/resources/commercial -solutions -for-classified -program ).  \nSolution registrations are valid for one year from the date the solution r egistration is approved, at which \ntime customers are required to re -register their solution in order to continue using it.  Approved CPs will \nbe reviewed twice a year, or as events warrant.  Registered users of this CP will be notified when an \nupdated vers ion is published.  When a new version of this CP that has been approved by the D/NM is \npublished, customers will have six months to bring their solutions into compliance with the new version \nof the CP and re -register their solution (see requirement WLAN -GD-15).  Customers are also required to55 \n update their registrations whenever the information provided on the registration form changes, to \ninclude AO and POC information.56 \n APPENDIX A. GLOSSARY  OF TERMS  \nAuthorization (To Operate) \u2013 The official management decision given by a senior organizational official \nto autho", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}918{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "124", "chunk": "rize operation of an information system and to explicitly accept the risk to organizational \noperations (including mission, functions, image, or reputation), organizational assets, individuals, othe r \norganizations, and the Nation based on the implementation of an agree d-upon set of security controls  \n(NIST SP 800 -37). \nAuthorization Boundary \u2013 All components of an information system to be authorized for operation by  \nan AO  and excludes separately author ized systems, to which the information system is connected.  \nAuthorizing Official  (AO)  \u2013 A senior ( Federal) official or executive with the authority to formally assume \nresponsibility for operating an information system at an acceptable level of risk to org anizational \noperations (including mission, functions, image, or reputation), organizational assets, individuals, other \norganizations, and the Nation.  \nAuthorizing Official Designated Representative \u2013 An organizational official acting on b ehalf of an AO  in \ncarrying out and coordinating the required activities associated with security authorization.  \nAuthorization Package \u2013 A security package of documents consisting of the security control assessment \nthat p rovides the AO  with essential information needed to make a risk -based decision on whether to \nauthorize", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}919{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "125", "chunk": " operation of an information system or a designated set of common controls.  \nAssurance  \u2013 Measure of confidence that the security features, practices, procedures, and arc hitecture of \nan information system accurately mediates a nd enforces the security policy (CNSSI 4009).  \nAudit  \u2013 The activity of monitoring the operation of a product from within the product. It includes \nmonitoring of a product for a set of pre -determined eve nts. Each audit event may indicate rogue \nbehavior, or a condition that is detrimental to security, or provide necessary forensics to identify the \nsource of rogue behavior.  \nAudit Log  \u2013 A chronological record of the audit events that have been deemed critical to security. The \naudit log can be used to identify potentially malicious activity that may further identify the source of an \nattack, as well as potential vulnerabilities where add itional countermeasures or corrective action s are \nrequired.  \nAvailability  \u2013 Ensuring timely and reliable a ccess to and use of information  (NIST SP 800 -37). \nBlack Box Testing  \u2013 Testing the functionality of a component of the solution, such that testing is li mited \nto the subset of functionality that is available from the external interfaces of the box during its normal \noperational configuration without any", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}920{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "126", "chunk": " additional privileges (such as given to the Security Administrator \nor Auditor).  \nBlack Network  \u2013 A network  that contains classified dat a that has been encrypted twice  (See Section  \n4.3.3 ).57 \n Capability Package (CP)  \u2013 The set of guidance provided by NSA that describes recommended \napproaches to composing COTS components to protect classified information for a parti cular class of \nsecurity problem.  CP instantiations are built using products selected from the CSfC Components List . \nCertificate Authority (CA)  \u2013 An authority trusted by one or more users to create and assign certificates \n(ISO9594 -8). \nCertificate Policy \u2013 A named set of rules that indicate the applicability of a certificate to a particular \ncommunity and/or class of application with common security requirements.  For example, a particular \nCP might indicate applicability of a type of certificate to the authe ntication of parties engaging in \nbusiness -to-business transactions for the trading of goods or services within a given price range  (IETF \nRFC 3647 ). \nCertificate Revocation List (CRL) Distribution Point (CDP)  \u2013 A web server that hosts a copy of a CRL \nissued by a CA for VPN Compo nents to download (see Key Management Requirements Annex ). \nCommercial National Security Algorithm (CNSA) - Set o", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}921{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "127", "chunk": "f commercial algorithms capable of protecting \ndata through Top Secret level (previously known as Suite B).  \nCommittee on Nat ional Security Systems Policy No. 15 (CNSSP -15) \u2013 Policy specifies which public \nstandards may be used for cryptographic protocol and algorithm interoperability to pro tect NSS . \nConfidentiality  \u2013 Assurance that the data stored in, processed by, or transmitte d by the system are \nprotected against unauthorized disclosure , and confidence that only the appropriate set of individuals or \norganizations would be provided the information.  \nContinuous Physical Control  - The AO defines what is considered \u201cContinuous Physi cal Control.\u201d \nPreviously called \u201cpositive control.\u201d  \nControl Plane Protocol  \u2013 A routing, signaling, or similar protocol whose endpoints are network \ninfrastructure devices such as VPN Gateways or routers.  Control plane protocols carry neither user data \nnor management traffic.  \nCross Domain Solution (CDS)  \u2013 A form of controlled interface that provides the ability to manually \nand/or automatically access and/or transfer information bet ween different security domains  \n(Committee on National Security Systems Instru ction CNSSI  4009 ). \nData  Plane Protocol  \u2013 A protocol that carries the data being transferred through the solution.  \n", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}922{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "128", "chunk": "End User Device (EUD)  \u2013 A form -factor agnostic component of the WLAN  solution that can include a \nmobile phone, tablet, or laptop computer .  EUDs can be composed of multiple components to provide \nphysical separation between layers o f encryption.  \nFederal Information Processing Standards (FIPS)  \u2013 A set of standards that describe the handling and \nprocessing of information within governmental agen cies.  \nGray Box Testing  \u2013 The ability to test functionality within a component of the solution, such that full \nmanagement privileges are granted (i.e. , knowing passwords for security administrator and Auditor and \naccess to the capabilities associated with t hose privileges).   In addition, the use of any and all testing \nequipment and/or testing software used inside and outside the developed solution is available.58 \n Gray Network  \u2013 A network that contains classified data that has been encrypted once ( see Section  \n4.1.2). \nGray Firewall  \u2013 A stateful traffic filtering firewall placed on the Gray Network  to provide filtering of \nports, protocols, and IP addresses to ensure traffic reaches the correct Inner Encryption Endpoint or is \ndropped .  \nInternal Interface  \u2013 The inte rface on a VPN Gateway or Inner Encryption Component that connects to \nthe inner network (i.e., the", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}923{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "129", "chunk": " Gray Network  on the WLAN Access System  or the Red Network  on the Inner \nEncryption Component ). \nLocally Managed Device  \u2013 A device that is being managed by the direct connection of the \nAdministration Workstation to the device in a hardwired fashion (such as a console cable).  \nMalicious \u2013 Any unauthorized events that are either unexplained or in any way indicate adversary \nactivity . \nManagement  Plane Protocol  \u2013 A protocol that carries either traffic between a system administrator and \na component being managed, or log messages from a solution component to a SIEM or similar \nrepository.  \nProtection Profile  \u2013 A document used as part of the certification process according to the Common \nCriteria.  As the generic form of a security target, it is typically created by a user or user community and \nprovides an implementation independent specification of information  assurance security requirements.  \nPublic Key Infrastructure (PKI)  \u2013 Framework established to issue, maintain, and revoke public key \ncertificates.  \nRed Network \u2013 A network that contains classified data that is not encrypted (see Section  4.3.1 ) \nRemotely Managed Device  \u2013 A device that is being managed by any other method besides that given in \nthe definition of a Locally Managed Device.  \nSecurity Level  \u2013 Th", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}924{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "130", "chunk": "e combination of classification level, list of compartments, dissemination controls, \nand other controls  applied to the information within a network.  \nSplit -tunneling  \u2013 Allows network traffic to egress through a path other than the established VPN tunnel \n(either on the same interface or another network interface).  Split tunneling is explicitly prohibited in \nWLAN CP compliant configurations (see WLAN -CR-12).   \nSecure Real-Time Protocol (SRTP)  Client  \u2013 A component on the EUD that facilitates encryption for voice \ncommunications.  \nTransport Layer Security (TLS)  Client  \u2013 A component on a TLS EUD that  provide s the I nner layer of Data \nin Transit (DIT) encryption.  \nTLS Component  \u2013 Refers to both TLS Clients and TLS -Protected Servers.  \nVirtual Private Network (VPN)  Client  \u2013 A VPN application installed on an EUD.  \nVPN Component  \u2013 The term used to refer to VPN Gateways and VPN Clients.59 \n VPN Gateway  \u2013 A VPN device physically located within the VPN infrastructure.  \nVPN Infrastructure  \u2013 Physically protected in a secure facility and includes Inner, Certificate Authorities, \nand Administration Workstations, but does not include EUDs .60 \n APPENDIX B. ACRONYMS  \nAcronym  Meaning  \nACL Access Control List  \nAES Advanced Encryption Standard  \nAO Authorizing Official", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}925{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "131", "chunk": "  \nAP Access Point  \nARP Address Resolution Protocol  \nAS Authentication Server  \nBIOS  Basic Input/Output System  \nCA Certificate Authority  \nCAA  Certificate Authority Administrator  \nCBC Cipher Block Chaining  \nCDP CRL Distribution Point  \nCDS Cross Domain Solution  \nCNSS  Committee on National Security Systems  \nCNSSI  Committee on National Security Systems Instruction  \nCNSSP  Committee on  National Security Systems Policy  \nCOTS  Commercial Off -the-Shelf  \nCP Capability Package  \nCPS Certification Practice Statement  \nCRL Certificate Revocation List  \nCSfC  Commercial Solutions for Classified  \nCSV Comma Separated Value  \nCUI Controlled Unclassified Information  \nDAR  Data -At-Rest  \nDDoS  Distributed Denial of Service  \nDH Diffie -Hellman  \nDHCP  Dynamic Host Configuration Protocol  \nDHS  Department of Homeland Security  \nDM Device Management  \nDN Domain Name  \nDNS  Domain Name System  \nD/NM  Deputy National Manager  \nDoD  Department of Defense  \nDoE Department of Energy  \nDoS Denial of Service  \nDSA Digital Signature Algorithm  \nEAP-TLS Extensible Authentication Protocol -Transport Layer Security  \nECDH  Elliptic Curve Diffie -Hellman  \nECDHE  Elliptic Curve Diffie -Hellman Ephemeral  \nECDSA  Elliptic Curve Digital Signature Algorithm  \nESP Encapsulating Security Payload", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}926{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "132", "chunk": "  \nEST Enrollment Over Secure Transport  \nEUD  End User Device  \nFIPS  Federal Information Processing Standards  \nGCM  Galois Counter Mode  \nGOTS  Government Off -the-Shelf  \nGPS Global Positioning System  \nHIDS  Host Based Intrusion Detection System61 \n Acronym  Meaning  \nHMAC  Hash -based Message Authentication Code  \nHSM  Hardware Security Module  \nHTTP  Hypertext Transfer Protocol  \nHTTPS  Hypertext Transfer Protocol Secure  \nIA Information Assurance  \nIAVA  Information Assurance Vulnerability Alert  \nICT Information Communication Technology  \nIDS Intrusion Detection System  \nIEEE  Institute of Electrical and Electronics Engineers  \nIETF  Internet Engineering Task Force  \nIKE Internet K ey Exchange  \nIP Internet Protocol  \nIPS Intrusion Prevention System  \nIPsec  Internet Protocol Security  \nIS-IS Intermediate System to Intermediate System  \nJIMS  Joint Incident Management System  \nKM Key Management  \nKMI Key Management Infrastructure  \nMAC  Media Access Control  \nMDM  Mobile Device Manager  \nMOA  Memorandum of Agreement  \nNDP  Neighbor Discovery Protocol  \nNIAP  National Information Assurance Partnership  \nNIDS  Network -based Intrusion Detection System  \nNIST  National Institute of Standards and Technology  \nNPE Non Person Entity  \nNSA National Security Agency  \nNSS Nationa", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}927{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "133", "chunk": "l Security Systems  \nNTP Network Time Protocol  \nO Objective  \nOCSP  Online Certificate Status Protocol  \nOID Object Identifier  \nOPSEC  Operational Security  \nOS Operating System  \nOSI Open System Interconnection  \nOSPF  Open Shortest Path First  \nPKCS  Public Key Cryptographic Standard  \nPKI Public Key Infrastructure  \nPMK  Pairwise -Master Key  \nPOC  Point of Contact  \nPTP Precision Time Protocol  \nRADIUS  Remote Authentication Dial in User Service  \nRDP Remote  Desktop Protocol  \nRFC Request for Comment  \nRSA Rivest Shamir Adelman algorithm  \nS3 Secure Sharing Suite  \nSA Security Association  \nSCRM  Supply Chain Risk Management  \nSHA Secure Hash Algorithm62 \n Acronym  Meaning  \nSIEM  Security Information and Event Management  \nSIPRNet  Secret Internet Protocol Router Network  \nSRTP  Secure Real -Time Protocol  \nSSH Secure Shell  \nSSID  Service Set Identifier  \nSSHv2  Secure Shell Version 2  \nT Threshold  \nT&E Test and Evaluation  \nTFFW  Traffic Filtering Firewall  \nTLS Transport Layer Security  \nURL Uniform  Resource Locator  \nVLAN  Virtual Local Area Network  \nVM Virtual Machine  \nVPN  Virtual Private Network  \nWIDS  Wireless Intrusion Detection System  \nWIPS  Wireless Intrusion Prevention System  \nWLAN  Wireless Local Area Network  \nWPA  Wi-Fi Protected Access  \nWPA2  Wi-Fi", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}928{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "134", "chunk": " Protected Access 2  \nWPA3  Wi-Fi Protected Ac cess 363 \n APPENDIX C. REFERENC ES \nCNSSI 1300  CNSSI 1300, National Security Systems Public Key Infrastructure X.509 \nCertificate Policy  February \n2019   \nCNSSI 4009  CNSSI 4009, National Information Assurance (IA) Glossary Committee for \nNational Security Systems.   April 2015  \nCNSSP 15  CNSS Policy (CNSSP) Number 15, Use of Public Standards for Secure \nInformation Sharing  October \n2016  \nCNSSD 505  CNSS Directive (CNSSD) Number 505, Supply Chain Risk Management \n(SCR M) November \n2021  \nCSfC CM \nAnnex  CSfC Continuous Monitoring Annex, v1.0  August \n2021  \nCSfC Data -at-\nRest CP  CSfC Data -at-Rest Capability Package, v5.0  November \n2020   \nCSfC KM Req. \nAnnex  CSfC Key Management Requirements Annex, v2.0  October  \n2021  \nCSfC \nSymmetric \nKM Req. \nAnnex  CSfC Symmetric Key Management Requirements Annex, v2.0  October  \n2021  \nCSfC \nWIDS/WIPS \nAnnex  CSfC Wireless Intrusion Detection System (WIDS)/Wireless Intrusion \nPrevention System (WIPS) Annex, v1.0  February \n2021  \nFIPS 140 -3 Federal Information Processing Standard 140, Security Requirements For \nCryptographic Modules National Institute for Standards and Technology \nFIPS Publication   March \n2019  \nFIPS 180 -4 Federal Information Processing Standard 180 -4, Secure Hash ", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}929{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "135", "chunk": "Standard \n(SHS)  August \n2015 \nFIPS 186 -4 Federal Information Processing Standard 186 -4, Digital Signature \nStandard (DSS)  July 2013  \nFIPS 197  Federal Information Processing Standard 197, Advanced Encryption \nStandard (AES)  November \n2001  \nFIPS 201 -2 Federal Information Processing Standard 201 -2, Personal Identity \nVerification (PIV) of Federal Employees and Contractors  August \n2015  \nIPsec VPN  \nClient PP  Virtual Private Network PP -Module for VPN Client , Version 2. 3 August  \n2021  \nISO 09594 -8  Iso9594 -8 Information Technology -Open System s Interconnection -The \nDirectory  \u2013 Part 8: Public -key and attribute certificate f ramework s March \n2013  \nCommercial \nNational \nSecurity \nAlgorithm \nSuite  NSA Guidance on Encryption Algorithms  \n  \nDecember \n201564 \n RFC 2409  IETF RFC 2409 The Internet Key Exchange (IKE) . D. Harkins and D. Carrel.  November \n1998  \nRFC 3647  IETF RFC 3647 Internet X.509 Public Key Infrastructure Certificate Policy \nand Certification Practices Framework  Internet Engineering Task Force  November \n2003  \nRFC 3711  IETF RFC 3711 The Secure Real -Time Transport Protocol (SRTP). M. \nBaugher and D. McGrew.  March  \n2004  \nRFC 4252  IETF RFC 4252 The Secure Shell (SSH) Authentication Protocol . T. Ylonen \nand C. Lonvick.  January \n2006  \nRFC 42", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}930{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "136", "chunk": "53  IETF RFC 4253 The Secure Shell (SSH)  Transport Layer Protocol . T. Ylonen \nand C. Lonvick.  January \n2006  \nRFC 4254  IETF RFC 4254 The Secure Shell (SSH) Connection Protocol . T. Ylonen and  \nC. Lonvick.  January \n2006  \nRFC 4256  IETF RFC 4256 Generic Message Exchange Authentication for the Secure \nShell Protocol (SSH) . F. Cusack and M. Forssen.  January \n2006  \nRFC 4302  IETF RFC 4302 IP Authentication Header . S. Kent  December \n2005  \nRFC 4303  IETF RFC 4303 IP Encapsulating Security Payload . S. Kent  December \n2005  \nRFC 4307  IETF RFC 4307 Cryptographic Algo rithms for Use in the Internet Key \nExchange Version 2 (IKEv2) . J. Schiller  December \n2005  \nRFC 4308  IETF RFC 4308 Cryptographic Suites for IPsec . P. Hoffman  December \n2005  \nRFC 4492  IETF RFC 4492 Elliptic Curve Cryptography (ECC) Cipher Suites for \nTransport Layer Security (TLS). S. Blake -Wilson, N. Bolyard, V. Gupta, C. \nHawk Corriente, B. Moeller, and Ruhr -Uni Bochum.  May 2006  \nRFC 4754  IETF RFC 4754 IKE and IKEv2 Authentication Using  the Elliptic Curve Digital \nSignature Algorithm (ECDSA) . D. Fu and J. Solinas.  January \n2007  \nRFC 5246  IETF RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2 . T. \nDierks and E. Rescorla.  August \n2008  \nRFC 5280  IETF RFC 5280 Internet X.509 Pub", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}931{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "137", "chunk": "li c Key Infrastructure Certificate and \nCertificate Revocation List (CRL) Profile . D. Cooper, et. al.  May 2008  \nRFC 5996  IETF RFC 5996 Internet Key Exchange Protocol Version 2 (IKEv2) .  \nC. Kaufman, et. al.  September \n2010  \nRFC 6188  IETF RFC 6188 The Use of AES 192 and AES 256 in Secure RTP. D. McGrew.  March \n2011  \nRFC 6818  IETF RFC 6818 Updates to the Internet X.509 Public Key Infrastructure \nCertificate and Certificate Revocation List (CRL) Profile . P. Yee  January \n2013  \nRFC 7030  IETF RFC 7030 Enrollment over Secure Transport . M. Pritikin, P. Yee, and \nD. Harkins.  October \n2013  \nSP 800 -53 NIST Special Publication 800 -53 Rev. 5, Security and Privacy Controls for \nFederal Information Systems and Organizations . December  \n202065 \n SP 800 -56A NIST Special Publication 800 -56A Rev. 3, Recommendation for Pair -Wise \nKey Establishment Schemes Using Discrete Logarithm Cryptography . E. \nBarker, et. al.  April 2018  \nSP 800 -56B NIST Special Publication 800 -56B Rev. 2, Recommendation for Pair -Wise \nKey Establishment Schemes Using Integer Factorization Cryptography . E. \nBarker, et. al.  March \n2019  \nSP 800 -56C NIST Special Publication 800 -56C Rev. 2, Recommendation for Key \nDerivation Methods  in Key -Establishment Schemes . L. Chen.  August \n2020  \nSP 800 -1", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}932{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "138", "chunk": "31A  NIST Special Publication 800 -131A Rev. 2, Transitioning the Use of \nCryptographic Algorithms and Key Lengths . E. Barker.  March \n2019  \nSP 800 -147 \n NIST Special Publication 800 -147, BIOS Protection Guidelines . D. Cooper, \net. al. April 201166 \n APPENDIX D. TACT ICAL SOLUTION IMPLEM ENTATIONS  \nAlthough the majority of customers instantiating solutions based on the Campus WLAN CP will be used \nfor Strategic or Operational Environments, some organizations may deploy the Campus WLAN CP in \nTactical Environments.  These Tactical Environments include a  specific set of Size, Weight, and Power \n(SWaP) constraints not found in traditional environments.  \nOrganizations intending to deploy a Campus WLAN CP Solution for Tactical Environments may use this \nAppendix, which accommodates the SWaP constraints unique to their environment.  This Appendix may \nonly be used to protect Tactical Data classified as SECRET or below.  The CP follows CNSSI 4009, which \ndefines Tactical Data as, \u201cInformation that requires protection from disclosure and modification for a \nlimited d uration as determined by the originator or information owner.\u201d  In addition to protecting \nTactical Data, organizations that register their solution using this Appendix must be deployed at the \nTactical Edge.  The CP", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}933{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "139", "chunk": " follows CNSSI 4009, which defines the Tac tical Edge as, \u201cThe platforms, sites, and \npersonnel (U.S. military, allied, coalition partners, first responders) operating at lethal risk in a battle \nspace or crisis environment characterized by 1) a dependence on information systems and connectivity \nfor survival and mission success, 2) high threats to the operational readiness of both information \nsystems and connectivity, and 3) users are fully engaged, highly stressed, and dependent on the \navailability, integrity, and transparency of their information sy stems.\u201d  \n \nIf an organization\u2019s planned solution meets the three criteria above then their solution may be \nregistered using the requirement accommodations in this Appendix.  The Campus WLAN CP Registration \nform must explicitly state that the solution is bein g used in Tactical Environments and provide \njustification on how the above criteria are met.  In general, customers registering with this Appendix will \nbe deployed in support of Battalion and below (or equivalent) unit structure.  Typically, these Tactical  \nEnvironments are located in austere environments where communication infrastructure is generally \nlimited.   \n \nTable 2 8 defines the Tactical Implementation Overlay Requirements and may be used by customers \nmeeting", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}934{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "140", "chunk": " the criteria above when they configure, tes t, register, and operate their Campus WLAN \nSolution.  All other requirements stand as written in the body of the CP.  Any questions on the use of this \nAppendix should be directed to wi-fi@nsa.gov  and csfc@nsa.gov . \nTable 28. Tactical Implementation Overlay Requirements  \nReq #  Requirement Description  Threshold/ \nObjective  Alternative  \nWLAN -PS-11 The WLAN Access System, Gray Firewall, Inner VPN \nGateway  and Inner Firewall must use physically \nseparate components, such that no component is \nused for more than one function.  O WLAN -TO-1 \nWLAN -TO-1 The WLAN Access System must be physically \nseparate from the Inner Encryption Components.  T WLAN -PS-11 \nWLAN -EU-7 Rekeying of an EUD\u2019s certificates and associated \nprivate keys must be done through re -provisioning \nprior to expiration of keys.  O67 \n Req #  Requirement Description  Threshold/ \nObjective  Alternative  \nWLAN -EU-12 Red Network services must not transmit any \nclassified data to EUDs until user authentication \nsucceeds.  O  \nWLAN -EU-33 USB mass storage mode must be disabled on the \nEUDs.  O  \nWLAN -GD-21 The implementing organization must develop a \ncontinuity of operations plan for auditing \ncapability, which includes a mechanism or method \nfor determining when the", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}935{"doi": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "chunk-id": "141", "chunk": " audit log is rea ching its \nmaximum storage capacity.  O  \nWLAN -GD-22 The implementing organization must develop a \ncontinuity of operations plan for auditing \ncapability, which includes a mechanism or method \nfor off -loading audit log data for long - term \nstorage.  O  \nWLAN -GD-23 The implementing organization must develop a \ncontinuity of operations plan for auditing \ncapability, which includes a mechanism or method \nfor responding to an overflow of audit log data \nwithin a product.  O  \nWLAN -GD-24 The implementing organizati on must develop a \ncontinuity of operations plan for auditing capability \nwhich includes a mechanism or method for \nensuring that the audit log can be maintained \nduring power events.  O  \nWLAN -WIDS -0 Meet all requirements defined in the CSfC  Wireless \nIntrusion  Detection System/Wireless Intrusion \nPrevention System (WIDS/WIPS) Requirements \nAnnex that apply to the WLAN CP for government \nprivate wireless.  O", "id": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "title": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "source": "(U) Approved Campus WLAN CP v3_0_1 - Copy", "authors": [], "categories": [], "references": []}936{"doi": "NIST.SP.800-53r5", "chunk-id": "0", "chunk": "NIST Special Publication 800 -53 \nRevision 5  \n \n \nSecurity and Privacy Control s for \nInformation  Systems  and Organizations  \n \n \n \n \nJOINT TASK FORCE  \n  \n \n \nThis publication is available free of charge from:  \nhttps://doi.org/10.6028/NIST.SP.800- 53r5NIST Special Publication 800 -53 \nRevision 5  \n \n \n Security and Privacy Controls for \nInformation Systems and Organizations                                                                                                 \n \n  \nJOINT TASK FORCE  \n \n \n \n \n \n \n \nThis publication is available free of charge from:  \nhttps://doi.org/10.6028/NIST.SP.800- 53r5   \n \n \n \n \nSeptember  2020  \nINCLUDES UPDATES AS OF 12- 10-2020; SEE PAGE XVII  \n \n \n  \n \n \n \n \n \n \n \nU.S. Department of Commerce  \nWilbur L. Ross, Jr., Secretary  \n \nNational Institute of Standards and Technology  \n      Walter Copan, NIST Director and Under Secretary of Commerce for Standards and TechnologyNIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \ni \nThis publication is availabl", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}937{"doi": "NIST.SP.800-53r5", "chunk-id": "1", "chunk": "e free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n Authority  \nThis publication has been developed by NIST to further its statutory responsibilities under the \nFederal Information Security Modernization Act (FISMA), 44 U.S.C. \u00a7 3551 et seq. , Public Law \n(P.L.) 113 -283. NIST is responsible for developing information security standards and guidelines, \nincluding minimum requirements for federal informatio n systems . Such information security \nstandards and guidelines shall not apply to national security systems without the express \napproval of the appropriate federal officials exercising policy authority over such systems. This \nguideline is consistent with the requirements of the Office of Management and Budget (OMB) \nCircular A-130.  \nNothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce  under statutory \nauthority. Nor should these guidelines be interpreted as altering or superseding the existing \nauthorities of the Secretary of Commerce, OMB Director, or any other federal official. This \npublication may be used by nongovernmental organizati ons on a voluntary basis and is not \nsubject to copyright in the United States. Attribution would, however, be ap", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}938{"doi": "NIST.SP.800-53r5", "chunk-id": "2", "chunk": "preciated by NIST.   \nNational Institute of Standards and Technology Special Publication 800 -53, Revision 5  \nNatl. Inst. Stand. Technol.  Spec. Pub l. 800 -53, Rev. 5 , 492 pages  (September  2020 ) \nCODEN: NSPUE2  \nThis publication is available free of charge from:  \nhttps://doi.org/10.6028/NIST.SP.800- 53r5   \n \n \n \n \n \n \n \n \n \n \n \n \n \n \nComments on this publication may be submitted to:  \nNational Institute of Standards and Technology  \nAttn: Computer Security Division, Information Technology Laboratory  \n100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899 -8930  \nEmail: sec-cert@nist.gov   \nAll comments are subject to release under the Freedom of Information Act (FOIA)  [FOIA96 ]. Certain commercial entities, equipment, or materials may be identified in this document to describe \nan experimental procedure or concept adequately. Such identification is not intended to imply \nrecommendation or endorsement by NIST, nor is it intended to imply that the entities, materials, or \nequipment are necessarily the best available for the purpose.  \nThere may be references in this publication to other publications currently under development by \nNIST in accordance with its assigned statutory responsibilities. The information in this publication, \nincluding concepts, practices, and met", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}939{"doi": "NIST.SP.800-53r5", "chunk-id": "3", "chunk": "hodologies may be u sed by federal agencies even before the \ncompletion of such companion publications. Thus, until each publication is completed, current \nrequirements, guidelines, and procedures, where they exist, remain operative. For planning and \ntransition purposes, federa l agencies may wish to closely follow the development of these new \npublications by NIST.   \nOrganizations are encouraged to review draft publications during the designated public comment \nperiods and provide feedback to NIST. Many NIST publications, other than the ones noted above, \nare available at https://csrc.nist.gov/publications .NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nii \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n Reports on Computer Systems Technology  \nThe National Institute of Standards and Technology (NIST) Information Technology Laboratory \n(ITL) promotes the U.S. economy and public welfare by providing technical leadership for the \nNation\u2019s", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}940{"doi": "NIST.SP.800-53r5", "chunk-id": "4", "chunk": " measurement and standards infrastructure. ITL develops tests, test methods, reference \ndata, proof of concept implementations, and technical analyses to advance the development \nand productive use of informatio n technology (IT). ITL\u2019s responsibilities include the development \nof management, administrative, technical, and physical standards and guidelines for the cost -\neffective security of other than national security-related information in federal information systems. The Special Publication 800 -series reports on ITL\u2019s research, guidelines, and outreach \nefforts in information systems security and privacy and its collaborative activities with industry, \ngovernment, and academic organizations. \nAbstract  \nThis publicati on provides a catalog of security and privacy c ontrols for information systems and \norgan izations to protect organizational operations and assets, individuals, other organizations, \nand the Nation from a diverse set of threats  and risks , including hostile attacks , human errors, \nnatural disa sters, structural failures, foreign intelligence entities, and privacy risks . The controls \nare flexible and customizable and implemented as part of an organiz ation -wide process to \nmanage risk. The contr ols address diverse requirement s derived from mission and b", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}941{"doi": "NIST.SP.800-53r5", "chunk-id": "5", "chunk": "usiness \nneeds, laws , executive orders, directives, regulations, policies, standards , and guidelines . Finally, \nthe consolidated control catalog address es security and privacy from a functionality perspective \n(i.e., the strength of functions and mechanisms  provided by the controls ) and from an assurance \nperspective ( i.e., the measure of confidence in the security or privacy capability  provided by the \ncontrols ). Addressin g functionality and assurance helps to ensure that information technology  \nproducts and the systems that rely on those products are sufficiently trustworthy.  \nKeywords  \nAssurance; availability; computer security; confidentiality; control; cybersecurity; FISMA; \ninformation security; information system; integrity; personally identifiable information; Privacy \nAct; privacy controls; privacy functions; privacy requirements; Risk Management Framework; \nsecurity controls; security function s; security requirements ; system; system security .NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_______________________________________________________________________", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}942{"doi": "NIST.SP.800-53r5", "chunk-id": "6", "chunk": "__________________________  \niii \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n Acknowledgements  \nThis publication was developed by the Joint Task Force  Interagency Working Group. The group \nincludes representatives from the c ivil, defense, and intelligence communities. The National \nInstitute of Standards and Technology wishes to acknowledge and thank the senior leaders from \nthe Department of Commerce , Dep artment of Defense, the Office of the Director of National \nIntelligence, the Committee on National Security Systems, and the members of the interagency working group whose dedicated efforts contributed significantly to th is publication. \nDepartment of Defen se Office of the Director of National \nIntelligence  \nDana Deasy       Matthew A. Kozma                                                                                                                                                                                                 \nChief Information Officer      Chief Information Officer  \nJohn Sherman                                                                                   Michael E. Waschull  \nPrincipal Deputy CIO  Deputy Chief Information Officer  \nMark Hakun                                                   ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}943{"doi": "NIST.SP.800-53r5", "chunk-id": "7", "chunk": "                                 Clifford M. Conner  \nDeputy CIO for Cybersecurity  and DoD SISO  Cybersecurity Group and IC CISO  \nKevin Dulany       Vacant  \nDirector, Cybersecurity Policy and Partnerships    Director, Security Coordination Center \nNational Institute of Standards    Committee on National Security \nand Technology      Systems  \nCharles H. Romine       Mark G. Hakun  \nDirector, Information Technology Laboratory  Chair  \nKevin Stine       Susan Dorr  \nActing Cybersecurity Advisor, ITL     Co-Chair  \nMatthew  Scholl       Kevin Dulany  \nChief, Computer Security Division     Tri-Chair\u2014 Defense Community  \nKevin Stine       Chris Johnson  \nChief, Applied Cybersecurity Division     Tri-Chair\u2014 Intelligence Community  \nRon Ross        Vicki Michetti  \nFISMA Implementation Project Leader     Tri-Chair\u2014 Civil Agencies  \nJoint Task Force Working Group  \nVictoria Pillitteri        McKay Tolboe    Dorian Pappas   Kelley Dempsey  \nNIST, JTF Leader        DoD    Intelligence Community  NIST  \nEhijele Olumese        Lydia Humphries    Daniel Faigin   Naomi Lefkovitz  \nThe MITRE Corporation        Booz Allen Hamilton   Aerospace Corporation  NIST  \nEsten Porter       Julie Nethery Snyder   Christina Sames   Christian Enloe  \nThe MITRE Corporation       The MITRE Corporation   Th", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}944{"doi": "NIST.SP.800-53r5", "chunk-id": "8", "chunk": "e MITRE Corporation  NIST  \nDavid Black        Rich Graubart    Peter Duspiva   Kaitlin Boeckl   \nThe MITRE Corporation       The MITRE Corporation   Intelligence Community  NIST     \nEduardo Takamura       Ned Goren    Andrew Regenscheid Jon Boyens   \nNIST         NIST     NIST    NISTNIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \niv \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n In addition to the above acknowledgments, a special not e of thanks goes to Jeff Brewer, Jim \nFoti, and the NIST web team for their outstanding administrative support. The authors also wish \nto recognize Kristen Baldwin, Carol Bales, John Bazile, Jennifer Besceglie, Sean Br ooks, Ruth \nCannatti, Kathleen Coupe, Keesha Crosby, Charles Cutshall, Ja\u2019Nelle DeVore, Jennifer Fabius, Jim \nFenton, Hildy Ferraiolo, Ryan Galluzzo, Robin Gandhi, Mike Garcia, Paul Grassi, Marc Groman , \nMatthew Halstead, Kevin Herms, Scott Hill, Ralph Jones, Martin Kihiko, Raquel Leone, Ja", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}945{"doi": "NIST.SP.800-53r5", "chunk-id": "9", "chunk": "son \nMarsico, Kirsten Moncada, Ellen Nadeau, Elaine Newton, Michael Nieles, Michael Nussdorfer, \nTaylor Roberts, Jasmeet Seehra, Joe Stuntz, Jeff Williams, the professional staff  from the NIST \nComputer Security  Division and Applied Cybersecurity Division , and the representatives from \nthe Federal CIO Council , Federal CISO Council, Federal Privacy Council, Control Baseline \nInteragency Working Group , Security and Privacy Collaboration Working Group , and  Federal \nPrivacy Council  Risk Management Subcommittee for their ongoing contributions in helping to \nimprove th e content of the publication.  Finally, the authors gratefully acknowledge the \ncontributions fr om individuals and organizations in the public and private sectors,  both \nnationally and internationally, whose insightful  and constructive comments improved the \noverall quality, thoroughness, and usefulness of this publication.   \nHISTORICAL CONTRIBUTIONS TO NIST SPECIAL PUBLICATION 800-53 \nThe authors wanted to acknowledge the many individuals who contributed to previous versions \nof Special Publication 800 -53 since its inception in 2005. They include Marshall Abrams, Dennis \nBailey, Lee Badger, Curt Barker, Matt hew  Barrett, Nadya Bartol, Frank Belz, Paul Bicknell, Deb \nBodeau, Paul Brusil, Brett Burley, Bill ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}946{"doi": "NIST.SP.800-53r5", "chunk-id": "10", "chunk": "Burr, Dawn Cappelli, Roger Caslow, C orinne Castanza, Mike \nCooper, Matt Coose, Dominic Cussatt, George Dinolt, Randy Easter, Kurt Eleam,  Denise Farrar, \nDave Ferraiolo, Cita Furlani, Harriett Goldman, Peter Gouldmann, Tim Grance, Jennifer Guild, Gary Guissanie, Sarbari Gupta, Priscilla Guthrie , Richard Hale, Peggy Himes, Bennett Hodge, \nWilliam Hunteman, Cynthia Irvine, Arnold Johnson, Roger Johnson, Don ald Jones, Lisa Kaiser, \nStuart Katzke, Sharon Keller, Tom Kellerman n, Cass Kelly, Eustace King, Daniel Klemm, Steve \nLaFountain, Annabelle Lee, R obert Lentz, Steven  Lipner, William  MacGregor, T homas  Macklin, \nThomas  Madden, Robert Martin, Erika McCallister, Tim McChesney, Michael McEvilley, Rosalie \nMcQuaid, Peter Mell, John Mildner, Pam Miller, Sandra Miravalle, Joji Montelibano, Doug las \nMontgomery,  George Moore, Rama Moorthy, Mark Morrison, Harvey Newstrom, Sherrill Nicely, \nRobert Niemeyer, LouAnna Notargiacomo, Pat O\u2019Reilly, Tim Polk, Karen Quigg, Steve Quinn, \nMark Riddle, Ed Roback, Cheryl Roby, George Rogers, Scott Rose, Mike Rubin, Karen Scarfone, \nRoger Schell, Jackie Snouffer, Ray Snouffer, Murugiah Souppaya, Gary Stoneburner, Keith \nStouffer, Marianne Swanson, Pat Toth, Glenda Turner, Pat rick Viscuso, Joe Weiss, Richard \nWilsher, Mark Wilson, John Woodwa", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}947{"doi": "NIST.SP.800-53r5", "chunk-id": "11", "chunk": "rd, and Carol Woody.NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nv \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n Patent Disclosure Notice  \nNOTICE: The Information Technology Laboratory (ITL) has requested that holders of patent \nclaims whose use may be required for compliance with the guidance or requirements of this \npublication disclose such patent claims to ITL. However, holders of patents are not obligated to \nrespond to ITL calls for patents and ITL has not undertaken a patent search in order to identify \nwhich, if any, patents may apply to this publication.  \n  \nAs of the date of publication and following call(s) for the identification of patent claims whose use may be required for compliance with the guidance or requirements of this publication, no such patent claims have been identified to ITL.   \n  \nNo representation is made or implied by ITL that licenses are not required to avoid patent \ninfringement in the use of this pub", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}948{"doi": "NIST.SP.800-53r5", "chunk-id": "12", "chunk": "lication.NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nvi \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n   \nRISK MANAGEMENT  \nOrganizations must exercise  due diligence in managing information security  and privacy risk. This \nis accomplished, in part, by  establish ing a comprehensive risk management program  that uses \nthe flexibility inherent in NIST publications to categorize systems, select and implement security \nand priva cy controls that meet mission and business needs, assess the effectiveness of the \ncontrols, authorize the systems for operation, and continuously monitor the system s. Exercising \ndue diligence and implementing robust and comprehensive information security a nd privacy risk \nmanagement programs can facilitate compliance with applicable laws, regulations, executive \norders, and governmentwide policies. Risk management frameworks and risk management \nprocesses are essential in developing, implementing, and mainta", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}949{"doi": "NIST.SP.800-53r5", "chunk-id": "13", "chunk": "in ing the protection measures \nnecessary to address stakeholder needs and the current threats to organizational operations and assets, individuals, other organizations, and the Nation. Employing effective risk -based \nprocesses, procedures, methods, and technol ogies ensure s that information systems and \norganizations have the necessary trustworthiness and resiliency to su pport essential mission and \nbusiness functions, the U.S. critical infrastructure , and continuity of government.NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nvii \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n   \nCOMMON SECURITY AND PRIVACY FOUNDATIONS  \nIn working with the Office of Management and Budget to develop standards and guidelines \nrequired by FISMA, NIST consults with federal agencies, state, local, and tribal governments, and \nprivate sector organizations to improve information security and privacy , avoid unnecessary and \ncostly duplication of effort , ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}950{"doi": "NIST.SP.800-53r5", "chunk-id": "14", "chunk": "and help ensure that its publications are complementary with the \nstandards and guidelines used for the protection of national security systems. In addition to a \ncomprehensive and t ransparent public review and comment process, NIST is engaged in a \ncollaborative partnership with the Office of Management and Budget, Office of the Director  of \nNational Intelligence, Department of Defense, Committee on N ational Security Systems, Federal \nCIO Council, and Federal Privacy Council to establish  a Risk Management Framework  (RMF)  for \ninformation security and privacy  for the Federal Government. This co mmon foundation provides \nthe Federal Government and their cont ractors  with cost-effective, flexible, and consi stent ways \nto manage  security and privacy  risks to organizational operations and assets, individuals, other \norganizatio ns, and the Nation. The framework provide s a basis for the reciprocal acceptance of \nsecur ity and privacy control assessment evidence and authorization decisions and facilitates \ninformation sharing and collaboration. NIST continues to work with public and private sector \nentities to establish mappings and relationships between the standards and guidelines \ndeveloped by NIST and those developed by other organizations.  NIST anticipates using these", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}951{"doi": "NIST.SP.800-53r5", "chunk-id": "15", "chunk": " \nmappings and the gaps they identify to improve the control catalog.NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nviii \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n   \nDEVELOPMENT OF INFORMATION SYSTEMS, COMPONENTS, AND SERVICES  \nWith a  renewed emph asis on the use of trustworthy, secure information systems and supply \nchain security, it is essential that organizations express their security and privacy requirements \nwith clarity and specificity in order to  obtain the systems, components, a nd services necessary \nfor mission and business success. Accordingly, this publica tion provides controls in the System \nand Services Acquisition (SA) and Supply Chain Risk Management (SR) families that are directed \nat developers . The scope of the controls in those families includes information system, system \ncomponent, and system service development and  the associated developers whether the \ndevelopment i s conducted internally by organizat", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}952{"doi": "NIST.SP.800-53r5", "chunk-id": "16", "chunk": "ions or externally through the contracting and \nacquisition processes. Th e affected controls in the control catalog include SA-8, SA-10, SA-11, \nSA-15, SA-16, SA-17, SA-20, SA-21, SR-3, SR-4, SR-5, SR-6, SR-7, SR-8, SR-9, and SR-11.NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nix \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n   \nINFORMATION SYSTEMS \u2014  A BROAD -BASED PERSPECTIVE  \nAs we push computers to \u201cthe edge ,\u201d building an increasingly complex world of interconnected \nsystems and devices, security and privacy continue to do minate the national dialogue. There is \nan urgent need to further strengthen the underlying systems, products, and services that we \ndepend on in every sector of the critical infrastructure to ensur e that  those systems, products , \nand services are sufficiently trustworthy and provide the necessary resilience to support the \neconomic and national security interests of th e United States. NIST Special Publicat", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}953{"doi": "NIST.SP.800-53r5", "chunk-id": "17", "chunk": "ion 800- 53, \nRevision 5, responds to this need by embarking on a proactive and systemic approach to develop  \nand make available to a broad base of public and private sector organizations a comprehensive \nset of security and privacy safeguarding measures for all types of computing platforms, including \ngeneral purpose computing systems, cyber -physical systems, clou d systems, mobile systems, \nindustrial control systems,  and Internet of Things (IoT) devices.  Safeguarding measures include \nboth security and privacy controls to protect the critical and essential operations and assets of \norganizations and the privacy of individuals. The objective is to make the systems we depend on more penetration resistant to attacks , limit the damage from those attacks when they occur , \nand make the systems resilient , survivable , and protective of individuals\u2019 privacy.NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nx \nThis publication is available free of charge from: https://doi.org/10.6028/NIS", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}954{"doi": "NIST.SP.800-53r5", "chunk-id": "18", "chunk": "T.SP.800 -53r5 \n  \n  \nCONTROL BASELINES   \nThe control baselines that have previously been included in NIST Special Publication 800- 53 have \nbeen relocated to NIST Special Publication 800 -53B. SP 800- 53B contains security and privacy \ncontrol baselines for federal information systems and organizations. It provides guidance for  \ntailoring control baselines and for developing o verlays to support the security and privacy \nrequirements of stakeholder s and their organizations.  CNSS Instruction 1253  provides control \nbaselines and guidance for security categorization and security control selection for national \nsecurity systems.NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nxi \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n   \nUSE OF EXAMPLES IN THIS PUBLICATION   \nThroughout this publication, examples  are used to illustrate, clarify, or explain certain items in \nchapter sections, controls, and control enhancements. These examples are ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}955{"doi": "NIST.SP.800-53r5", "chunk-id": "19", "chunk": "illustrative in nature \nand are not  intended to limit or constrain the application of controls or control enhancements \nby organizations.NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nxii \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n   \nFEDERAL RECORDS MANAGEMENT COLLABORATION   \nFederal records management processes have a nexus with certain information security and \nprivacy requirements and controls. For example, records officers may be managing records \nretention, inclu ding when records will be deleted. Collaborating with records officers on the \nselection and implementation of security and privacy controls related to records management \ncan support consistency and efficiency and ultimately strengthen the organization\u2019s se curity and \nprivacy posture.NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS     ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}956{"doi": "NIST.SP.800-53r5", "chunk-id": "20", "chunk": "                                                             \n_________________________________________________________________________________________________  \nxiii \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n Table of Contents  \nCHAPTER  ONE    INTRODUCTION  ...................................................................................................... 1 \n1.1   PURPOSE  AND  APPLICABILITY  ................................ ................................ ................................ ... 2 \n1.2   TARGET  AUDIENCE  ................................ ................................ ................................ ..................  3 \n1.3   ORGANIZATIONAL  RESPONSIBILITIES ................................ ................................ .........................  3 \n1.4   RELATIONSHIP  TO OTHER  PUBLICATIONS  ................................ ................................ ...................  5 \n1.5   REVISIONS  AND  EXTENSIONS  ................................ ................................ ................................ .... 5 \n1.6   PUBLICATION  ORGANIZATION  ................................ ................................ ................................ .. 5 \nCHAPTER  TWO    THE FUNDAMENTALS  ............", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}957{"doi": "NIST.SP.800-53r5", "chunk-id": "21", "chunk": "................................................................................ 7 \n2.1   REQUIREMENTS  AND  CONTROLS  ................................ ................................ ..............................  7 \n2.2   CONTROL  STRUCTURE  AND  ORGANIZATION  ................................ ................................ ..............  8 \n2.3   CONTROL  IMPLEMENTATION  APPROACHES  ................................ ................................ .............  11 \n2.4   SECURITY  AND  PRIVACY  CONTROLS  ................................ ................................ .........................  13 \n2.5   TRUSTWORTHINESS  AND  ASSURANCE  ................................ ................................ .....................  14 \nCHAPTER  THRE E   THE CONTROLS  .................................................................................................  16 \n3.1   ACCESS  CONTROL  ................................ ................................ ................................ ..................  18 \n3.2   AWAREN ESS  AND  TRAINING  ................................ ................................ ................................ ... 59 \n3.3   AUDIT  AND  ACCOUNTABILITY  ................................ ................................ ................................", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}958{"doi": "NIST.SP.800-53r5", "chunk-id": "22", "chunk": " . 65  \n3.4   ASSESSMENT,  AUTHORIZATION,  AND  MONITORING  ................................ ................................ . 83 \n3.5   CONFIGURATION  MANAGEMENT  ................................ ................................ ...........................  96 \n3.6   CONTINGENCY  PLANNING  ................................ ................................ ................................ .... 115 \n3.7   IDENTIFICATION  AND  AUTHENTICATION  ................................ ................................ ...............  131 \n3.8   INCIDENT  RESPONSE ................................ ................................ ................................ ............  149 \n3.9   MAINTENANCE  ................................ ................................ ................................ ....................  162 \n3.10    MEDIA  PROTECTION  ................................ ................................ ................................ ..........  171 \n3.11    PHYSICAL  AND  ENVIRONMENTA L PROTECTION  ................................ ................................ .... 179 \n3.12    PLANNING  ................................ ................................ ................................ ........................  194 \n3.13    PROGRAM  MANAGEMENT  ................................ ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}959{"doi": "NIST.SP.800-53r5", "chunk-id": "23", "chunk": "................................ ................................ . 203 \n3.14    PERSONNEL  SECURITY  ................................ ................................ ................................ ........  222 \n3.15    PERSONALLY  IDENTIFIABLE  INFORMATION  PROCESSING  AND  TRANSPARENCY  .......................  229 \n3.16    RISK  ASSESSMENT  ................................ ................................ ................................ ..............  238 \n3.17    SYSTEM  AND  SERVICES  ACQUISITION  ................................ ................................ ..................  249 \n3.18    SYSTEM  AND  COMMUNICATIONS  PROTECTION  ................................ ................................ ... 292 \n3.19    SYSTEM  AND  INFORMATION  INTEGRITY  ................................ ................................ ..............  332 \n3.20    SUPPLY  CHAIN  RISK  MANAGEMENT  ................................ ................................ .....................  363 \nREFERENCES  ................................................................................................................................ 374 \nAPPENDIX  A   GLOSSARY  .............................................................................................................. 394 \nAPPENDIX  B   ACRO", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}960{"doi": "NIST.SP.800-53r5", "chunk-id": "24", "chunk": "NYMS  ............................................................................................................ 424 \nAPPENDIX  C   CONTROL  SUMMARIES  .......................................................................................... 428NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nxiv \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n Executive Summary  \nAs we push computers to \u201cthe edge, \u201d building an increasingly complex world of connected \ninformation systems and devices, security and privacy will continue to dominate the national \ndialogue. In its 2017 report, Task Force on Cyber Deterrence  [DSB 2017 ], the Defense Science \nBoard (DSB) provides a sobering assessment of the current vulnerabilities in the U.S. critical \ninfrastructure and the information systems that support mission -essential operations and assets \nin the public and private sectors.  \n\u201c\u2026The Task Force notes that the cyber threat to U.S. critical infrastructu", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}961{"doi": "NIST.SP.800-53r5", "chunk-id": "25", "chunk": "re is outpacing  \nefforts to reduce pervasive vulnerabilities, so that for the next decade at least the United States  \nmust lean significantly on deterrence to address the cyber threat posed by the most capable \nU.S. adversaries. It is clear that a more proactive and systematic approach to U.S. cyber  \ndeterrence is urgently needed\u2026\u201d \nThere is an urgent need to further strengthen the underlying information systems, component \nproducts, and services that  the Nation  depends on in every sector of the critical infrastructure\u2014\nensuring that those systems, components, and services are sufficiently trustworthy and provide \nthe necessary resilience to support the economic and national security interests of the United \nStates. This update to NIST Special Publication (SP) 800-53 responds to the call by the DSB  by \nembarking on a proactive and systemic approach to develop and make available to a broad base \nof public and private sector organizations a comprehensive set o f safeguarding measures for all \ntypes of computing platforms, including general purpose computing systems, cyber -physical \nsystems, cloud -based systems, mobile devices, Internet of Things ( IoT) devices, weapons \nsystems, space systems, communications systems , environmental control systems , super \ncomputers,  and i", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}962{"doi": "NIST.SP.800-53r5", "chunk-id": "26", "chunk": "ndustrial control systems. Those safeguarding measures include implementing \nsecurity and  privacy controls to protect the critical and essential operations and assets of \norganizations and the privacy of individuals. The objectives are  to make the information systems \nwe depend on more penetration-resistant , limit the damage from attacks when they occur , \nmake the systems cyber -resilient  and survivable , and protect individuals\u2019 privacy.  \nRevision 5 of this foundational NIST publication represents a multi -year effort to develop the \nnext generation of security and privacy controls that will be needed  to accomplish the above \nobjectives. It includes changes to make the controls more usable by diverse consumer groups \n(e.g., enterprises conducting mission and business functions ; engineering organizations \ndeveloping information systems, IoT devices, and sy stems -of-systems; and industry partners \nbuilding system components, products, and services). The most significant changes to this \npublication include:  \n\u2022 Making the controls more outcome -based  by removing the entity responsible for satisfying \nthe control (i.e ., information system, organization) from the control statement;  \n\u2022 Integrating information security and privacy controls into a seamless, consolidated con", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}963{"doi": "NIST.SP.800-53r5", "chunk-id": "27", "chunk": "trol \ncatalog for information systems and organizations;  \n\u2022 Establishing a new supply chain risk management control family;  \n\u2022 Separating control selection processes  from the controls , thereby allowing the controls to be \nused by different communities of interest, including systems engineers, security architects, \nsoftware developers, enterprise architects , systems security and privacy engineers, and \nmission or business owners;NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nxv \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n \u2022 Removing control baselines and tailoring guidance from the publication and transferring the \ncontent to NIST SP  800-53B , Control Baselines for  Information Systems and Organizations ; \n\u2022 Clarifying the relationship between requirements and controls and the relationship between \nsecurity and privacy controls; and  \n\u2022 Incorporating new, state-of -the-practice controls (e.g., controls to support cyber resiliency,", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}964{"doi": "NIST.SP.800-53r5", "chunk-id": "28", "chunk": " \nsupport secure systems design, and s trengthen security and privacy governance and \naccountability)  based on the latest threat intelligence and cyber -attack data.  \nIn separating the process of control selection from the controls and removing the control \nbaselines, a significant amount of guidan ce and other informative material previously contained \nin SP 800-53 was eliminated. That content will be moved to other NIST publications such as SP  \n800-37 (Risk Management Framework) and SP  800-53B during the next update cycle. In the near \nfuture, NIST also plans to offer the content of SP  800-53, SP 800-53A, and SP 800-53B to a web -\nbased portal to provide its customers interactive, online access to all control, control baseline, overlay, an d assessment information.NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nxvi \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n Prologue  \n\u201c\u2026Through the process of risk management, leaders must consi", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}965{"doi": "NIST.SP.800-53r5", "chunk-id": "29", "chunk": "der risk to US interests from \nadversaries using cyberspace to their advantage and from our own efforts to employ the global \nnature of cyberspace to achieve obje ctives in military, intelligence, and business operations\u2026 \u201c  \n  \u201c\u2026For operational plans development, the combination of threats, vulnerabilities, and impacts must be evaluated in order to identify important trends and decide where effort should be applied t o eliminate or reduce threat capabilities; eliminate or reduce vulnerabilities; and assess, \ncoordinate, and deconflict all cyberspace operations\u2026\u201d  \n\u201c\u2026Leaders at all levels are accountable for ensuring readiness and security to the same degree as in any othe r domain\u2026\"  \nTHE NATIONAL STRATEGY FOR CYBERSPACE OPERATIONS  \nOFFICE OF THE CHAIRMAN , JOINT CHIEFS OF STAFF, U.S.  DEPARTMENT OF DEFENSE  \n \n__________  \n \n\u201cNetworking and information technology [ are] transforming life in the 21st century, changing \nthe way people, businesses, and government interact. Vast improvements in computing, storage, \nand communications are creating new opportunities for enhancing our social wellbeing; \nimproving health and health care; eliminating barriers to education and employment; and \nincreasing efficiencies in many sectors such as manufacturing, transportation, and agriculture", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}966{"doi": "NIST.SP.800-53r5", "chunk-id": "30", "chunk": ".  \nThe promise of these new applications often stems from their ability to create, collect, transmit,  \nprocess, and archive information on a massive scale. However, the vast increase in the quantity \nof personal information that is being collected and retained, combined with the increased ability \nto analyze it and combine it with other information, is creat ing valid concerns about privacy and \nabout the ability of entities to manage these unprecedented volumes of data responsibly\u2026.  A key \nchallenge of this era is to assure that growing capabilities to create, capture, store, and process \nvast quantities of info rmation will not damage the core values of the country\u2026.\u201d  \n\u201c\u2026When systems process personal information, whether by collecting, analyzing, generating, \ndisclosing, retaining, or otherwise using the information, they can impact privacy of individuals. \nSystem designers need to account for individuals as stakeholders in the overall development of \nthe solution.\u2026Designing for privacy must connect individuals\u2019 privacy desires with system \nrequirements and controls in a way that effectively bridges the aspirations wi th development\u2026.\u201d  \nTHE NATIONAL PRIVACY RESEARCH STRATEGY  \nNATIONAL SCIENCE AND TECHNOLOGY COUNCIL , NETWORKING AND INFORMA TION TECHNOLOGY RESEARCH AND DEV", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}967{"doi": "NIST.SP.800-53r5", "chunk-id": "31", "chunk": "ELOPMENT PROGRAMNIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nxvii \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n Errata  \nThis table contains changes that have been incorporated i nto SP 800-53, Revision 5 . Errata \nupdates can include corrections, clarifications, or other minor changes in the publication that \nare either editorial or substantive  in nature.  Any potential updates for this document that are \nnot yet published in an errata update or revi sion\u2014 including additional issues and potential \ncorrections \u2014will be posted as they are identified; see the SP 800 -53, Revision 5 publication \ndetails . \nDATE  TYPE  REVISION  PAGE  \n12-10-2020 Editorial  Acknowledgements (ODNI): Add \u201c Matthew A. Kozma , Chief \nInformation Officer\u201d  iii \n12-10-2020 Editorial  Acknowledgements (ODNI): Add \u201c Michael E. Waschull , Deputy Chief \nInformation Officer\u201d  iii \n12-10-2020 Editorial  Acknowledgements (ODNI): Add \u201c Clifford M. Conner , Cybersecur", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}968{"doi": "NIST.SP.800-53r5", "chunk-id": "32", "chunk": "it y \nGroup and IC CISO \u201d iii \n12-10-2020 Editorial  Call Out Box: Change \u201cSpecial Publication 800 -53B contains control \nbaselines\u201d to \u201cSP 800 -53B contains security and privacy control \nbaselines\u201d  x \n12-10-2020  Editorial  Chapter One (Footnote 7): Add \u201c[SP 800 -53A]\u201d  1 \n12-10-2020 Editorial  Section 1.4: Delete \u201c The controls have also been mapped to the \nrequirements for federal information systems included in [OMB A-\n130]. \u201d 5 \n12-10-2020 Editorial  Section 1.4 (Footnote 23): Delete \u201c [OMB A -130] establishes policy \nfor the planning, budgeting, governance, acquisition, and \nmanagement of federal information, personnel, equipment, funds, \nIT resources, and supporting infrastructure and services.\u201d  5 \n12-10-2020 Editorial  Section 2.4 (first paragraph) : Change \u201c personally identifiable \ninformation (PII) \u201d to \u201c PII\u201d 13 \n12-10-2020 Editorial  Control AC -1a.1. : Change \u201c organization -level; mission/business \nprocess -level; system -level \u201d to \u201c Organization- level; Mission/business \nprocess -level; System -level \u201d 18 \n12-10-2020 Editorial  Control AC -1 Discussion : Change \u201c security or privacy incidents \u201d to \n\u201csecurity incidents or breaches \u201d 18 \n12-10-2020 Editorial  Control Enhancement AC -3(2) Discussion : Change \u201c authorization \nduties to other individuals \u201d to \u201c auth", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}969{"doi": "NIST.SP.800-53r5", "chunk-id": "33", "chunk": "orization duties \u201d 23 \n12-10-2020 Editorial  Control Enhancement AC -3(9) Discussion : Change \u201c mitigating \ncontrol \u201d to \u201c mitigation measure \u201d 26 \n12-10-2020  Editorial  Control Enhancement  AC-3(14) Related Controls : Add \u201c, PT -6\u201d 28 \n12-10-2020 Editorial  Control Enhancement  AC-4(17): Change \u201c organization, system, \napplication, service, individual \u201d to \u201c organization; system; \napplication; service; individual \u201d 33 \n12-10-2020 Editorial  Control Enhancement  AC-4(25): Change \u201c Selection (one or more: \u201d to \n\u201cSelection (one or more): \u201d 34 \n12-10-2020  Editorial  Control AC -12: Change \u201c conditions, \u201d to \u201c conditions \u201d 43 \n12-10-2020 Editorial  Control AC-14 Discussion : Change \u201c assignment \u201d to \u201c assignment \noperation \u201d 44 \n12-10-2020 Editorial  Control AC-19 Discussion : Change \u201c the organizational network \u201d to \n\u201cits network \u201d 52NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nxviii \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n DATE  ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}970{"doi": "NIST.SP.800-53r5", "chunk-id": "34", "chunk": "TYPE  REVISION  PAGE  \n12-10-2020 Editorial  Control AC-19 Discussion : Change \u201c Many controls for mobile \ndevices are reflected in other controls allocated to the initial control \nbaselines as starting points for the development of securi ty plans \nand overlays using the tailoring process. There may also be some \noverlap by the security controls within the different families of \ncontrols. \u201d to \u201c Many safeguards  for mobile devices are reflected in \nother controls .\u201d 52 \n12-10-2020 Editorial  Control AC-20 Discussion : Change \u201c organizational systems \u201d to \n\u201corganizational systems, \u201d 53 \n12-10-2020 Editorial  Control Enhancement  AC-20(3)  Discussion : Change \u201c AC-20(6) \u201d to \n\u201cAC-20 b. \u201d 54 \n12-10-2020 Editorial  Control AT -1a.1. : Change \u201c organization -level; mission/business \nprocess -level; system -level \u201d to \u201c Organization- level; Mission/business \nprocess -level; System -level \u201d 59 \n12-10-2020 Editorial  Control AT -1 Discussion : Change \u201c security or privacy incidents \u201d to \n\u201csecurity incidents or breaches \u201d 59 \n12-10-2020 Editorial  Control AT -2d.: Change \u201c security or privacy incidents \u201d to \u201c security \nincidents or breaches \u201d 60 \n12-10-2020 Editorial  Control AT -2 Discussion : Change \u201c security or privacy incidents \u201d to \n\u201csecurity incidents or breaches \u201d 60 \n12-10-2020 ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}971{"doi": "NIST.SP.800-53r5", "chunk-id": "35", "chunk": "Editorial  Control AT -3c.: Change \u201c security or privacy incidents \u201d to \u201c security \nincidents or breaches \u201d 62 \n12-10-2020 Editorial  Control AT -3 Discussion : Change \u201c security or privacy incidents \u201d to \n\u201csecurity incidents or breaches \u201d 63 \n12-10-2020  Editorial  Control AT-3 Related Controls : Change \u201c IR-10\u201d to \u201c IR-4\u201d 63 \n12-10-2020 Editorial  Control AT -6 Discussion : Change \u201c assessment and update \u201d to \n\u201cevaluation and update \u201d 64 \n12-10-2020 Editorial  Control AT -6 Discussion : Change \u201c organization training \u201d to \n\u201corganizational training \u201d 64 \n12-10-2020 Editorial  Control AU -1a.1. : Change \u201c organization -level; mission/business \nprocess -level; system -level \u201d to \u201c Organization- level; Mission/business \nprocess -level; System -level \u201d 65 \n12-10-2020 Editorial  Control AU -1 Discussion : Change \u201c security or privacy incidents \u201d to \n\u201csecurity incidents or breaches \u201d 65 \n12-10-2020 Editorial  Control CA -1a.1. : Change \u201c organization -level; mission/business \nprocess -level; system -level \u201d to \u201c Organization- level; Mission/business \nprocess -level; System -level \u201d 83 \n12-10-2020 Editorial  Control CA -1 Discussion : Change \u201c security or privacy incidents \u201d to \n\u201csecurity incidents or breaches \u201d 83 \n12-10-2020 Editorial  Control CA -1 References : Change \u201c [OMB A -130,", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}972{"doi": "NIST.SP.800-53r5", "chunk-id": "36", "chunk": " Appendix II] \u201d to \n\u201c[OMB A -130] \u201d 84 \n12-10-2020  Editorial  Control CA -1 References : Add \u201c[SP 800 -137A], \u201d 84 \n12-10-2020 Editorial  Control Enhancement  CA-2(2): Change \u201c data loss assessment \u201d to \n\u201cdata loss assessment; \u201d 86 \n12-10-2020 Editorial  Control CA -3 References : Change \u201c [OMB A -130, Appendix II] \u201d to \n\u201c[OMB A -130] \u201d 88 \n12-10-2020  Editorial  Control CA-7 Discussion : Change \u201c SC-18c\u201d to \u201c SC-18b\u201d 91 \n12-10-2020 Editorial  Control CM -1a.1. : Change \u201c organization -level; mission/business \nprocess -level; system -level \u201d to \u201c Organization- level; Mission/business \nprocess -level; System -level \u201d 96 \n12-10-2020 Editorial  Control CM -1 Discussion : Change \u201c security or privacy incidents \u201d to \n\u201csecurity incidents or breaches \u201d 96 \n12-10-2020  Editorial  Control CM-2b.2. : Change \u201c Assignment \u201d to \u201c Assignment: \u201d 97 \n12-10-2020 Editorial  Control Enhancement CM -7(4) Title: Change \u201cUNAUTHORIZED \nSOFTWARE\u201d to \u201cUNAUTHORIZED SOFTWARE \u2013  DENY -BY-\nEXCEPTION\u201d  106NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_____________________________________________________________", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}973{"doi": "NIST.SP.800-53r5", "chunk-id": "37", "chunk": "____________________________________  \nxix \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n DATE  TYPE  REVISION  PAGE  \n12-10-2020 Editorial  Control Enhancement CM -7(5) Title: Change \u201cAUTHORIZED \nSOFTWARE\u201d to \u201cAUTHORIZED SOFTWARE \u2013 ALLOW -BY-EXCEPTION\u201d  106 \n12-10-2020  Editorial  Control CM -8 Related Controls: Add \u201cCP -9,\u201d 108 \n12-10-2020 Editorial  Control CP -1a.1. : Change \u201c organization -level; mission/business \nprocess -level; system -level \u201d to \u201c Organization- level; Mission/business \nprocess -level; System -level \u201d 115 \n12-10-2020 Editorial  Control CP -1 Discussion : Change \u201c security or privacy incid ents \u201d to \n\u201csecurity incidents or breaches \u201d 115 \n12-10-2020 Editorial  Control CP -3 Discussion : Change \u201c security or privacy incidents \u201d to \n\u201csecurity incidents or breaches \u201d 119 \n12-10-2020 Editorial  Control Enhancement CP -9(7) Title: Change \u201cDUAL \nAUTHORIZATION\u201d to \u201cDUAL AUTHORIZATION FOR DELETION OR \nDESTRUCTION\u201d  127 \n12-10-2020 Editorial  Control Enhancement CP -10(3): Change \u201ctailoring procedures\u201d to \n\u201ctailoring\u201d  128 \n12-10-2020 Editorial  Control IA -1a.1. : Change \u201c organization -level; mission/business \nprocess -level; system -level \u201d to \u201c Organization- level; Mission/business \nprocess -level; System -level \u201d", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}974{"doi": "NIST.SP.800-53r5", "chunk-id": "38", "chunk": " 131 \n12-10-2020 Editorial  Control IA -1 Discussion : Change \u201c security or privacy incidents \u201d to \n\u201csecurity incidents or brea ches \u201d 131 \n12-10-2020 Editorial  Control Enhancement IA -2(1) Discussion: Change \u201c Common Access \nCard \u201d to \u201c Common Access Card (CAC) \u201d 132 \n12-10-2020 Editorial  Control Enhancement IA -2(7) Title: Change \u201cACCESS\u201d to \u201cNETWORK \nACCESS\u201d  134 \n12-10-2020 Editorial  Control Enhancement IA -8(5) Discussion: Change \u201c Personal Identity \nVerification (PIV) \u201d to \u201c PIV\u201d 145 \n12-10-2020 Editorial  Control IR -1a.1. : Change \u201c organization -level; mission/business \nprocess -level; system -level \u201d to \u201c Organization- level; Mission/business \nprocess -level; System -level \u201d 149 \n12-10-2020 Editorial  Control IR -1 Discussion : Change \u201c security or privacy incidents \u201d to \n\u201csecurity incidents or breaches \u201d 149 \n12-10-2020 Editorial  Control Enhancement IR -2(1) Discussion : Delete  \u201cIncident response \ntraining includes tabletop exercises that simulate a breach. See IR -\n2(3). \u201d 150 \n12-10-2020  Editorial  Control IR-4 Related Controls : Add \u201cIR -5,\u201d 152 \n12-10-2020  Editorial  Control IR-5 Related Controls : Add \u201cIR -4, IR-6,\u201d 156 \n12-10-2020 Editorial  Control Enhancement IR -5(1) Related Controls : Change \u201cAU -7, IR -4\u201d \nto \u201cNone\u201d  156 \n12-10-2020 Editorial  Control", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}975{"doi": "NIST.SP.800-53r5", "chunk-id": "39", "chunk": " IR -10: Change \u201c Incident Analysis \u201d to \u201cIntegrated \nInformation Security Analysis Team\u201d  161 \n12-10-2020  Editorial  Control IR -10: Change \u201c Incorporated into \u201d to \u201c Moved to \u201d 161 \n12-10-2020 Editorial  Control MA -1a.1. : Change \u201c organization -level; mission/business \nprocess -level; system -level \u201d to \u201c Organization- level; Mission/business \nprocess -level; System -level \u201d 162 \n12-10-2020 Editorial  Control MA -1 Discussion : Change \u201c security or privacy incidents \u201d to \n\u201csecurity incidents or breaches \u201d 162 \n12-10-2020 Editorial  Control Enhancement MA -4(2): Change \u201c MA-1, MA -4\u201d to \u201c MA-1 and \nMA-4\u201d 166 \n12-10-2020 Editorial  Control MP -1a.1. : Change \u201c organization -level; mission/business \nprocess -level; system -level \u201d to \u201c Organization- level; Mission/business \nprocess -level; System -level \u201d 171 \n12-10-2020 Editorial  Control MP -1 Discussion : Change \u201c security or privacy incidents \u201d to \n\u201csecurity incidents or breaches \u201d 171 \n12-10-2020  Editorial  Control MP -3 References : Add \u201c[EO 13556], \u201d 172NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n________________________", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}976{"doi": "NIST.SP.800-53r5", "chunk-id": "40", "chunk": "_________________________________________________________________________  \nxx \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n DATE  TYPE  REVISION  PAGE  \n12-10-2020 Editorial  Control PE -1a.1. : Change \u201c organization -level; mission/business \nprocess -level; system -level \u201d to \u201c Organization- level; Mission/business \nprocess -level; System -level \u201d 179 \n12-10-2020 Editorial  Control PE -1 Discussion : Change \u201c security or privacy incidents \u201d to \n\u201csecurity incidents or breaches \u201d 179 \n12-10-2020  Editorial  Control Enhancement PE -3(8) Discussion : Delete  \u201c, or mantrap, \u201d 183 \n12-10-2020 Editorial  Control Enhancement PE -3(8) Discussion : Change  \u201cMantraps \u201d to \n\u201cVestibules\u201d  183 \n12-10-2020  Editorial  Control Enhancement PE -19(1) Title: Delete \u201dAND TEMPEST\u201d  192 \n12-10-2020 Editorial  Control PL -1a.1. : Change \u201c organization -level; mission/business \nprocess -level; system -level \u201d to \u201c Organization- level; Mission/business \nprocess -level; System -level \u201d 194 \n12-10-2020 Editorial  Control PL -1 Discussion : Change \u201c security or pr ivacy incidents \u201d to \n\u201csecurity incidents or breaches \u201d 194 \n12-10-2020 Editorial  Control PL -2 References : Change \u201c [OMB A -130, Appendix II] \u201d to \n\u201c[OMB A -130] \u201d 196 \n12-10-2020 Editorial  C", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}977{"doi": "NIST.SP.800-53r5", "chunk-id": "41", "chunk": "ontrol PL -7 References : Change \u201c [OMB A -130, Appendix II] \u201d to \n\u201c[OMB A-130] \u201d 198 \n12-10-2020 Editorial  Control PL -11 Discussion : Change  \u201c[FISMA] and [PRIVACT] \u201d to \n\u201c[FISMA], [PRIVACT], and [OMB A -130]\u201d  201 \n12-10-2020 Editorial  Control PM -1 Discussion : Change \u201c security or privacy incidents \u201d to \n\u201csecurity incidents or breaches \u201d 204 \n12-10-2020  Editorial  Control PM -2 References : Add \u201c, [SP 800 -181] \u201d 204 \n12-10-2020  Editorial  Control PM -5 References : Add \u201c[OMB A -130], \u201d 206 \n12-10-2020  Editorial  Control PM -8 References : Add \u201c[EO 13636], \u201d 207 \n12-10-2020  Editorial  Control PM -10 References : Add \u201c, [SP 800 -181] \u201d 208 \n12-10-2020  Editorial  Control PM-11 Related Controls : Add \u201cRA -9,\u201d 209 \n12-10-2020  Editorial  Control PM -12 References : Add \u201c[NITP12], \u201d 210 \n12-10-2020  Editorial  Control PM -17 References : Add \u201c[SP 800-172], \u201d 212 \n12-10-2020  Editorial  Control PM-19 Related Controls : Add \u201c, PM -27\u201d 213 \n12-10-2020  Editorial  Control PM -22 References : Add \u201c[OMB M -19-15],\u201d 216 \n12-10-2020  Editorial  Control PM-24 Related Controls : Add \u201cPT -2,\u201d 216 \n12-10-2020 Editorial  Control PM -24 References : Change \u201c [OMB A -130, Appendix II] \u201d to \n\u201c[OMB A -130] \u201d 217 \n12-10-2020  Editorial  Control PM-25 Related Controls : Add \u201c, SI -12\u201d 217 \n1", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}978{"doi": "NIST.SP.800-53r5", "chunk-id": "42", "chunk": "2-10-2020 Editorial  Control PM -25 References : Change \u201c [OMB A -130, Appendix II] \u201d to \n\u201c[OMB A -130] \u201d 217 \n12-10-2020  Editorial  Control PM -29 References : Add \u201c, [SP 800 -181] \u201d 219 \n12-10-2020  Editorial  Control PM -30 References : Add \u201c[CNSSD 505], \u201d 220 \n12-10-2020  Editorial  Control PM-31 Discussion : Change \u201c SC-18c\u201d to \u201c SC-18b\u201d 220 \n12-10-2020  Editorial  Control PM -31 References : Add \u201c, [SP 800 -137A] \u201d 221 \n12-10-2020 Editorial  Control PM -32 References : Change  \u201c[SP 800 -137] \u201d to \u201c[SP 800 -160-\n1], [SP 800 -160-2]\u201d 221 \n12-10-2020 Editorial  Control PS -1a.1. : Change \u201c organization -level; mission/business \nprocess -level; system -level \u201d to \u201c Organization- level; Mission/business \nprocess -level; System -level \u201d 222 \n12-10-2020 Editorial  Control PS -1 Discussion : Change \u201c security or privacy incidents \u201d to \n\u201csecurity incidents or brea ches \u201d 222 \n12-10-2020  Editorial  Control Enhancement PS -3(3) Title: Change \u201cWITH\u201d to \u201cREQUIRING\u201d  224 \n12-10-2020 Editorial  Control PT -1a.1. : Change \u201c organization -level; mission/business \nprocess -level; system -level \u201d to \u201c Organization- level; Mission/business \nprocess -level; System -level \u201d 229 \n12-10-2020  Editorial  Control PT -1 Discussion : Change \u201c privacy breaches \u201d to \u201c breaches \u201d 229NIST  SP 800- 53, R", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}979{"doi": "NIST.SP.800-53r5", "chunk-id": "43", "chunk": "EV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nxxi \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n DATE  TYPE  REVISION  PAGE  \n12-10-2020 Editorial  Control Enhancement PT -2(1): Change \u201c permissible \u201d to \n\u201cauthorized \u201d 230 \n12-10-2020 Editorial  Control PT -2 References : Change \u201c [OMB A -130, Appendix II] \u201d to \n\u201c[OMB A -130] \u201d 231 \n12-10-2020 Editorial  Control PT -3a.: Change \u201c [Assignment organization -defined \npurpose(s)] \u201d to \u201c [Assignment: organization- defined purpose(s) ]\u201d 231 \n12-10-2020 Editorial  Control PT -3 References : Change \u201c [OMB A -130, Appendix II] \u201d to \n\u201c[OMB A -130] \u201d 232 \n12-10-2020  Editorial  Control PT-5 Related Controls : Add \u201cSC -42,\u201d 234 \n12-10-2020 Editorial  Control Enhancement PT -6(2): Change \u201c [Assignment: organization -\ndefined frequency] \u201d to \u201c [Assignment: organization- defined \nfrequency ]\u201d 235 \n12-10-2020  Editorial  Control PT -7 References : Add \u201c, [NARA CUI] \u201d 236 \n12-10-2020  Editorial  Control PT -8 References :", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}980{"doi": "NIST.SP.800-53r5", "chunk-id": "44", "chunk": " Add \u201c[CMPPA], \u201d 237 \n12-10-2020 Editorial  Control RA -1a.1. : Change \u201c organization -level; mission/business \nprocess -level; system -level \u201d to \u201c Organization- level; Mission/business \nprocess -level; System -level \u201d 238 \n12-10-2020 Editorial  Control RA -1 Discussion : Change \u201c security or privacy incidents \u201d to \n\u201csecurity incidents or breaches \u201d 238 \n12-10-2020  Editorial  Control RA -2 References : Add \u201c, [NARA CUI] \u201d 240 \n12-10-2020  Editorial  Control RA-3 Related Controls : Add \u201cPT -2,\u201d 240 \n12-10-2020 Editorial  Control RA -8 References : Change \u201c [OMB A-130, Appendix II] \u201d to \n\u201c[OMB A -130] \u201d 247 \n12-10-2020  Editorial  Control RA-9 Related Controls : Add \u201cPM -11,\u201d 247 \n12-10-2020 Editorial  Control SA -1a.1. : Change \u201c organization -level; mission/business \nprocess -level; system -level \u201d to \u201c Organization- level; Mission/business \nprocess -level; System -level \u201d 249 \n12-10-2020 Editorial  Control SA -1 Discussion : Change \u201c security or privacy incidents \u201d to \n\u201csecurity incidents or breaches \u201d 249 \n12-10-2020  Editorial  Control SA -2 References : Add \u201c[SP 800 -37], \u201d 250 \n12-10-2020  Editorial  Control SA -4 References : Add \u201c[ISO 29148], \u201d 255 \n12-10-2020 Editorial  Control Enhancement SA -9(5) Discussion : Change \u201c security or \nprivacy incidents \u201d to \u201c security inc", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}981{"doi": "NIST.SP.800-53r5", "chunk-id": "45", "chunk": "idents or breaches \u201d 273 \n12-10-2020 Editorial  Control Enhancement SA -10(2) Title: Change \u201cALTERNATIVE \nCONFIGURATION MANAGEMENT\u201d to \u201cALTERNATIVE \nCONFIGURATION MANAGEMENT PROCESSES\u201d  274 \n12-10-2020  Editorial  Control SA -11a. : Change \u201cassessments \u201d to \u201c control assessments \u201d 276 \n12-10-2020 Editorial  Control Enhancement SA -12(13) : Change \u201c MA-6, RA -9\u201d to \u201c MA-6 \nand RA -9\u201d 280 \n12-10-2020 Editorial  Control Enhancement SA -12(14) : Change \u201c SR-4(1), SR -4(2)\u201d to \u201c SR-\n4(1) and SR -4(2)\u201d 280 \n12-10-2020 Editorial  Control Enhancement  SA-17(4)(b): Change \u201c informal \ndemonstration, \u201d to \u201c informal demonstration; \u201d 286 \n12-10-2020 Editorial  Control SA -23: Change \u201c design modification, augmentation, \nreconfiguration \u201d to \u201c design; modification; augmentation; \nreconfiguration \u201d 291 \n12-10-2020 Editorial  Control SC -1a.1. : Change \u201c organization -level; mission/business \nprocess -level; system -level \u201d to \u201c Organization- level; Mission/business \nprocess -level; System -level \u201d 292 \n12-10-2020 Editorial  Control SC -1 Discussion : Change \u201c security or privacy incidents \u201d to \n\u201csecurity incidents or breaches \u201d 292 \n12-10-2020 Editorial  Control SC -6: Change \u201c Selection (one or more); \u201d to \u201c Selection (one \nor more): \u201d 297NIST  SP 800- 53, REV. 5                              ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}982{"doi": "NIST.SP.800-53r5", "chunk-id": "46", "chunk": "                                                       SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nxxii \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n DATE  TYPE  REVISION  PAGE  \n12-10-2020 Substantive  Control SC -7 Discussion: Add  \u201c[SP 800 -189] provides additional \ninformation on source address validation techniques to prevent \ningress and egress of traffic with spoofed addresses.\u201d  297 \n12-10-2020 Substantive  Control Enhancement  SC-7(4) Discussion: Delete \u201c Unauthorized \ncontrol plane traffic can occur through a technique known as \nspoofing. \u201d 298 \n12-10-2020 Substantive  Control Enhancement  SC-7(4) Discussion: Change  \u201crouting \u201d to \n\u201cBorder Gateway Protocol (BGP) routing \u201c 298 \n12-10-2020 Substantive  Control Enhancement  SC-7(4) Discussion: Change  \u201cmanagement \u201d to \n\u201cmanagement protocols \u201c 298 \n12-10-2020 Substantive  Control Enhancement  SC-7(4) Discussion: Add \u201cSee [SP 800 -189] for \nadditional information on the use of the resource public key \ninfrastructure (RPKI) to protect BGP routes and detect unauthorized \nBGP announcement", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}983{"doi": "NIST.SP.800-53r5", "chunk-id": "47", "chunk": "s. \u201d 298 \n12-10-2020 Editorial  Control Enhancement  SC-7(4) Related Controls : Add \u201c, SC -20, SC -21, \nSC-22\u201d 298 \n12-10-2020 Editorial  Control Enhancement  SC-7(5): Change \u201c Selection (one or more); \u201d to \n\u201cSelection (one or more): \u201d 298 \n12-10-2020  Editorial  Control SC -14: Change \u201c SI-7,\u201d to \u201c SI-7, and \u201d 309 \n12-10-2020 Editorial  Control SC -17 Discussion: Change \u201c Public Key Infrastructure\u201d to \n\u201cPublic Key Infrastructure (PKI)\u201d  311 \n12-10-2020 Editorial  Control SC-19: Change \u201c addressed by other controls for protocols \u201d \nto \u201caddressed as any other technology or protocol \u201d 313 \n12-10-2020 Editorial  Control Enhancement SC -30(4) Related Controls : Change \u201cSC -26\u201d to \n\u201cNone\u201d  319 \n12-10-2020 Editorial  Control Enhancement  SC-31(2): Change \u201c Selection (one or more); \u201d \nto \u201cSelection (one or more): \u201d 320 \n12-10-2020  Editorial  Control SC-42b. : Change \u201c class of users \u201d to \u201c group of users \u201d 326 \n12-10-2020 Editorial  Control SI -1a.1. : Change \u201c organization -level; mission/business \nprocess -level; system -level \u201d to \u201c Organization- level; Mission/business \nprocess -level; System -level \u201d 332 \n12-10-2020 Editorial  Control SI -1 Discussion : Change \u201c security or privacy incidents \u201d to \n\u201csecurity incidents or breaches \u201d 332 \n12-10-2020 Editorial  Control SI -3c.1.: Chan", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}984{"doi": "NIST.SP.800-53r5", "chunk-id": "48", "chunk": "ge \u201c Selection (one or more); \u201d to \u201c Selection \n(one or more): \u201d 334 \n12-10-2020  Editorial  Control SI -9: Change \u201c AC-5,\u201d to \u201c AC-5, and \u201d 349 \n12-10-2020 Editorial  Control SI -10 References : Change \u201c [OMB A -130, Appendix II] \u201d to \n\u201c[OMB A -130] \u201d 351 \n12-10-2020 Editorial  Control Enhancement SI -12(1) : Change \u201cPII\u201d to \u201cpersonally \nidentifiable information\u201d  352 \n12-10-2020 Editorial  Control Enhancement SI -12(1) Related Controls : Delete  \u201cPT-2, PT -3, \nRA-3\u201d 352 \n12-10-2020 Editorial  Control Enhancement SI -12(3) Related Controls : Change \u201cMP -6\u201d to \n\u201cNone\u201d  353 \n12-10-2020 Editorial  Control SI -12 References : Change \u201c [OMB A -130, Appendix II] \u201d to \n\u201c[OMB A -130] \u201d 353 \n12-10-2020  Editorial  Control SI-18 Related Controls : Add \u201cPT -2,\u201d 356 \n12-10-2020  Editorial  Control Enhancement SI -18(1) Related Controls : Delete \u201cPM -22,\u201d 357 \n12-10-2020 Editorial  Control Enhancement SI -18(4) Related Controls : Change \u201cPM -22\u201d to \n\u201cNone\u201d  358 \n12-10-2020  Editorial  Control SI -18 References : Add \u201c[OMB M -19-15],\u201d 358 \n12-10-2020 Editorial  Control SI -19 References : Change \u201c [OMB A -130, Appendix II] \u201d to \n\u201c[OMB A -130] \u201d 360 \n12-10-2020 Editorial  Control SI -20 References : Change \u201c [OMB A -130, Appendix II] \u201d to \n\u201c[OMB A -130] \u201d 361NIST  SP 800- 53, REV. 5           ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}985{"doi": "NIST.SP.800-53r5", "chunk-id": "49", "chunk": "                                                                          SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nxxiii \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n DATE  TYPE  REVISION  PAGE  \n12-10-2020 Editorial  Control SR -1a.1. : Change \u201c organization -level; mission/business \nprocess -level; system -level \u201d to \u201c Organization- level; Mission/business \nprocess -level; System -level \u201d 363 \n12-10-2020 Editorial  Control SR -1 Discussion : Change \u201c security or privacy incidents \u201d to \n\u201csecurity incidents or breaches \u201d 363 \n12-10-2020  Editorial  Control SR -1 References : Add \u201c[CNSSD 505], \u201d 364 \n12-10-2020  Editorial  Control SR -2 References : Add \u201c[SP 800 -181],\u201d  365 \n12-10-2020  Editorial  Control SR -2 References : Add \u201c[CNSSD 505],\u201d  365 \n12-10-2020  Editorial  Control Enhancement SR -5(2) Related Controls : Delete \u201cSR -9\u201d 369 \n12-10-2020 Editorial  Control Enhancement  SR-6(1): Change \u201c organizational analysis, \nindependent third- party analysis, organizational testing, \nindependent third- party testing\u201d to \u201c organizational an", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}986{"doi": "NIST.SP.800-53r5", "chunk-id": "50", "chunk": "alysis; \nindependent third- party analysis; organizational testing; \nindependent third- party testing \u201d 370 \n12-10-2020 Editorial  References  [ATOM54] : Change \u201cAtomic Energy Act (P.L. 107)\u201d to \n\u201cAtomic Energy Act (P.L. 83 -703)\u201d  374 \n12-10-2020 Editorial  References  [ISO 15026 -1]: Change \u201c International Organization for \nStandardization/International Electrotechnical Commission \n(ISO/IEC) 15026- 1:2013, Systems and software engineering \u2014  \nSystems and software assurance \u2014  Part 1: Concepts and \nvocabulary, November 2013.  \nhttps://www.iso.org/standard/62526.html \u201d to \u201c International \nOrganization for Standardization/International Electrotec hnical \nCommission/Institute of Electrical and Electronics Engineers \n(ISO/IEC/IEEE) 15026- 1:2019, Systems and software engineering \u2014 \nSystems and software assurance \u2014  Part 1: Concepts and \nvocabulary, March 2019. \nhttps://www.iso.org/standard/73567.html \u201d 377 \n12-10-2020  Editorial  References: Delete \u201c[ISO 28001]\u201d  378 \n12-10-2020 Editorial  References  [ISO 29148] : Change \u201c International Organization for \nStandardization/International Electrotechnical \nCommission/Institute of Electrical and Electronics Engineers \n(ISO/IEC/IEEE) 29148:2011, Systems and software engineering \u2014Life \ncycle processes\u2014 Requirements engineering, December 20", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}987{"doi": "NIST.SP.800-53r5", "chunk-id": "51", "chunk": "11.  \nhttps://www.iso.org/standard/45171.html \u201d to \u201c International \nOrganization for Standardization/International Electrotechnical \nCommission/Institute of Electrical and Electronics Engineers \n(ISO/IEC/IEEE) 29148:2018, Systems and software engineering \u2014Life \ncycle processes\u2014 Requirements engineering, November 2018.  \nhttps://www.iso.org/standard/72089.html \u201d 379 \n12-10-2020  Editorial  Referen ces [SP 800 -53B] : Change \u201c Draft NIST \u201d to \u201c NIST \u201d 381 \n12-10-2020 Editorial  References  [SP 800 -53B] : Change \n\u201chttps://doi.org/10.6028/NIST.SP.800- 53B-draft \u201d to \n\u201chttps://doi.org/10.6028/NIST.SP.800 -53B\u201d 381 \n12-10-2020  Editorial  References: Delete \u201c[SP 800-58]\u201d  382 \n12-10-2020 Editorial  References: Add \u201c[SP 800 -137A] Dempsey KL,  Pillitteri VY, Baer C, \nNiemeyer R,  Rudman R, Urban S (2020) Assessing Information \nSecurity Continuous Monitoring (ISCM) Programs: Developing an \nISCM Program Assessment. (National Institute of Standards and \nTechnology, Gaithersburg, MD), NIST Special Publication (SP) 800 -\n137A.  https://doi.org/10.6028/NIST.SP.800 -137A \u201d 387 \n12-10-2020  Editorial  References: Delete \u201c[SP 800 -161-1]\u201d 387NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}988{"doi": "NIST.SP.800-53r5", "chunk-id": "52", "chunk": "SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nxxiv \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n DATE  TYPE  REVISION  PAGE  \n12-10-2020 Editorial  References  [SP 800 -181] : Change \u201c Newhouse WD, Witte GA, \nScribner B, Keith S (2017) National Initiative for Cybersecurity \nEducation (NICE) Cybersecurity Workforce Framework. (National \nInstitute of Standards and Technology, Gaithersburg, MD), NIST \nSpecial Pu blication (SP) 800 -181.  \nhttps://doi.org/10.6028/NIST.SP.800- 181\u201d to \u201c Petersen R, Santos D, \nSmith MC, Wetzel KA, Witte G (2020) Workforce Framework for \nCybersecurity (NICE Framework). (National Institute of Standards \nand Technology, Gaithersburg, MD), NIST Special Publication (SP) \n800- 181, Rev. 1.  \nhttps://doi.org/10.6028/NIST.SP.800 -181r1 \u201d 388 \n12-10-2020 Editorial  References  [DODTERMS] : Change \n\u201chttp://www.dtic.mil/dtic/tr/fulltext/u2/a485800.pdf \u201d to \n\u201chttps://www.jcs.mil/Portals/36/Documents/Doctrine/pubs/diction\nary.pdf \u201d 391 \n12-10-2020 Editorial  Appendix A Glossary (counterfeit) : Change \u201c[SP 800 -161-1]\u201d to [SP \n800-161]\u201d  400 \n12-10-2020  Editorial  Appendix", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}989{"doi": "NIST.SP.800-53r5", "chunk-id": "53", "chunk": " A Glossary (supplier) : Delete \u201c[SP 800-161-1]\u201d 419 \n12-10-2020  Editorial  Appendix A Glossary (supply chain) : Delete \u201c[SP 800 -161-1]\u201d 419 \n12-10-2020  Editorial  Appendix A Glossary (supply chain risk) : Delete \u201c[SP 800 -161-1]\u201d 420 \n12-10-2020 Editorial  Appendix A Glossary (supply chain risk assessment) : Delete \u201c[SP \n800-161-1]\u201d 420 \n12-10-2020 Editorial  Appendix A Glossary (supply chain risk management) : Delete \u201c[SP \n800-161-1]\u201d 420 \n12-10-2020  Editorial  Appendix B Acronyms : Add \u201cBGP Border Gateway Protocol\u201d  424 \n12-10-2020  Editorial  Appendix B Acronyms : Add \u201cCAC Common Access Card\u201d  424 \n12-10-2020  Editorial  Appendix B Acronyms : Add \u201cCONOPS Concept of Operations\u201d  424 \n12-10-2020  Editorial  Appendix B Acronyms : Add \u201cDSB Defense Science Board\u201d  424 \n12-10-2020 Editorial  Appendix B Acronyms : Add \u201cFICAM Federal Identity, Credential, and \nAccess Management \u201d 425 \n12-10-2020 Editorial  Appendix B Acronyms : Add \u201cIEEE Institute of Electrical and \nElectronics Engineers \u201d 425 \n12-10-2020 Editorial  Appendix B Acronyms : Add \u201cISAC Information Sharing and Analysis \nCenters\u201d  425 \n12-10-2020 Editorial  Appendix B Acronyms : Add \u201cISAO Information Sharing and Analysis \nOrganizations \u201d 425 \n12-10-2020 Editorial  Appendix B Acronyms : Add \u201cITL Information Technology \nL", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}990{"doi": "NIST.SP.800-53r5", "chunk-id": "54", "chunk": "aboratory \u201d 425 \n12-10-2020  Editorial  Appendix B Acronyms : Add \u201cMLS Multilevel Secure \u201d 425 \n12-10-2020  Editorial  Appendix B Acronyms : Add \u201cNDA Non -Disclosure Agreement \u201d 426 \n12-10-2020 Editorial  Appendix B Acronyms : Add \u201cODNI Office of the Director of National \nIntelligence \u201d 426 \n12-10-2020  Editorial  Appendix B Acronyms : Add \u201cOPM Office of Personnel Management \u201d 426 \n12-10-2020  Editorial  Appendix B Acronyms : Add \u201cPDS Position Designation System \u201d 426 \n12-10-2020 Editorial  Appendix B Acronyms : Add \u201cRPKI Resource Public Key \nInfrastructure \u201d 426 \n12-10-2020  Editorial  Appendix B Acronyms : Add \u201cSCRM Supply Chain Risk Management \u201d 426 \n12-10-2020  Editorial  Appendix B Acronyms : Add \u201cSDLC System Development Life Cycle \u201d 426 \n12-10-2020 Editorial  Appendix B Acronyms : Add \u201cSIEM Security Information and Event \nManagement \u201d 426 \n12-10-2020  Editorial  Appendix B Acronyms : Add \u201cSWID Software Identification \u201d 427 \n12-10-2020  Editorial  Appendix B Acronyms : Add \u201cTIC Trusted Internet Connections \u201d 427 \n12-10-2020 Editorial  Appendix B Acronyms : Add \u201cUEFI Unified Extensible Firmware \nInterface \u201d 427NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND O", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}991{"doi": "NIST.SP.800-53r5", "chunk-id": "55", "chunk": "RGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nxxv \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n DATE  TYPE  REVISION  PAGE  \n12-10-2020  Editorial  Appendix B Acronyms : Add \u201cUPS Uninterruptible Power Supply \u201d 427 \n12-10-2020  Editorial  Appendix C Control Summaries : Change \u201cw\u201d to \u201cW\u201d  428 \n12-10-2020  Editorial  Table C -1 (AC -3(1)) Title: Change \u201cFUNCTION\u201d to \u201cFUNCTIONS\u201d  429 \n12-10-2020  Editorial  Table C -1 (AC -3(6)) : Change \u201c MP-4, SC -28\u201d to \u201c MP-4 and SC -28\u201d 429 \n12-10-2020  Editorial  Table C -1 (AC -13): Change \u201c AC-2, AU -6\u201d to \u201c AC-2 and AU -6\u201d 431 \n12-10-2020 Editorial  Table C -3 (AU -7(2)) Title: Change \u201cSEARCH AND SORT\u201d to \u201cSORT \nAND SEARCH\u201d  434 \n12-10-2020  Editorial  Table C -3 AU -15: Change \u201cIncorporated into\u201d to \u201cMoved to\u201d  435 \n12-10-2020 Editorial  Table C -4 (CA -3(1)) Title: Change \u201cCONNECTIONS\u201d to \u201cSYSTEM \nCONNECTIONS\u201d  436 \n12-10-2020 Editorial  Table C -5 (CM -7(4)) Title: Change \u201cUNAUTHORIZED SOFTWARE\u201d to \n\u201cUNAUTHORIZED SOFTWARE \u2013 DENY -BY-EXCEPTION\u201d  437 \n12-10-2020 Editorial  Table C -5 (CM -7(5)) Title: Change \u201cAUTHORIZED SOFTWARE\u201d to \n\u201cAUTHORIZED SOFTWARE \u2013 ALLO", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}992{"doi": "NIST.SP.800-53r5", "chunk-id": "56", "chunk": "W -BY-EXCEPTION\u201d  437 \n12-10-2020  Editorial  Table C -5: Delete  duplicate row CM -8(5).  438 \n12-10-2020 Editorial  Table C -6 (CP -9(7)) Title: Change \u201cDUAL AUTHORIZATION\u201d to \u201cDUAL \nAUTHORIZATION FOR DELETION OR DESTRUCTION\u201d  440 \n12-10-2020  Editorial  Table C -7 (IA -5(11)): Change \u201cIA -2(1)(2)\u201d to \u201cIA -2(1) and IA -2(2)\u201d  441 \n12-10-2020 Editorial  Table C -8 (IR -10) Title : Change \u201cIntegrated Information Security \nAnalysis\u201d to \u201cIntegrated Information Security Analysis Team\u201d  444 \n12-10-2020  Editorial  Table C -9 (MA -4(2)) : Change \u201c MA-1, MA -4\u201d to \u201c MA-1 and MA -4\u201d 445 \n12-10-2020  Editorial  Table C -11 (PE -7): Change \u201c PE-2, PE -3\u201d to \u201c PE-2 and PE -3\u201d 447 \n12-10-2020  Editorial  Table C -11 (PE -19(1)) Title: Delete \u201dAND TEMPEST\u201d  448 \n12-10-2020  Editorial  Table C -14 (PS -3(1)) Title: Change \u201cI NFORMATION \u201d to \u201c INFORMATION \u201d 451 \n12-10-2020  Editorial  Table C -14 (PS -3(3)) Title : Change \u201cWITH\u201d to \u201cREQUIRING\u201d  451 \n12-10-2020  Editorial  Table C -17 (SA -6): Change \u201c CM-10, SI -7\u201d to \u201c CM-10 and SI -7\u201d 454 \n12-10-2020  Editorial  Table C -17 (SA -7): Change \u201c CM-11, SI -7\u201d to \u201c CM-11 and SI -7\u201d 454 \n12-10-2020  Editorial  Table C -17 (SA -12(13)) : Change \u201c MA-6, RA -9\u201d to \u201c MA-6 and RA -9\u201d 456 \n12-10-2020  Editorial  Table C -17 (SA -12(14)) : Change \u201c SR-4(", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}993{"doi": "NIST.SP.800-53r5", "chunk-id": "57", "chunk": "1)(2) \u201d to \u201c SR-4(1) and SR -4(2)\u201d 456 \n12-10-2020  Editorial  Table C -17 (SA -12(15)) Title : Change \u201cPROCESS\u201d to \u201cPROCESSES\u201d  456 \n12-10-2020 Editorial  Table C -18 (SC -7(25)) Title : Change \u201cCONNECTIONS\u201d to \u201cSYSTEM \nCONNECTIONS\u201d  459 \n12-10-2020  Editorial  Table C -18 (SC -12(4)) : Change \u201c SC-12\u201d to \u201c SC-12(3) \u201d 459 \n12-10-2020  Editorial  Table C -18 (SC -12(5)) : Change \u201c SC-12\u201d to \u201c SC-12(3) \u201d 459 \n12-10-2020  Editorial  Table C -18 (SC -14): Change \u201c SI-7,\u201d to \u201c SI-7, and \u201d 459 \n12-10-2020 Editorial  Table C -18 (SC-19): Change \u201caddressed by other controls for \nprotocols\u201d to \u201caddressed as any other technology or protocol.\u201d  460 \n12-10-2020  Editorial  Table C -19 (SI -9): Change \u201c AC-5,\u201d to \u201c AC-5, and \u201d 463 \n12-10-2020 Editorial  Table C -19 (SI -19(7)) Title : Change \u201c SOFTWARE \u201d to \u201c AND \nSOFTWARE \u201d 464NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER ONE   PAGE  1 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n CHAPTER", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}994{"doi": "NIST.SP.800-53r5", "chunk-id": "58", "chunk": " ONE  \nINTRODUCTION  \nTHE NEED TO PROTECT INFORMATION, SYSTEMS , ORGANIZATIONS, AND INDIVIDUALS  \nModer n information systems1 can include a variety of computing platforms  (e.g.,  industrial  \ncontrol systems , general purpose computing systems , cyber -physical systems,  super computers , \nweapons systems,  communications systems , environmental control systems , medical devices , \nembedded devices , sensors,  and mobile devices such as smart phones and tablets) . These \nplatforms  all share a common foundation \u2014computers with complex hardware, software and \nfirmware providing a capability that supports the essential mission and business functions of \norganizations.2  \nSecurity controls  are the safeguards o r countermeasu res employed within a system or an \norganization to protect the confidentiality, integrity, and availability of the system and its \ninformation  and to manage information security3 risk. Privacy controls are the administrative, \ntechnical, and physical safe guards employed within a system or an organization  to manage \nprivacy risks and to ensure compliance with applicable privacy requirements .4 Security and \nprivacy controls are selected and implemented to satisfy security and privacy requirements  \nlevied on a  system or organization . Security and privacy", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}995{"doi": "NIST.SP.800-53r5", "chunk-id": "59", "chunk": "  requirements are derived from \napplicable laws, executive orders, directives, regulations, policies, standards, and mission needs \nto ensure the confidentiality, integrity, and availability of informa tion processed, stored, or \ntransmitted  and to manage risks to individual privacy. \nThe selection , design,  and implementation of security and privacy controls5 are important tasks \nthat have significant implications for the operations6 and assets of organizations as well as the \nwelfare of individuals and the Nation.  Organizations should answer  several key questions  when \naddressing information security  and privac y controls : \n\u2022 What security and privacy controls are needed to satisfy security and privacy requirements  \nand to adequately manage mission/business risks or risks to indiv iduals ? \n\u2022 Have the selected controls been implemented or is there a plan in place  to do so?  \n\u2022 What is the required level of assurance (i.e., grounds for confidence) that the selected \ncontrols, as designed and  implemented, are effective?7 \n \n1 An information system  is a discrete set of information resources organized for the collection, processing, \nmaintenance, use, sharing, dissemination, or disposition of information  [OMB A -130]. \n2 The term organization describes an entity of any", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}996{"doi": "NIST.SP.800-53r5", "chunk-id": "60", "chunk": " s ize, complexity, or positioning within an organizational structure \n(e.g., a federal agency or, as appropriate, any of its operational elements) . \n3 The two terms information security  and security  are used synonymously  in this publication.  \n4 [OMB A -130] defines security and privacy controls .  \n5 Controls provide safeguards and countermeasures in system s security and privacy engineering processes to reduce \nrisk during the system development life cycle.  \n6 Organizational operations include mission, functions, image, and re putation. \n7 Security and privacy control effectiveness addresses the extent to which the controls are implemented correctly, \noperating as intended, and producing t he desired outcome with respect to meeting the designated security and \nprivacy requirements  [SP 800- 53A].NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER ONE   PAGE  2 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n The answers to these", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}997{"doi": "NIST.SP.800-53r5", "chunk-id": "61", "chunk": " questions are not given in isolation but rather in the context of a  risk \nmanagement process  for the  organization  that identifies, assesses, responds to , and monitors \nsecurity and privacy risks  arising from  its information and systems on an ongoing basis .8 The \nsecurity and privacy controls in this publication are recommended for use by organizations to \nsatisfy  their information security and privacy requirements . The control  catalog can be viewed \nas a tool box containing a collection of safeguards, countermeasures, techniques, and processes  \nto respond to  security and privacy  risks. The controls are  employed as part of a well -defined risk \nmanagement proc ess that supports organizational  information security and privacy programs . In \nturn, those information security and privacy programs  lay the  foundation for the success of the \nmission and business functions of the organization.  \nIt is important  that responsible officials understand the security and privacy risks that could \nadversely affect organizational operations  and assets , individuals , other  organizations, and the \nNation .9 These officials must also unders tand the current status of their security and privacy \nprograms and the controls plann ed or in place to protect information , information", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}998{"doi": "NIST.SP.800-53r5", "chunk-id": "62", "chunk": " systems, and \norganization s in order to make informed judgments and investments that  respond to  identified \nrisks in an accepta ble manner . The objective is to manage these risks through the selection and \nimplementation of  security and privacy controls . \n1.1   PURPOSE  AND  APPLICABILITY  \nThis publication establishes  controls for systems and organizations . The controls can be \nimplemented within any organization or system that processes, stores, or transmits information. \nThe use of these controls is mandatory  for federal information systems10 in accordance with \nOffice of Management and Budget ( OMB ) Circular A- 130 [ OMB A -130] and  the provisions of the \nFederal Information Security Modernization Act11 [FISMA ], which requires the implementation  \nof minimum controls to protect federal information and information systems .12 This publication , \nalong with other supporting NIST publications,  is designed  to help organizations identify the \nsecurity and privacy controls needed to manage risk and to satisf y the security and p rivacy \nrequirements in FISMA, the Privacy Act of 1974 [PRIVACT], OMB policies (e.g., [ OMB A -130 ]), \nand designated Federal Information Processing Standards  (FIPS) , among others . It accomplishes \nthis objective by p roviding a comprehen", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}999{"doi": "NIST.SP.800-53r5", "chunk-id": "63", "chunk": "sive and  flexible catalog of security and privacy controls  \nto meet current and future protection needs based on changing threats, vulnerabilities, \nrequirements, and technologies . The publication also improve s communication among \norganizations by providing a common lexicon that supports  the discussion of security, privacy, \nand risk management concepts.  \n \n8 The Risk Management Framework  in [SP 800- 37] is an example of a comprehensive  risk management process.  \n9 This includes risk to critical infrastructure and key resources described in [ HSPD -7]. \n10 A federal information system  is an information system used or operated by an agency, a contractor of an agency, or \nanother organization on behalf of an agency. \n11 Information systems that have been designated as national security systems, as defined in 44 U.S.C., Section 3542, \nare not  subject to the requirements in  [FISMA ]. However, the controls established in this publication may be selected \nfor national security systems as otherwise required (e.g., the Privacy Act of 1974) or with the approval of federal \nofficials exercising policy authority over such systems. [ CNSSP 22] and [ CNSSI 1253 ] provide gu idance for national \nsecurity systems . [DODI 8510.01 ] provides guidance for the Department of Defense.  \n1", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1000{"doi": "NIST.SP.800-53r5", "chunk-id": "64", "chunk": "2 While the controls established in this publication are mandatory for federal information systems and organizations, \nother organizations such as state, local, and tribal governments as well as private secto r organizations are encouraged \nto consider using these guidelines, as appropriate. See [SP 800- 53B] for federal control baselines.NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER ONE   PAGE  3 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n Finally, the controls are independent of the process employed to se lect those controls. The  \ncontrol selection process can be part of an organization -wide risk management process , a \nsystems engineering process  [SP 800-160 -1],13 the R isk Management Framework [SP 800-37 ], \nthe C ybersecurity Framework  [NIST CSF], or the Privacy Framework [ NIST PF].14 The control \nselection criteria can be guided and informed by  many factors , including mission and business \nneeds , stakeholder pr", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1001{"doi": "NIST.SP.800-53r5", "chunk-id": "65", "chunk": "otecti on needs , threats, vulnerabilities , and requirements to comply with \nfederal laws, executive orders, directives, regulations, policies,  standards , and guidelines . The \ncombination of a catalog of security and privacy controls and a risk -based contro l selection \nprocess can help organizations comply with stated security and privacy requirements , obtain \nadequate security for their information systems, and protect the privacy  of individuals . \n1.2   TARGET  AUDIENCE  \nThis publication is intended to serve a diverse audience , including : \n\u2022 Individuals with system , information security , privacy, or risk  management and oversight \nresponsibilit ies, including authorizing officials, c hief information officers, senior agency \ninformation securit y officers, and senior agency  officials for privacy ; \n\u2022 Individuals with system development responsibilities , including mission owners, program \nmanagers , system  engineers, system security engineers, privacy engineers, hardware  and \nsoftware developers, system integrators , and acquisition or procurement officials ; \n\u2022 Individuals with logistical or disposition- related responsibilities, including  program \nmanagers, procurement officials, system integrators, and property managers;  \n\u2022 Individuals with security and pri", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1002{"doi": "NIST.SP.800-53r5", "chunk-id": "66", "chunk": "vacy implementation and operations  responsibilities , \nincluding  mission or bus iness owners, system owners, information owners  or stewards , \nsystem administrators, continuity planners, and system security  or privacy  officers ; \n\u2022 Individuals with security and privacy assessment and monitoring responsibilities , including  \nauditors, Inspectors G eneral, system evaluators, control assessors, independent verifi ers \nand validat ors, and analysts; and  \n\u2022 Commercial entities , including industry partners, producing component products and \nsystems, creating security and privacy technologies, or providin g services  or capabilities that \nsupport  information security or privacy . \n1.3   ORGANIZATIONAL  RESPONSIBILITIES  \nManaging security and privacy risks  is a complex, multifaceted undertaking that requires:  \n\u2022 Well-defined security and privacy requirements for systems and organizations;  \n\u2022 The use of trustworthy information system components based on state-of -the-practice \nhardware, firmware, and software development and acquisition processes;  \n \n13 Risk management is an integral part of systems engineering, systems security engineerin g, and privacy engineering.  \n14 [OMB A -130] requires federal agencies to implement the NIST Risk Management Framework for the selection", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1003{"doi": "NIST.SP.800-53r5", "chunk-id": "67", "chunk": " of \ncontrols for federal information systems. [ EO 13800 ] requires federal agencies to implement the NIST Framework for \nImproving Critical Infrastructure Cybersecurity  to manage cybersecurity risk. The NIST frameworks are also available \nto nonfederal organizations as optional resources.NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER ONE   PAGE  4 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n \u2022 Rigorous security and privacy planning and system development life cycle management;  \n\u2022 The application of system security and privacy engineering principles and practices to \nsecurely develop and  integrate system components into information systems;  \n\u2022 The employment of security and privacy practices that are properly documented and \nintegrated into and supportive of the institutional and operat ional processes of \norganizations; and  \n\u2022 Continuous monitoring of information systems and organizations to determine the ongoing \neffect", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1004{"doi": "NIST.SP.800-53r5", "chunk-id": "68", "chunk": "iveness of controls, changes in information systems and environments of operation, \nand th e state of security and privacy organization -wide.  \nOrganizations continuously assess the security and privacy risks to organizational operations and \nassets, individuals, other organizations, and the Nation . Security and privacy  risks arise from the \nplanning and execution of organ izational  mission and business functions , placing information \nsystems into operation,  or continuing system operations. Realistic assessments of risk require a \nthorough understanding of the susceptibility to threats based on the specific vulnerabilities in \ninformation systems and organizations and the likelihood and potential adverse impacts of \nsuccessful exploitations of such vulnerabilities by those threats.15 Risk assessments also require \nan understanding of privacy risks.16 \nTo address the organization\u2019s concerns  about assessment and determination of risk , security \nand privacy requirements are satisfied with the knowledge and understanding  of the \norganizational risk management strategy .17 The risk management strategy consider s the cost, \nschedule, performance, and supply chain  issues associated with the design, development, \nacquisition, deployment, operation, sustainment , and disposal  o", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1005{"doi": "NIST.SP.800-53r5", "chunk-id": "69", "chunk": "f organizational systems . A risk \nmanagement process is then applied to manage risk on an ongoing basis .18 \nThe catalog of security and privacy controls can be effectively used to protect organizations, individuals, and information systems from traditional and advanced persistent threats and \nprivacy risks arising from the processing of personally identifiable information (PII) in varied \noperational, environmental, and technical scenarios. The controls can be used to demonstrate \ncompliance with a variety of governmental, organizational, or institutional security and privacy \nrequirements. Organizations have the responsibility to select the appropriate security and \nprivacy controls, to implement the controls correctly, and to demonstrate the eff ectiveness of \nthe controls in satisfying security and privacy requirements.\n19 Security and privacy controls can \nalso be used in developing specialized baselines  or overlays  for unique or specialized missions or \nbusiness applications, information systems, t hreat concerns, operational environments, \ntechnologies, or communities of interest.20 \n \n15 [SP 800- 30] provides guidance on the risk assessment process.  \n16 [IR 8062 ] introduces privacy risk concepts.  \n17 [SP 800- 39] provides guidance on risk management processes and st", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1006{"doi": "NIST.SP.800-53r5", "chunk-id": "70", "chunk": "rateg ies.   \n18 [SP 800- 37] provides  a comprehensive risk management process.   \n19 [SP 800- 53A] provides guidance on assessing the effectiveness of controls.  \n20 [SP 800- 53B] provides guidance for tailoring security and privacy control baselines and for developing overlays to \nsupport the specific protection needs and requirements of stak eholders and their organizations.NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER ONE   PAGE  5 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n Organizational risk assessments  are used, in part, to  inform the security and privacy control \nselection  process.  The selection process results in an agreed-upon set of security and privacy \ncontrols addressing specifi c mission or business needs consistent with organizational risk \ntolerance.21 The process preserves, to the greatest extent possible, the agility and flexibility that \norganizations need to a ddress an increasingly sophisticated an", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1007{"doi": "NIST.SP.800-53r5", "chunk-id": "71", "chunk": "d hostile threat space, mission \nand business requirements , rapidly changing technologies, complex supply chains, and many  \ntypes of operational environments.  \n1.4   RELATIONSHIP  TO OTHER  PUBLICATIONS  \nThis publication defines controls to satisfy a diverse set of security and privacy requirements \nthat have been levied on  information systems and  organizati ons and that are  consistent with \nand complementary to other recognized  national and international inf ormation security and \nprivacy standards.  To develop a broadly applicable and technically sound set of controls for \ninformation systems  and organizations , many sources were considered during the development \nof th is publication . These  sources included requirements and controls from the manufacturing, \ndefense, financial, healthcare, transportation , energy, intelligence, industrial control, and audit \ncommunities as  well as national and international standards organizations.  In addition, the \ncontrols in this publication are used by the national security community in publications such as \nCommittee on National Security Systems ( CNSS ) Instruction No. 1253 [CNSSI 1253 ] to provide \nguidance specific t o systems designated as national security systems. Whenever possible, the \ncontrols have been mapped to inte", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1008{"doi": "NIST.SP.800-53r5", "chunk-id": "72", "chunk": "rnational standards to help ensure maximum usability and \napplicability.22 The relationship of this publication to other risk management, security, pr ivacy, \nand publications can be found at [ FISMA IMP ]. \n1.5   REVISIONS  AND  EXTENSIONS  \nThe security and privacy controls described in this publication represent the state-of -the-\npractice protection measures for individuals, information systems , and organizations. The \ncontrols are  reviewed and revised periodically to reflect the e xperience gained from using the \ncontrols;  new or revised laws,  executive orders, directives, regulations, policies, and standards; \nchanging security and privacy requirement s; emergin g threats, vulnerabilities, attack and \ninformation processing methods ; and  the a vailability of new technologies.  \nThe security and privacy controls in the control catalog are also expected to change over t ime as \ncontrols are withdrawn, revised, and added. In addition to the need for change, the need for \nstability is addressed by requiring that proposed modifications to security and privacy controls \ngo through a rigorous and transparent public review process to  obtai n public and private sector \nfeedback and to build a consensus for such change. The review process  provides a technically \nsound, flexibl", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1009{"doi": "NIST.SP.800-53r5", "chunk-id": "73", "chunk": "e, and stable  set of security and privacy controls for the organizations that use the \ncontrol catalog.  \n1.6   PUBLICATION  ORGANIZATION \nThe remainder of this special publication is organized as follows:  \n \n21 Authorizing officials or their designated representatives, by accepting the security and privacy plans, agree to the \nsecurity and privacy controls proposed to meet the security and privacy requirements for organizations and systems.  \n22 Mapping tables are available at  [SP 800- 53 RES ].NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER ONE   PAGE  6 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n \u2022 Chapter Two  describes the fundamental  concepts associated with security and privacy \ncontrols , including the structure of the controls , how the controls are organized in the \nconsolidated catalog , control  implementation approaches , the relationship between security \nand privacy controls , and trustworthiness and assuranc", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1010{"doi": "NIST.SP.800-53r5", "chunk-id": "74", "chunk": "e.  \n\u2022 Chapter Three  provides a  consolidated catalog of security and privacy controls including a \ndiscussion section  to explain the purpose of each control and to provide useful information \nregarding control i mplementation and assessment , a list of related controls  to show the \nrelationships and dependencies among controls , and a list of references to supporting \npublications that may be hel pful to organizations .  \n\u2022 References , Glossary , Acronyms , and Control Summar ies provide additional information on \nthe use of security and privacy controls .23\n \n23 Unless otherwise stated, all references to NIST publications refer to the most recent version of those publications.NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER TWO   PAGE 7 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n CHAPTER TWO  \nTHE  FUNDAMENTALS  \nSTRUCTURE, TYPE, AND ORGANIZATION OF SECURITY AND PRIVACY CONTROLS  \nThis chapter presents the fundamental conc", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1011{"doi": "NIST.SP.800-53r5", "chunk-id": "75", "chunk": "epts associated with security and privacy controls , \nincluding  the relationship between requirements and controls , the structure of controls , how \ncontrols are organized in the consolidated control catalog , the different control implementation \napproaches  for information systems and organizations , the relationship between security and \nprivacy controls , the impo rtance of the concepts of trustworthiness and assurance for  security \nand privacy controls , and the effect s of the controls on achieving trustworthy, secure,  and \nresilient systems .  \n2.1   REQUIREMENTS  AND  CONTROLS  \nIt is important to understand the relationship between requirements and controls. For  federal \ninformation security and privacy policies, the term requirement  is generally used to refer to \ninformation security and privacy obligations imposed on organization s. For example, [ OMB A -\n130] imposes information security and privacy requirements with which federal agencies must \ncomply when managing information resources. The term requirement  can also be used in a \nbroader sense to refe r to an expression of stakeholder protection needs for a particular system \nor organization. Stakeholder protection needs and the corresponding security and privacy \nrequirements may be derived from many sources", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1012{"doi": "NIST.SP.800-53r5", "chunk-id": "76", "chunk": " (e.g., laws, executive orders, directives, \nregulations, policies, standards, mission and business needs, or risk assessments). The term \nrequirement, as used in this guideline, includes both legal and policy requirements, as well as an expression of the broader set of stakeholder protection needs that may be derived from other \nsources. All of these requirements, when applied to a system, help determine the necessary  \ncharacteristics of the system \u2014encompassing security, privacy, and assurance.\n24 \nOrganizations may divide security and privacy requirements into more granular categories , \ndepending on where the requirements are employed in the s ystem development life cycle \n(SDLC) and for what purpose. Organizations may use the term capability requirement  to describe \na capability that the system or  organization must provide to satisfy a stakeholder protection \nneed. In addition, organizations may refer to system requirements that pertain to particular \nhardware, software, and firmware components of a system as specification requirements \u2014that \nis, capab ilities that implement all or part of a control and that may be assessed (i.e., as part of \nthe verification, validation, testing, and evaluation processes). Finally, organizations may use the \nterm statement of work requir", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1013{"doi": "NIST.SP.800-53r5", "chunk-id": "77", "chunk": "ements  to refer to actions that mus t be performed operationally \nor during system development.  \n \n24 The system characteristics that impact security and privacy vary and include the system type and function in terms \nof its primary purpose; the system make -up in terms of its technology, mechanical, physical, and human elements; \nthe modes and states within which the s ystem delivers its functions and services; the criticality or importance of the \nsystem and its constituent functions and services; the sensitivity of the data or information processed, stored, or \ntransmitted; the consequence of loss, failure, or degradatio n relative to the ability of the system to execute correctly \nand to provide for its own protection (i.e., self -protection);  and monetary or other value  [SP 800 -160- 1].NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER TWO   PAGE 8 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n Controls  can be viewed as de", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1014{"doi": "NIST.SP.800-53r5", "chunk-id": "78", "chunk": "scriptions of the safeguards and protection capabilities appropriate \nfor achieving the particular security and privacy objectives of the organization and reflecting the \nprotection needs of organizational stakeholders. Controls are selec ted and implemented by the \norganization in order to satisfy the system requirements. Controls can include administrative , \ntechnical, and physical aspects. In some cases, the selection and implementation of a control \nmay necessitate additional specification  by the organization in the form of derived requirements  \nor instantiated control parameter values. The derived requirements and control parameter \nvalues may be necessary to provide the appropriate level of implementation detail for particular \ncontrols with in the SDLC.  \n2.2   CONTROL  STRUCTURE  AND  ORGANIZATION \nSecurity and privacy controls described in this publication have a well-defined organizati on and \nstructure. For ease of use in the security and privacy control selection and specification process,  \ncontrols are organized into 20 families .25 Each family contains controls that are related to the \nspecific  topic of the family. A two-character identifier uniquely identif ies each  control  family  \n(e.g., PS for Personnel Security ). Security  and privacy  controls may invo", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1015{"doi": "NIST.SP.800-53r5", "chunk-id": "79", "chunk": "lve aspects of policy, \noversight , supervision, manual processes , and automated mechanisms  that are implemented  by \nsystems or actions by individuals . Table 1 lists the security and privacy control families  and their  \nassociated family identifiers .  \nTABLE 1: SECURITY AND PRIVACY CONTROL FAMILIES  \nID FAMILY  ID FAMILY  \nAC Access Control  PE Physical and Environmental Protection   \nAT Awareness and Training  PL Planning   \nAU Audit and Accountability  PM Program Management   \nCA Assessment, Authorization , and Monitoring  PS Personnel Security  \nCM Configuration Management  PT PII Processing and Transparency  \nCP Contingency Planning  RA Risk Assessment  \nIA Identification and Authentication  SA System and Services Acquisition  \nIR Incident Response  SC System and Communications Protection  \nMA Maintenance   SI System and Information Integrity  \nMP Media Protection   SR Supply Chain Risk Management  \n \n \nFamilies of controls  contain base controls and control enhancements, which are directly related \nto their base controls. Control enhancements either add functionality or specificity to a base \ncontrol or increase the strength of a base control. C ontrol enhancements are used in systems \nand environments of operation that require greater protection than the protection pr", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1016{"doi": "NIST.SP.800-53r5", "chunk-id": "80", "chunk": "ovided by \nthe base control . The need for organizations to select and implement control enhancements  is \ndue to the potential adverse organizational or individual imp acts or when organizations require \nadditions to the base control functionality or assurance based on assessments of risk. The \n \n25 Of the 20 control families in NIST SP  800- 53, 17  are aligned with the minimum security requirements in [ FIPS 200 ]. \nThe Program Management ( PM), PII Processing and Transparency ( PT), and Supply Chain  Risk Management ( SR) \nfamilies address enterprise- level program management , privacy, and supply chain risk considerations pertaining to \nfederal mandates emergent since [ FIPS 200 ].NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER TWO   PAGE 9 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n selection and implementation of control enhancements always  requires the selection and \nimplementation  of the base control.  \nThe families ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1017{"doi": "NIST.SP.800-53r5", "chunk-id": "81", "chunk": "are arranged in alphabetical order, while the controls and control enhancements \nwithin each family are in numerical order. The order of the families, controls, and control \nenhancements does not  imply any logical progressi on, level of prioritization or importance, or \norder in which the controls or control enhancements are to be implemented. Rather,  it reflects \nthe order in which they were included in the catalog. Control designations are not re -used when \na control is withdr awn.  \nSecurity and privacy control s have the following  structure : a base control  section , a discussion \nsection,  a related controls  section , a control enhancements  section,  and a references  section . \nFigure 1 illustrates the structure of a typical control.  \n \n  \n \n   \n \n  \n \n   \n \n \n  \n \n \n \n \nFIGURE 1: CONTROL STRUCTURE \nThe control  section prescribes a security or privacy capability to be implemented. Security and \nprivacy  capabilit ies are achieved by the activities or actions, automated or nonautomated, \ncarried out by information systems and organizations. Organizations designate th e responsibility \nfor control development, implementation, assessment, and monitoring. Organizations have the \nAU-4 AUDIT STORAGE CAPACITY  \nControl :  Allocate audit record storage capacity to accommod", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1018{"doi": "NIST.SP.800-53r5", "chunk-id": "82", "chunk": "ate [ Assignment: organization-\ndefined audit record retention requirements ].  \nDiscussion :  Organizations consider the types of auditing to be performed and the audit \nprocessing requirements when allocating audit storage capacity. Allocating sufficient audit \nstorage capacity reduces the likelihood of such capacity being exceeded and resulting i n the \npotential loss or reduction of auditing capability.  \nRelated Controls :  AU -2, AU-5, AU-6, AU-7, AU-9, AU-11, AU-12, AU-14, SI-4. \nControl Enhancements : \n(1) AUDIT STORAGE CAPACITY | TRANSFER TO ALTERNATE STORAGE   \nOff-load audit records [Assignment: organization- defined frequency ] onto a different \nsystem or media than the system being audited.  \nDiscussion :  Off-loading is a process designed to preserve the confidentiality and \nintegrity of audit records by moving the records from th e primary system to a secondary \nor alternate system.  It is a common process in systems with limited audit storage \ncapacity; the audit storage is used only in a transitory fashion until the system can communicate with the secondary or alternate system designated for storing the audit records, at which point the information is transferred.  \nRelated Controls :  None.  \nReferences :  None.  \nBase \nControl  \nOrganization -defined Parameter ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1019{"doi": "NIST.SP.800-53r5", "chunk-id": "83", "chunk": " \nControl \nEnhancement  \nSources for additi onal information related to the control  \nOrganization -defined Parameter  \nControl Identifier  \n Control NameNIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER TWO   PAGE 10 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n flexibility to implement the controls selected in whatever manner that satisfies organizational \nmission or business needs consistent with law, regu lation, and policy.  \nThe discussion section provides additional information about a control. Organizations can use \nthe information as needed when developing, tailoring, implementing, assessing, or monitoring \ncontrols. The information provides important cons iderations for implementing controls based \non mission or business requirements, operational environments, or assessments of risk. The \nadditional information can also explain the purpose of controls and often includes examples. \nControl enhancements may also  include a ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1020{"doi": "NIST.SP.800-53r5", "chunk-id": "84", "chunk": "separate discussion section  when the discussion \ninformation is applicable only to a specific  control enhancement.  \nThe related controls  section provides a list of controls from the control catalog that impact or \nsupport the implementation of a pa rticular control or control enhancement, address a related \nsecurity or privacy capability, or are referenced in the discussion section.  Control enhancements \nare inherently related to their base control. Thus , related controls that are referenced in the \nbase control are not repeated in the control enhancements. However, there may be related \ncontrols identified for control enhancements that are not referenced in the base control (i.e., the related control is only associated with the specific control enhancement).  Controls may also \nbe related to enhancements of other base controls.  When a control is designated as a related \ncontrol, a corresponding designation is made on that control in its source location in the catalog to illustrate the two -way relationship.  Additionally, each control in a given family is inherently \nrelated to the -1 control (Policy and Procedures) in the same family. Therefore, the relationship between the -1 control and the other controls in th e same family is not specified in the related \ncontrols  s", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1021{"doi": "NIST.SP.800-53r5", "chunk-id": "85", "chunk": "ection for each control.  \nThe control enhancements  section provides statements of security and privacy capability that \naugment a base control. The control enhancements are numbered sequentially within each control so that the enhancements can be easily identified when selected to supplement the \nbase control.  Each control enhancement has a short subtitle to indicate the intended function or \ncapability provided by the enhancement. In the AU -4 example, if the control enhancement is \nselected, the control designation becomes AU -4(1). The numerical designation of a control \nenhancement is used only to identify that enhancement within the control. The designation is \nnot indicative of the strength of the control enhancement, level of protection, priority, degree of \nimportance, or any hierarchical relationship among the enhancements. Control enhancements \nare not intended to be selected independently. That is, if a control enhancement is selected, then the correspon ding base control is  also selected and implemented.  \nThe references  section includes a list of applicable laws, policies, standards, guidelines, websites, \nand other useful references that are relevant to a specific control or control enhancement.\n26 The \nreferences section also includes  hyperlinks to publicatio", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1022{"doi": "NIST.SP.800-53r5", "chunk-id": "86", "chunk": "ns for obtaining additional information \nfor control development, implementation, assessment, and monitoring.  \n \nFor some controls, additional flexibility is provided by allowing organizations to define specific \nvalues for designated parameters associated with the controls. Flexibility is achieved as part of a \ntailoring process using assignment  and selection  operations  embedded within the controls and \n \n26 References are provided to assist organizations in understanding and implementing  the security and privacy \ncontrols and are not intended to be inclusive or complete.NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER TWO   PAGE 11 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n enclosed by brackets. The assignment and selecti on operations  give organizations the capability \nto customize controls based on organizational  security and privacy requirements. In contrast to \nassignment operations  which allow complete flexibilit", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1023{"doi": "NIST.SP.800-53r5", "chunk-id": "87", "chunk": "y in the designation of parameter values, \nselection operati ons narrow the range of potential values by providing a specific list of items \nfrom which organizations choose. \nDetermination of the organization -defined parameters can evolve from many sources, including \nlaws, executive orders, directives, regulations, po licies, standards, guidance, and mission or \nbusiness needs. Organizational risk assessments and risk tolerance are also important factors in \ndetermining  the values for control parameters. Once specified by the organization, the values \nfor the assignment an d selection operations become a part of the control. Organization -defined \ncontrol parameters used in the base controls also apply to the control enhancements associated \nwith those controls. The implementation of the control is assessed for effectiveness against the \ncompleted control statement.  \nIn addition to assignment and selection operations embedded in a control, additional flexibility is achieved through iteration and refinement  actions.  Iteration allows organizations to use a \ncontrol multiple times with different assignment and selection values, perhaps being applied in \ndifferent situations or when implementing multiple policies. For example, an organization may \nhave multiple systems implemen", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1024{"doi": "NIST.SP.800-53r5", "chunk-id": "88", "chunk": "ting a control but with different parameters established to  \naddress different risks for each system and environment of operation. Refinement is the process \nof providing additional implementation detail to a control. Refinement can also be used to \nnarrow the scope of a control in conjunction with iteration to cover  all applicable scopes (e.g., \napplying different authentication mechanisms to different system interfaces). The combination \nof assignment and selection operations and iteration and refinement actions when applied to controls provides the needed flexibility to allow organizations to satisfy a broad base of security \nand privacy requirements at the organization, mission and business process, and system levels of implementation.  \n \n \n  \n \n \n \n \n \n \n \n \n \n2.3   CONTROL  IMPLEMENTATION  APPROACHES  \nThere are three approaches to implementing the controls in Chapter Three : (1) a  common  \n(inheritable) control  implementation approach , (2) a  system -specific control  implementation \napproach , and (3) a  hybrid  control  implementation approach . The control implementation \napproaches  define  the scope of applicability for the control , the shared nature or inheritability \nof the control , and the responsibility for control development , implementation, assessment,", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1025{"doi": "NIST.SP.800-53r5", "chunk-id": "89", "chunk": " and SECURITY AS A DESIGN PROBLEM  \n\u201cProviding satisfactory security controls in a computer system is\u2026.a system design problem. A \ncombination of hardware, software, communications, physical, personnel and administrative -\nprocedural safeguards is required for comprehensive security\u2026.software safeguards alone are \nnot sufficient.\u201d  \n-- The War e Report  \nDefense Science Board Task Force on Computer Security, 1970NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER TWO   PAGE 12 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n authorization. Each control implementation approach  has a specific objective and focus  that \nhelps organizations select the a ppropriate controls, implement the controls  in an effective \nmanner,  and satisfy security and privacy  requirements . A specific control implementation \napproach may achieve cost benefits by leveraging security and privacy capabilities across \nmultiple systems and environments of operatio", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1026{"doi": "NIST.SP.800-53r5", "chunk-id": "90", "chunk": "n.27 \nCommon controls are controls whose implementation results  in a capability that is inherit able  \nby multiple systems  or programs . A control  is deemed inheritable when the system  or program \nreceive s protection from the implemented control,  but the control  is developed, implemented, \nassessed, authorized, and monitored by an internal or external entity  other than the entity  \nresponsible for the system  or program . The s ecurity and privacy capabilities provided by \ncommon controls can be inherited from many sources , including  mission or business lines, \norganization s, enclaves, environment s of operation, sites, or other system s or programs .  \nImplementing controls as common controls can introduce the risk of a single point of failure. \nMany of the controls needed to pro tect organizational information systems\u2014 including  many \nphysical and environmental protection controls, personnel  security controls, and incident \nresponse controls \u2014are inheritable  and, therefore, are good candidates for common control \nstatus. Common controls  can also include technology -based controls , such as  identification and \nauthentication controls , boundary protection controls, audit and accountability controls,  and \naccess controls . The cost of development, implementation,", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1027{"doi": "NIST.SP.800-53r5", "chunk-id": "91", "chunk": " assessment, authorization, and \nmonitoring  can be amortized across multi ple systems, organizational elements, and programs  \nusing the common control implementation approach . \nControls not implemented as common controls are  implemented as  system -specific  or hybrid \ncontrols.  System -specific controls are the primary responsibility of the system owner and the \nauthorizing official for a given  system . Implementing system -specific controls can introduce risk \nif the control implementations are not interoperable with common controls. Organizations can \nimplement  a control as  hybrid if one part of the control is common  (inheritable) and the other  \npart is system -specific. For example, an organization may implement control CP-2  using a \npredefined template for the  contingency plan for  all organizational information systems with \nindividual system owners tailoring the pla n for system -specific uses , where appropriate . The \ndivision of a hybrid  control into its common (inheritable) and system -specific parts may vary by \norganization, depending on the types of information technologies employed, the approach used \nby the organization t o manage its controls, and assignment of responsibilities.  When a control is \nimplemented  as a hybrid control, the common control", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1028{"doi": "NIST.SP.800-53r5", "chunk-id": "92", "chunk": " provider is responsible for ensuring the   \nimplement ation , assessment , and monitoring of the common  part of the hybrid control , and the \nsystem owner is responsible for ensuring the implement ation , assessment , and monitoring of \nthe system -specific  part of the hybrid control. Implementing controls as hybrid controls can \nintroduce risk if the responsibility for the implementation an d ongoing management of the \ncommon and system-specific parts of the controls is unclear.  \nThe determination as to the appropriate control implementation approach  (i.e., common, \nhybrid , or system -specific)  is context- dependent. The c ontrol  implementation approach  cannot \nbe determined to be common, hybrid , or system -specific simply based on the language of the \n \n27 [SP 800- 37] provide s additional guidance on control implementation approache s (formerly referred to as control \ndesignations)  and how the different approaches  are used in the Risk Management Framework .NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n___________________________________________________________________", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1029{"doi": "NIST.SP.800-53r5", "chunk-id": "93", "chunk": "______________________________  \nCHAPTER TWO   PAGE 13 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n control.  Identifying the control implementation approach can result in significant savings to \norganizations in implementation and ass essment costs and a more consistent application of the \ncontrols organization -wide. Typically, t he identification of  the control implementation approach \nis straightforward . However , the implementation takes significant planning and coordination.  \nPlanning for the implementation approach  of a control (i.e., common, hybrid, or system-specific)  \nis best carried out early in the system development life cycle and coordinated with the entities \nproviding the control  [SP 800 -37]. Similarly, if a control is to be inheritable, coordination is \nrequired with the inheriting entity to ensure that the control meets its needs. This is especially \nimportant given the nature of control parameters. An inheriting entity ca nnot assume that \ncontrols are the same and mitigate the appropriate risk to the system just because the control identifiers  (e.g., \nAC-1) are the same. It is essential to examine the control parameters (e.g., \nassignment or selection operations ) when determining if a  common control ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1030{"doi": "NIST.SP.800-53r5", "chunk-id": "94", "chunk": "is adequate to \nmitigate system -specific risks.  \n2.4   SECURITY  AND  PRIVACY  CONTROLS  \nThe selection and implementation of security and privacy controls reflect the objectives of \ninformation security and privacy programs and how those programs  manage their respective \nrisks. Depending on the circumstances, these objectives and risks can be independent or \noverlapping. Federal i nformation security programs are responsible for protectin g information \nand information systems from unauthorized access, use, disclosure, disruption, modification, or \ndestruction (i.e., unauthorized activity or system behavior) to provide confidentiality, integrity, \nand availability . Those programs are also responsible for man aging security risk and for ensuring \ncompliance with applicable security  requirements . Federal privacy programs are responsible for \nmanaging risks  to individuals associated with the creation, collection, use, processing, storage, \nmaintenance, dissemination, disclosure, o r disposal (collectively referred to as \u201cprocessing\u201d) of \nPII and for ensuring compliance with applicable privacy requirements .28 When a system \nprocesses PII, the information security program and the privacy program have a shared \nresponsibility for managing the security risks for the PII in the ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1031{"doi": "NIST.SP.800-53r5", "chunk-id": "95", "chunk": "system . Due to this overlap in \nresponsibilities, the controls that organizations select to manage these security risks will \ngenerally be the same regardless of their designation as security or privacy controls in control \nbaselines or program or system plans.  \nThere also may be circumstances in which the selection and/or implementation of the  control or \ncontrol enhancement affects the ability of a program to achieve its objectives  and manage its \nrespective risks . The control discussion section may highlight specific security and/or privacy \nconsiderations  so that organizations can take these considerations  into account as they \ndetermine the most effective method to implement the control . However, these considerations \nare not exhaustive.  \nFor example, an organization might select AU -3 (Content of Audit Records) to support \nmonitoring for unauthorized access to an information asset that does not include PII. Since the \n \n28 Privacy programs may also choose to consider the risks to individuals that may arise from their interactions with \ninformation systems, where the processing of personally identifiable information may be less impactful than the \neffect that the system has on individuals\u2019 behavior or activities. Such effects would constitute risks to individual \nau", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1032{"doi": "NIST.SP.800-53r5", "chunk-id": "96", "chunk": "tonomy , and organizations may need to take steps to manage those risks in addition to information security and \nprivacy risks.NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER TWO   PAGE 14 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n potential loss of confidentiality of the information asset does not affect privacy, security \nobjectives are the primary driver for the selection of the control. However, the implementation \nof the control with respect to monitoring for unauthorized access could involve the processing \nof PII which may result in privacy risks and affect privacy program objectives. The discussio n \nsection in AU -3 includes privacy risk considerations so that organizations can take those \nconsiderations into account as they determine the best way to implement the control. \nAdditionally, the control enhancement AU-3(3)  (Limit Personally Identifiable Information \nElements) could be selected to support managing these p", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1033{"doi": "NIST.SP.800-53r5", "chunk-id": "97", "chunk": "rivacy risks. \nDue to permutations in the relationship between information security and privacy program objectives  and risk management , there is a need for close collaboration between programs to \nselect and implement the appropriate controls for information systems processing PII. \nOrganizations consider how to promote and institutionalize collaboration between the two \nprograms to ensure that the objectives of both disciplines are met  and risks are appropriately \nmanaged .\n29 \n2.5   TRUSTWORTHINESS  AND  ASSURANCE  \nThe trustworthiness of systems, system co mponents, and system services  is an important part \nof the risk management strategies developed by organizations.30 Trustworthiness, in this \ncontext, means worthy of being trust ed to fulfill whatever requirements  may be needed for a \ncomponent, subsystem, system, network, application, mission, business function, enterprise, or \nother entity.31 Trustworthiness requirements can include attributes of reliability, dependability, \nperformance, resilience, safety, security, privacy, and survivab ility under a range of potential \nadversity in the form of disruptions, hazards, threats , and privacy  risks . Effective measures of \ntrustworthiness are mea ningful only to the extent that the requirements are complete , well-\ndef", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1034{"doi": "NIST.SP.800-53r5", "chunk-id": "98", "chunk": "ined,  and can be accurately assessed.  \nTwo fundamental concepts  that affect the trustworthiness of systems are functionality  and \nassurance . Functionality is defined in terms of the security and privacy features, functions, \nmechanisms, services, procedures, and architectures implemented within organizational \nsystems and programs and the environments in which those systems and programs operate. \nAssurance is the measure of confidence that the system functionality is implemented correctly, \noperating as intended, and producing the desired outcome with respect to meeting the secur ity \nand privacy requirements for the system\u2014 thus possessing the capability to accurately mediate \nand enforce established security and privacy policies.  \nIn general, the task of prov iding meaningful assurance that a system is likely to do what is \nexpect ed of  it can be enhanced by techniques that simplify or narrow t he analysis by, for \nexample, increasing the discipline applied to the system architecture, software design, \nspecifications, code style , and configuration management. Security and privacy controls a ddress \nfunctionality and assurance. Certain  controls focus primarily on functionality  while o ther \ncontrols focus primarily on assurance. Some controls can support functionality ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1035{"doi": "NIST.SP.800-53r5", "chunk-id": "99", "chunk": "and assurance. \n \n29 Resources to support information security and privacy program collaboration are available at  [SP 800- 53 RES ]. \n30 [SP 800- 160- 1] provides guidance on systems security engineering and the application of security design principles \nto achieve trustworthy systems.  \n31 See [ NEUM04 ].NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER TWO   PAGE 15 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n Organizations can select assurance -related controls to define system development activities,  \ngenerate evidence about the functionality and behavior o f the system , and trace the evidence to \nthe system elements that provide such functionality or exhibit such  behavior. The evidence is \nused to obtain a degree of confidence that the system  satisfies the stated security and privacy \nrequirements  while supporting the organization\u2019s mission and business functions. Assurance -\nrelated controls are identified in the cont ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1036{"doi": "NIST.SP.800-53r5", "chunk-id": "100", "chunk": "rol summary tables in  Appendix C . \nEVIDENCE OF CONTROL IMPLEMENTATION   \nDuring control selection  and implementation,  it is important for organizations to consider  the \nevidence (e.g., artifacts, documentation) that will be needed to support current and future \ncontrol assessments. Such assessments help determine whether the controls are implemented \ncorrectly, operating as intended, and satisfying security and privacy policies\u2014 thus, providing \nessential information for senior leaders to make informed  risk-based decisions.NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 16 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n CHAPTER THREE  \nTHE  CONTROLS  \nSECURITY AND PRIVACY CONTROLS  AND CONTROL ENHANCEMENTS  \nThis catal og of security and priva cy controls provides protective  measures for systems, \norganizations , and individuals .32 The controls are designed to facilitate risk management and \ncompliance with ap", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1037{"doi": "NIST.SP.800-53r5", "chunk-id": "101", "chunk": "plicable federal laws, executive orders, directives, regulations, policies, and \nstandards . With few excep tions,  the security and privacy controls in the catalog  are policy -, \ntechnolog y-, and sector -neutral , meaning that the controls focus on the fundamental measures \nnecessary to protect information and the privacy of individuals across the information life cycle . \nWhile the security and privacy controls are largely policy -, technology -, and sec tor-neutral, that \ndoes not imply that the controls are policy -, technology -, and sector -unaware. Understanding \npolicies, technologies, and sectors is necessary so that the controls are relevant when they are \nimplemented. Employing a policy -, technology -, and sector -neutral control catalog has many \nbenefits . It encourages organizations to:  \n\u2022 Focus on the security and privacy  functions and  capabilities required for mission and \nbusiness success and the protection of information and the privacy of i ndividuals, \nirrespective of the technolo gies that are employed in organizational systems;  \n\u2022 Analyze each security and privacy control for its applicability to specific technologies, \nenvironments of operation, mission and business functions, and communities of interest; \nand \n\u2022 Specify security and privacy policies", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1038{"doi": "NIST.SP.800-53r5", "chunk-id": "102", "chunk": " as part of the tailoring process for controls that have variable parameters.  \nIn the few cases where specific technologies a re referenced in controls, organizations are \ncautioned that the ne ed to manage security and privacy risks  may  go beyond the requirements \nin a single contr ol associated with a technology. The additional  needed protection measures are \nobtained from the other controls in the catalog. Federal Information Processing Standards\n, \nSpecial Publications , and Interagency /Internal Reports  provide guidance on selecting security \nand privacy controls that reduce risk for specific technologies and sect or-specific applications , \nincluding  smart grid, clo ud, healthcare, mobile, industrial control systems, and Internet of Things \n(IoT) devices .33 NIST publications are cited as references as applicable to specific controls in \nSections  3.1 through 3.20 . \nSecurity and privacy controls in the catalog are expected to change over time as controls are \nwithdrawn, revised, and added. To  maintain stability in security and privacy plans, controls are \nnot renumbered each time a control is withdrawn. Rather, notations  of the controls that have \nbeen withdrawn are maintained in the control catalog for historical purposes. Controls may be \nwithdrawn for a variety ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1039{"doi": "NIST.SP.800-53r5", "chunk-id": "103", "chunk": "of reasons , including when the function or capability provided by the \ncontrol has been incorporated into anoth er control , the control  is redundant to an existing \ncontrol , or the control is deemed to be no longer necessary or effective.  \n \n32 The controls in this publication are available online and can be obtained in various formats. See [ NVD 800- 53]. \n33 For example, [SP 800- 82] provides guidance on risk management and control selection for industrial control \nsystems.NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 17 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n New controls are developed on a regular basis using threat and vulnerability information  and \ninformation on the tactics, techniques , and procedures used by adversaries . In addition, new \ncontrols are developed based on a better understanding of how to mitigate information security \nrisks to systems and organizations and risks to the privacy ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1040{"doi": "NIST.SP.800-53r5", "chunk-id": "104", "chunk": "of individuals arising from information \nprocessing. Finally, new controls are developed based on new or changing requirements in laws, \nexecutive orders, regulations, policies, standards, or guidelines. Proposed modifications to the controls are carefully analyzed during each revision cycle, considering the need for stability of \ncontrol s and the need to  be responsive  to changing technologies, threats, vulne rabilities,  types \nof attack , and processing methods. The objective is to adjust  the level of information security \nand privacy over time  to meet the needs of organizations and individuals.NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 18 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n 3.1   ACCESS  CONTROL  \nQuick link to Access Control S ummary Table  \nAC-1  POLICY AND PROCEDURES  \nControl : \na. Develop, document, and disseminate to [ Assignment: organization- defined personnel or \nroles ]: \n1. [Selecti", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1041{"doi": "NIST.SP.800-53r5", "chunk-id": "105", "chunk": "on  (one or more): O rganization- level; Mission/business process- level; System -\nlevel ] access control policy that:  \n(a) Addresses purpose, scope, roles, responsibilities, management commitment, \ncoordination among organizational entities, and compliance; and  \n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, \nstandards, and guidelines; and \n2. Procedures to facilitate the im plementation of the access control policy and the \nassociated access controls;  \nb. Designate an [ Assignment: organization- defined official ] to manage the development, \ndocumentation, and dissemination of the access control policy and procedures;  and \nc. Review and update the current access control:  \n1. Policy [Assignment: organization- defined frequency ] and following [Assignment: \norganization- defined events ]; and \n2. Procedures [ Assignment: organization- defined frequency ] and following [ Assignment: \norganization- defined events ]. \nDiscussion :  Access control  policy and procedures address  the controls in the AC family  that are  \nimplemented within systems and organizations. The risk management strategy is an important \nfactor in establishing such polic ies and procedures. P olicies and procedures contribute to security \nand privacy assurance.", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1042{"doi": "NIST.SP.800-53r5", "chunk-id": "106", "chunk": " Therefore, it is important that security and privacy programs collaborate \non the development  of access control policy and procedures . Security and privacy program \npolicies and procedures at the organization level are preferable, in general, and may obviate  the \nneed for mission - or system -specific policies and procedures. The policy can be include d as part \nof the general security and privacy policy or be represented by multiple policies reflecting the complex nature of organizations. Proced ures can be established for security and privacy \nprograms , for mission  or business processes,  and for systems, if needed. Procedures describe \nhow the policies or controls are implemented and can be directed at the individual  or role that is \nthe object of the procedure. Procedures can be documented in system security and privacy plans \nor in one or more separate documents.  Events that may precipitate an update to access control \npolicy and procedures include  assessment or audit findings, security incidents or breaches , or \nchanges in laws, executive orders, directives, regulations, policies, standards,  and guidelines . \nSimply restating controls does not constitute an organizational policy or procedure.  \nRelated Controls :  IA-1, PM-9, PM-24, PS-8, SI-12. \nControl Enhancem", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1043{"doi": "NIST.SP.800-53r5", "chunk-id": "107", "chunk": "ents :  None.  \nReferences :  [OMB A -130], [SP 800- 12], [SP 800- 30], [SP 800- 39], [SP 800- 100], [IR 7874 ].NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 19 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n AC-2  ACCOUNT MANAGEMENT  \nControl :   \na. Define and document the types of accounts allowed and specifically prohibited for use \nwithin the system;  \nb. Assign account managers;  \nc. Require  [Assignment: organization- defined prerequisites and criteria ] for group and role \nmembership;  \nd. Specify:  \n1. Authorized users  of the system;  \n2. Group and role membership; and  \n3. Access authorizations (i.e., privileges) and [ Assignment: organization- defined attributes \n(as required) ] for each account;  \ne. Require approvals by [ Assignment: organization- defined personnel or roles ] for request s to \ncreate accounts;  \nf. Create, enable, modify, disable, and remove accounts in accordance with [ Assignment: \no", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1044{"doi": "NIST.SP.800-53r5", "chunk-id": "108", "chunk": "rganization- defined policy, procedures, prerequisites, and criteria ]; \ng. Monitor the use of accounts;  \nh. Notify account managers and [ Assignment: organization- defined personnel or roles ] within:  \n1. [Assignment: organization- defined time period ] when accounts are no longer required;  \n2. [Assignment: organization- defined time period ] when users are terminated or \ntransferred; and  \n3. [Assignment: organization -defined time period ] when system usage or need- to-know \nchanges for an individual;  \ni. Authorize access to the system based on:  \n1. A valid access authorization;  \n2. Intended system usage; and  \n3. [Assignment: organization- defined attributes (as required) ]; \nj. Review  accounts for compliance with account management requirements [ Assignment: \norganization- defined frequency ]; \nk. Establish and implement a process for changing shared or group account authenticators  (if \ndeployed) when individuals are removed from the group; and  \nl. Align account management processes with personnel termination and transfer processes.  \nDiscussion :  Examples of system account types include individual, shared, group, system, guest, \nanonymous, emergency, developer, temporary, and service. Identification o f authorized system \nusers and the specification of access priv", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1045{"doi": "NIST.SP.800-53r5", "chunk-id": "109", "chunk": "ileges reflect the requirements in other controls in the \nsecurity plan. Users requiring administrative privileges on system accounts receive additional \nscrutiny by organizational personnel respo nsible for approving such accounts and privileged \naccess, including system owner, mission or business owner, senior agency information security \nofficer, or senior agency official for privacy.  Types of accounts that organizations may wish to \nprohibit due to increased risk include shared , group, emergency , anonymous , temporary , and \nguest  accounts.NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 20 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n Where access involves personally identifiable information, security programs collaborate with \nthe se nior agency official for privacy to establish the specific conditions for group and role \nmembership; specify authorized users, group and role membership, and access authorizat", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1046{"doi": "NIST.SP.800-53r5", "chunk-id": "110", "chunk": "ions  for \neach account ; and creat e, adjust, or remov e system accounts in accordance with organizational \npolicies. Policies can include such information as account expiration dates or other factors that \ntrigger the disabling of accounts. Organizations may choose to define access privileges or other \nattributes by account, type of account,  or a combination of the two. Examples of other attributes \nrequired for authorizing access include restrictions on time  of day, day of week, and point  of \norigin. In defining other system account attributes, organizations consider system -related \nrequirement s and mission/business requirements. Failure to consider these factors could affect \nsystem availability.  \nTemporary and emergency accounts are intended for short -term use. Organizations establish \ntemporary accounts as part of normal account activation proce dures when there is a need for \nshort -term accounts without the demand for immediacy in account activation. Organizations \nestablish emergency accounts in response to crisis situations and with the need for rapid account \nactivation. Therefore, emergency acco unt activation may bypass normal account authorization \nprocesses. Emergency and temporary accounts are not to be confused with infrequently used \naccounts, including l", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1047{"doi": "NIST.SP.800-53r5", "chunk-id": "111", "chunk": "ocal logon accounts used for special tasks or when network resources are \nunavailable (may also be known as accounts of last resort). Such accounts remain available and \nare not subject to automatic disabling or removal dates. Conditions for disabling or deactivating \naccounts include when shared/group, emergency, or temporary accounts are no longer required \nand when individuals are transferred or terminated. Changing shared/group authenticators  when \nmembers leave the group is intended to ensure that former group members do not retain access \nto the shared or group account. Some types of system accounts may require specialized training.  \nRelated Controls :  AC-3, AC-5, AC-6, AC-17, AC-18, AC-20, AC-24, AU-2, AU-12, CM-5, IA-2, IA-4, \nIA-5, IA-8, MA-3, MA-5, PE-2, PL-4, PS-2, PS-4, PS-5, PS-7, PT-2, PT-3, SC-7, SC-12, SC-13, SC-37. \nControl Enhancements : \n(1) ACCOUNT MANAGEMENT | AUTOMATED SYSTEM ACCOUNT MANAGEMENT  \nSupport the management of system accounts using [ Assignment: organization- defined \nautomated mechanisms ]. \nDiscussion :  Automated system account management includes using automated mechanisms \nto create, enabl e, modify, disabl e, and remov e accounts; notify account managers when an  \naccount is created, enabled, modified, disabled, or removed, or when users", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1048{"doi": "NIST.SP.800-53r5", "chunk-id": "112", "chunk": " are terminated \nor transferred;  monitor system account usage; and report atypical system account usage.  \nAutomated  mechanisms can include internal system functions and email, telephonic, and \ntext messaging notifications.  \nRelated Controls :  None.  \n(2) ACCOUNT MANAGEMENT | AUTOMATED TEMPORARY AND EMERGENCY ACCOUNT MANAGEMENT  \nAutomatically [ Selection: remove; disable] temporary and emergency accounts after \n[Assignment: organization- defined time period for each type of account ]. \nDiscussion :  Management of temporary and emergency accounts includes the removal or \ndisabling of such accounts automatically after a predefined time  period rather than at the \nconvenience of the system administrator. Automatic removal or disabling of accounts \nprovides  a more consistent implementation.  \nRelated Controls :  None.  \n(3) ACCOUNT MANAGEMENT | DISABLE ACCOUNTS   \nDisable accounts  within  [Assignment: organization- defined time period ] when the \naccounts:NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n________________________________________________________________________________", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1049{"doi": "NIST.SP.800-53r5", "chunk-id": "113", "chunk": "_________________  \nCHAPTER THREE    PAGE 21 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n (a) Have expired;  \n(b) Are no longer associated with a user or individual;  \n(c) Are in violation of organizational policy; or  \n(d) Have been inactive for [ Assignment: organization- defined time period ]. \nDiscussion :  Disabling expired, inactive, or otherwise anomalous accounts supports the \nconcept s of least privilege and least functionality which reduce the attack surface of the \nsystem.  \nRelated Controls :  None.  \n(4) ACCOUNT MANAGEMENT | AUTOMAT ED AUDIT ACTIONS  \nAutomatically audit account creation, modification, enabling, disabling, and removal \nactions.  \nDiscussion :  Account management audit records are defined in accordance with AU-2 and \nreviewed, analyzed, and reported in accordance with AU-6. \nRelated Controls :  AU-2, AU-6. \n(5) ACCOUNT MANAGEMENT | INACTIVITY LOGOUT  \nRequire that users log out when [ Assignment: organization- defined time  period of \nexpected inactivity or description of when to log out].  \nDiscussion :  Inactivity logout is behavior - or policy -based and requires users to take physical \naction to log out when they are expecting inactivity longer than the defined period. \nAutomatic enforcement of in", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1050{"doi": "NIST.SP.800-53r5", "chunk-id": "114", "chunk": "activity logout  is addressed by AC-11. \nRelated Controls :  AC-11. \n(6) ACCOUNT MANAGEMENT | DYNAMIC PRIVILEGE MANAGEMENT  \nImplement [ Assignment: organization- defined dynamic privilege management \ncapabilities ]. \nDiscussion :  In contrast to access control approaches that employ static accounts and \npredefined user privileges, dynamic access control approaches rely on runtime access control decisions facilitated by dynamic privilege management , such as attribute -based \naccess co ntrol. While user identities remain relatively constant over time, user privileges \ntypically change more frequently based on ongoing mission or business requirements and \nthe operational needs of organizations. An example of dynamic privilege management is the \nimmediate revocation of privileges from users as opposed to requiring that users terminate and restart their sessions to reflect changes in privileges. Dynamic privilege management can also include mechanisms that change user privileges based on dynami c rules as opposed to \nediting specific user profiles. Examples include automatic adjustments of user privileges if they are operating out of their normal work times, if their job function or assignment \nchanges, or if systems are under duress or in emergenc y situations. Dynamic privilege \nm", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1051{"doi": "NIST.SP.800-53r5", "chunk-id": "115", "chunk": "anagement includes the effects of privilege changes, for example, when there are changes \nto encryption keys used for communications.  \nRelated Controls :  AC-16. \n(7) ACCOUNT MANAGEMENT | PRIVILEGED USER ACCOUNTS  \n(a) Establish and administer privileged user accounts in accordance with [ Selection: a role-\nbased access scheme; an attribute -based access scheme ]; \n(b) Monitor privileged role or attribute assignments;  \n(c) Monitor changes to roles or attributes; and  \n(d) Revoke access when privileged role or attribute assignments are no longer \nappropriate.NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 22 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n Discussion :  Privileged roles are organization -defined roles assigned to individuals that allow \nthose individuals to perform certain security -relevant functions that ordinary users are not \nauthorized to perform. Privileged roles include key management, account ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1052{"doi": "NIST.SP.800-53r5", "chunk-id": "116", "chunk": "management, \ndatabase administration, system and network administration, and web administration. A \nrole-based access scheme organizes permit ted system access and privileges into roles. In \ncontrast, an attribute -based access scheme specifies allowed system access and privileges \nbased on attributes.  \nRelated Controls :  None . \n(8) ACCOUNT MANAGEMENT | DYNAMIC ACCOUNT MANAGEMENT  \nCreate, activate, manage, and deactivate [ Assignment: organization- defined system \naccounts ] dynamically.  \nDiscussion :  Approaches for dynamically creating, activating, managing, and deactivating \nsystem accounts rely on automatically provisioning the accounts at runtime for entities that \nwere previously unknown. Organizations plan for the dynamic management, creation, \nactivation, and deactivation of system accounts by establishing trust relationships, business \nrules, and mechanisms with appropriate  authorities to validate related authorizations and \nprivileges.  \nRelated Controls :  AC-16. \n(9) ACCOUNT MANAGEMENT | RESTRICTIONS ON USE OF SHARED AND GROUP ACCOUNTS  \nOnly permit the use of shared and group accounts that meet [ Assignment: organization-\ndefined conditions for establishing shared and group accounts ]. \nDiscussion :  Before permitting the use of shared or group accounts, organi", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1053{"doi": "NIST.SP.800-53r5", "chunk-id": "117", "chunk": "zations consider \nthe increased risk due to the lack of accountabili ty with such accounts.  \nRelated Controls :  None.  \n(10) ACCOUNT MANAGEMENT | SHARED AND GROUP ACCOUNT CREDENTIAL CHANGE  \n[Withdrawn: Incorporated into AC-2k.] \n(11) ACCOUNT MANAGEMENT | USAGE CONDITIONS  \nEnforce [ Assignment: organization- defined circumstances and/or usage conditions ] for  \n[Assignment: organization- defined system accounts ]. \nDiscussion :  Specifying and enforcing usage conditions helps to enforce the principle of least \nprivilege, increase user account ability, and enable effective account monitoring. Account \nmonitoring includes alerts generated if the account is used in violation of organizational \nparameters. Organizations can describe specific conditions or circumstances under which \nsystem accounts can  be used, such as  by restricting usage to certain days of the week, time \nof day, or specific durations of time.  \nRelated Controls :  None.  \n(12) ACCOUNT MANAGEMENT | ACCOUNT MONITORING FOR ATYPICAL USAGE  \n(a) Monitor system accounts for [ Assignment: organization- defined atypical usage ]; and  \n(b) Report atypical usage of system accounts to [ Assignment: organization- defined \npersonnel or roles ]. \nDiscussion :  Atypical usage includes accessing systems at certain times of th", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1054{"doi": "NIST.SP.800-53r5", "chunk-id": "118", "chunk": "e day or from \nlocations that are not consistent with the normal usage patterns of individuals. Monitoring \nfor atypical usage may reveal rogue behavior by individuals or an attack in progress . Account \nmonitoring may inadvertently create privacy risks  since d ata collected to identify atypical \nusage may reveal previously unknown information about the behavior of individuals. Organizations assess and document privacy risks from monitoring account s for atypicalNIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 23 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n usage in their privacy impact assessment and make determinations that are in alignment \nwith their privacy program plan.  \nRelated Controls :  AU-6, AU-7, CA-7, IR-8, SI-4. \n(13) ACCOUNT MANAGEMENT | DISABLE ACCOUNTS FOR HIGH -RISK INDIVIDUALS  \nDisable accounts of individuals  within [ Assignment: organization- defined time period ] of \ndiscovery of [ Assignmen", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1055{"doi": "NIST.SP.800-53r5", "chunk-id": "119", "chunk": "t: organization- defined significant risks ]. \nDiscussion :  Users who pose a significant security and/or privacy risk include individuals for \nwhom reliable evidence indicates either the intention to use authorized access to systems to cause harm or through whom adversaries will cause harm. Such harm includes adverse \nimpacts to organizational operations, organizational assets, individuals, other organizations, \nor the Nation. Close coordination among system administrators, legal staff, human resource \nmanagers, and authorizing officials is essential when disabling system accounts for high- risk \nindividuals.  \nRelated Controls :  AU-6, SI-4. \nReferences :  [SP 800 -162], [SP 800 -178], [SP 800 -192].  \nAC-3  ACCESS ENFORCEMENT  \nControl :  Enforce approved authorizations for logical access to information and system resources \nin accordance with applicable access control policies.  \nDiscussion :  Access control policies control access between active entities or subjects (i.e., users \nor processes acting on behalf of users) and passive entities or objects (i.e., devices, files, records, \ndomains) in organizational systems. In addition to enforcing authorized access at the system level \nand recognizing that systems can host many applications and services in support of mission and ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1056{"doi": "NIST.SP.800-53r5", "chunk-id": "120", "chunk": "\nbusiness functions , access enforcement mechanisms can also be employed at the application and \nservice level to provide increased information security  and privacy. In contrast to logical access \ncontrols that are implemented within the system, physical access controls are addressed by the controls in the Physical and Environmental Protection (\nPE) family.  \nRelated Controls :  AC-2, AC-4, AC-5, AC-6, AC-16, AC-17, AC-18, AC-19, AC-20, AC-21, AC-22, AC-\n24, AC-25, AT-2, AT-3, AU-9, CA-9, CM-5, CM-11, IA-2, IA-5, IA-6, IA-7, IA-11, MA-3, MA-4, MA-5, \nMP-4, PM-2, PS-3, PT-2, PT-3, SA-17, SC-2, SC-3, SC-4, SC-12, SC-13, SC-28, SC-31, SC-34, SI-4, SI-8. \nControl Enhancements : \n(1) ACCESS ENFORCEMENT | RESTRICTED ACCESS TO PRIVILEGED FUNCTIONS  \n[Withdrawn: Incorporated into AC-6.] \n(2) ACCESS ENFORCEMENT | DUAL AUTHORIZATION  \nEnforce dual authorization for [ Assignment: organization -defined privileged commands \nand/or other organization- defined actions ]. \nDiscussion :  Dual authorization , also known as two -person control , reduce s risk related to  \ninsider threat s. Dual authorization mechanisms require the approval of two authorized \nindividuals to execute. To reduce the risk of collusion, organizations consider rotating dual \nauthorization duties. Organizations consider t", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1057{"doi": "NIST.SP.800-53r5", "chunk-id": "121", "chunk": "he risk associated with implementing dual \nauthorization mechanisms when  immediate responses are necessary to ensure public and \nenvironmental safety.  \nRelated Controls :  CP-9, MP-6. \n(3) ACCESS ENFORCEMENT | MANDATORY ACCESS CONTROLNIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 24 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n Enforce [ Assignment: organization- defined mandatory access control policy ] over the set \nof covered subjects and objects specified in the policy,  and where the policy:  \n(a) Is uniformly enforced across the covered subjects and objects within the system;  \n(b) Specifies that a subject that has been granted access to information is constrained \nfrom doing any of the following;  \n(1) Passing the information to unauthorized subjects or objects;  \n(2) Granting its privileges to other subjects;  \n(3) Changing one or more security attributes ( specified  by the policy) on subjects, \nobjects,", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1058{"doi": "NIST.SP.800-53r5", "chunk-id": "122", "chunk": " the system, or system components;  \n(4) Choosing the security attributes and attribute values ( specified by the policy) to \nbe ass ociated with newly created or modified objects; and \n(5) Changing the rules governing access control; and  \n(c) Specifies that [ Assignment: organization- defined subjects ] may explicitly be granted \n[Assignment: organization- defined privileges ] such that they are not l imited by any \ndefined subset (or all) of the above constraints.  \nDiscussion :  Mandatory access co ntrol is a type of nondiscretionary access  control . \nMandatory access control policies constrain what actions subjects can take with information \nobtained from objects for which they have already been granted access. This prevents the \nsubjects from passing the information to unauthorized subjects and objects. Mandatory \naccess control policies constrain actions that subjects can take with respect to the \npropagation of access control privileges; that is, a subject with a privilege cannot pass that \nprivilege to other subjects. The policy is uniformly enforced over  all subjects and objects to \nwhich the system has control . Otherwise, the access control policy can be circumvented. This \nenforcement is provided by an implementation that meets the reference monitor concept as \ndes", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1059{"doi": "NIST.SP.800-53r5", "chunk-id": "123", "chunk": "cribed in AC-25. The policy is bounded by the system (i.e., once the information is passed \noutside of the control of the system, additional means may be required to ensure that the \nconstraints on the information remain in effect).  \nThe trusted subjects described above are granted privileges consistent with the concept of \nleast privilege (see AC-6). Trusted subjects are only given the minimum privileges necessary \nfor satisfying organizational mission/business needs relative to the above policy . The control \nis most applicable when there is a mandate that establishes a policy regarding access to \ncontrolled unclassified information or  classified information and some users of the system \nare not authorized access to all such information resident in the system. Mandatory access \ncontrol can operate in conjunction with  discretionary access control  as described in  AC-3(4). \nA subject constrained in its operation by mandatory access control policies can still operate \nunder the les s rigorous constraints of AC- 3(4), but mandatory access control policies take \nprecedence over the less rigorous constraints of AC- 3(4). For example, while a mandatory \naccess control policy imposes a constraint that prevent s a subject from passing informati on \nto another subject operating at a ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1060{"doi": "NIST.SP.800-53r5", "chunk-id": "124", "chunk": "different impact or classification  level , AC-3(4) permits the \nsubject to pass the information to any other subject with the same impact or classification  \nlevel  as the subject.  Examples of mandatory access control policies include the Bell -LaPadula \npolicy to protect confidentiality of information and the Biba policy to protect the integrity of \ninformation.  \nRelated Controls :  SC-7. \n(4) ACCESS ENFORCEMENT | DISCRETIONARY ACCESS CONTROL   \nEnforce [Assignment: organization- defined discretionary access control policy ] over the set \nof covered subjects and objects specified in the policy, and where the policy specifies that a subject that has been granted access to information can do one or more of the following:  \n(a) Pass the information to any other subjects or objects;NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 25 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n (b) Grant its privileges to other subje", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1061{"doi": "NIST.SP.800-53r5", "chunk-id": "125", "chunk": "cts;  \n(c) Change security attributes on subjects, objects, the system, or the system\u2019s \ncompone nts; \n(d) Choose the security attributes to be associated with newly created or revised objects; or \n(e) Change the rules governing access control.  \nDiscussion :  When discretionary access control policies are implemented, subjects are not \nconstrained with regard to  what actions they can take with information for which they have \nalready been granted access. Thus, subjects that have been granted access to information  \nare not prevented from passing the information to other subjects or objects  (i.e., subjects \nhave the discretion to pass) . Discretionary access control can operate in conjunction with  \nmandatory access control as described in AC-3(3) and AC-3(15) . A subject that is constrained \nin its operation by mandatory access control policies can still operate under the less rigorous \nconstraints of discretionary access  control . Therefore, while AC-3(3) imposes constraints that \nprevent a subject from passing information to another subject operating at a different \nimpact or classification  level , AC-3(4) permits the subject to pass the information to any \nsubject at the same impact or classification  level . The policy is bounded by the system. Once \nthe information is p", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1062{"doi": "NIST.SP.800-53r5", "chunk-id": "126", "chunk": "assed outside of system control, additional means may be required to \nensure that the constraints remain in effect. While traditional defi nitions of discretionary \naccess control require identity- based access control, that limitation is not required for this \nparticular use of discretionary access control.  \nRelated Controls :  None . \n(5) ACCESS ENFORCEMENT | SECURITY -RELEVANT INFORMATION   \nPrevent access to [ Assignment: organization- defined security -relevant information] except \nduring secure, non- operable system states.  \nDiscussion :  Security- relevant information is information within systems that can potentially \nimpact the operation of security functions or the provision of security services in a manner that could result in failure to enforce system security and privacy policies or maintain the \nseparation  of code and data. Security- relevant information includes access control lists, \nfiltering rules for routers or firewalls, configuration parameters for security services , and \ncryptographic key management information. Secure, non- opera ble system states include  the \ntimes in which systems are not performing mission  or business -related processing , such as \nwhen  the system is offline for maintenance, boot- up, troubleshooting, or shut down.  \nRelated Contr", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1063{"doi": "NIST.SP.800-53r5", "chunk-id": "127", "chunk": "ols :  CM -6, SC-39. \n(6) ACCESS ENFORCEMENT | PROTECTION OF USER AND SYSTEM INFORMATION   \n[Withdrawn: Incorporated into MP-4 and SC-28.] \n(7) ACCESS ENFORCEMENT | ROLE -BASED ACCESS CONTROL  \nEnforce a role -based access control policy  over defined subjects and objects and control \naccess based upon [ Assignment: organization- defined roles and users authorized to \nassume such roles ]. \nDiscussion :  Role -based access control (RBAC) is an access control policy that enforces access \nto objects and system functions based on the defined role (i.e., job function) of the subject. \nOrganizations can create specific roles based on job functions and the authorizations (i.e., \nprivileges) to perform needed operations on the systems associated with the organization -\ndefined roles. When users are assigned to specific roles, they inherit the authorizations or \nprivileges defined for thos e roles. RBAC simplifies privilege administration for organizations \nbecause privileges are not assigned directly to every user (which can be a large number of \nindividuals) but are instead acquired through role assignments. RBAC can also increaseNIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYST", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1064{"doi": "NIST.SP.800-53r5", "chunk-id": "128", "chunk": "EMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 26 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n privacy and security risk if individuals assigned to a role are given access to information \nbeyond what they need to support organizational missions or business functions. RBAC can \nbe implemented as a mandatory or discretionary form of access control. For organizati ons \nimplementing RBAC with mandatory access controls, the requirements in AC -3(3) define the \nscope of the subjects and objects covered by the policy.  \nRelated Controls :  None . \n(8) ACCESS ENFORCEMENT | REVOCATION OF  ACCESS AUTHORIZATIONS   \nEnforce the revocation of access authorizations resulting from changes to the security \nattributes of subjects and objects based on [ Assignment: organization- defined rules \ngoverning the timing of revocations of access authorizations ]. \nDiscussion :  Revocation of access rules may differ based on the types of access revoked. For \nexample, if a subject (i.e., user or process  acting on behalf of a user ) is removed from a \ngroup, access may not be revoked until the ne", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1065{"doi": "NIST.SP.800-53r5", "chunk-id": "129", "chunk": "xt time the object is opened or the ne xt time \nthe subject attempts to access the object. Revocation based on changes to security labels \nmay take effect immediately. Organizations provide alternative approaches on how to make \nrevocations immediate if systems cannot provide such capability and immediate revocation \nis necessary.  \nRelated Controls :  None . \n(9) ACCESS ENFORCEMENT | CONTROLLED RELEASE   \nRelease information outside of the system only if:  \n(a) The receiving [ Assignment: organization- defined system or system component] \nprovides [ Assignment: organization- defined controls ]; and  \n(b) [Assignment: organization- defined controls ] are used to validate the appropriateness \nof the information designated for release.  \nDiscussion :  Organizations  can only directly protect information when it resides within the \nsystem. Additional controls may be needed to ensure that organizational  information is \nadequately protected once it is transmitted outside of  the system. In situations where the \nsystem is unabl e to determine the adequacy of the protections provided by external entities, \nas a mitigation measure , organizations procedurally determine whether the external systems \nare providing adequate controls . The means used to determine the adequacy of controls  \n", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1066{"doi": "NIST.SP.800-53r5", "chunk-id": "130", "chunk": "provided by exter nal systems include  conducting periodic  assessments (inspections/tests) , \nestablishing agreements between the organization and its counterpart organizations , or \nsome other process. The means used by external entities to protect the information received \nneed not be the same as those used by the organization, but the means employed are \nsufficient to provide consistent adjudication of the security and privacy policy to protect the \ninformation  and individuals\u2019 privacy . \nControlled release of information requires systems to implement  technical or procedural \nmeans to validate the information prior to releasing it to external systems. For example, if \nthe system passes information to a system controlled by another organization, technical \nmeans are employed to validate that the security and privacy attributes associated with the \nexported information are appropriate for the receiving system. Alternatively, if the system \npasses information to a printer in organization -controlled space, procedural means can be \nemployed to ensure that only aut horized individuals gain access to the printer.  \nRelated Controls :  CA-3, PT-7, PT-8, SA-9, SC-16. \n(10) ACCESS ENFORCEMENT | AUDITED OVERRIDE OF ACCESS CONTROL MECHANISMS   \nEmploy an audited override of automated ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1067{"doi": "NIST.SP.800-53r5", "chunk-id": "131", "chunk": "access control mechanisms under [ Assignment: \norganization- defined conditions ] by [ Assignment: organization- defined roles ].NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 27 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n Discussion :  In certain situations, such as when  there is a threat to human life or an event \nthat threatens the organization\u2019s ability to carry out critical missions or business functions, \nan override capability for access control mechanisms may be needed . Override conditions \nare defined by organizations and used only in those limited circumstances.  Audit events are \ndefined in AU-2. Audit records are generated in AU-12. \nRelated Controls :  AU-2, AU-6, AU-10, AU-12, AU-14. \n(11) ACCESS ENFORCEMENT | RESTRICT ACCESS TO SPECIFIC INFORMATIO N TYPES   \nRestrict access to data repositories containing [ Assignment: organization -defined \ninformation types ]. \nDiscussion :  Restricting access ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1068{"doi": "NIST.SP.800-53r5", "chunk-id": "132", "chunk": "to specific information is intended  to provide flexibility \nregarding  access control of specific information types within a  system. For example, role -\nbased access could be employed to allow access to only a specific  type of personally \nidentifiable information within a database rather than allowing access to the database in its \nentirety. Other examples include restricting access to cryptographic keys, authentication \ninformation, and selected system information.  \nRelated Controls :  CM -8, CM-12, CM-13, PM-5. \n(12) ACCESS ENFORCEMENT | ASSERT AND ENFORCE APPLICATION ACCESS  \n(a) Require applications to assert, as part of the installation process, the access needed to  \nthe following system applications and functions:  [Assignment: organization- defined \nsystem applications and functions ]; \n(b) Provide an enforcement mechanism to prevent unauthorized access ; and  \n(c) Approve access changes after initial installation  of the application . \nDiscussion :  Asserting and enforcing application access is intended to address applications \nthat need to access existing system applications and functions , including  user contacts , \nglobal positioning system s, camera s, keyboard s, microphone s, network s, phones , or other \nfiles.  \nRelated Controls :  CM -7. \n(13) ACCESS ENFORC", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1069{"doi": "NIST.SP.800-53r5", "chunk-id": "133", "chunk": "EMENT | ATTRIBUTE -BASED ACCESS CONTROL  \nEnforce attribute -based access control policy  over defined subjects and objects and control \naccess based upon [ Assignment: organization- defined attributes to assume access \npermissions ]. \nDiscussion :  Attribute -based access control  is an access control policy that restricts system \naccess to authorized users based on specified  organizational attributes  (e.g. , job function , \nidentity ), action attributes (e.g., read, write, delete) , environmental attributes  (e.g. , time of \nday, location ), and resource attributes  (e.g. , classification of a document) . Organizations can \ncreate rules based on attributes and the authorizations (i.e., privileges) to perform needed operations on the systems associated with organization -defined attributes and rule s. When \nusers are assigned to attributes defined in attribute -based access control policies or rules, \nthey can be provisioned to a system with the appropriate privileges or dynamically granted \naccess to a protected resource. Attribute -based access control  can be implemented as either \na mandatory or discretionary form of access control. When implemented with mandatory \naccess controls, the requirements in \nAC-3(3) define the scope of the subjects and objects \ncovered by the po", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1070{"doi": "NIST.SP.800-53r5", "chunk-id": "134", "chunk": "licy.  \nRelated Controls :  None . \n(14) ACCESS ENFORCEMENT | INDIVIDUAL ACCESSNIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 28 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n Provide [ Assignment: organization- defined mechanisms ] to enable individuals to have \naccess to  the following elements of their personally identifiable information : [Assignment: \norganization- defined elements ]. \nDiscussion :  Individual a ccess affords individuals the ability to review personally identifiable \ninformation about them held within organizational records, regardless of format. Access \nhelp s individuals to develop an understanding about how their personally identifiable \ninformation is being processed . It can also help individuals ensure that their data is accurate. \nAccess m echanisms can include  request forms and application interfaces. For federal \nagenc ies, [ PRIVACT ] processes  can be located in systems of record no", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1071{"doi": "NIST.SP.800-53r5", "chunk-id": "135", "chunk": "tices and on agency \nwebsites. Access to certain types of records may not be appropriate (e.g.,  for federal \nagencies,  law enforcement records within a system of records may be exempt from \ndisclosure under the [ PRIVACT ]) or may require certain levels of authentication assurance. \nOrganizational personnel consult with the senior agency official for privacy and legal counsel \nto determine appropriate mechanisms and access rights or limitations.  \nRelated Controls :  IA-8, PM-22, PM-20, PM-21, PT-6. \n(15) ACCESS ENFORCEMENT | DISCRETIONARY AND MANDATORY ACCESS CONTROL  \n(a) Enforce [ Assignment: organization- defined mandatory access control policy ] over the \nset of covered subjects and objects specified in the policy ; and  \n(b) Enforce [ Assignment: organization- defined discretionary access control policy ] over \nthe set of covered subjects and objects specified in the policy . \nDiscussion :  Simultaneously i mplementing a mandatory access control policy and a \ndiscretionary access control policy can provide additional protection against the \nunauthorized execution of code by users or processes acting on behalf of users. This helps \nprevent a single compromised us er or process from compromising the entire system.  \nRelated Controls :  SC-2, SC-3, AC-4. \nReferences :  [PRIV", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1072{"doi": "NIST.SP.800-53r5", "chunk-id": "136", "chunk": "ACT ], [OMB A -130], [SP 800 -57-1], [SP 800- 57-2], [SP 800- 57-3], [SP 800- 162], \n[SP 800- 178], [IR 7874 ]. \nAC-4  INFORMATION FLOW ENFORCEMENT  \nControl :  Enforce approved authorizations for controlling the flow of information within the \nsystem and between connected systems based on [ Assignment: organization- defined \ninformation flow control policies ]. \nDiscussion :  Information flow control regulates where information can travel within a system and \nbetween systems ( in contrast to who is allowed to access the information) and without regard to \nsubsequent accesses to that information. Flow control restrictions include  blocking external \ntraffic that claims to be from within the organization , keeping export -controlled information \nfrom being transmitted in the clear to the Internet , restricting web requests that are not from \nthe internal web proxy server , and limiting inf ormation transfers between organizations based \non data structures and content. Transferring information between organizations may require an \nagreement specifying how the information flow is enforced (s ee CA-3). Transferring informat ion \nbetween systems in different security or privacy domains with different security or privacy \npolicies introduces the risk that such transfers violate one or ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1073{"doi": "NIST.SP.800-53r5", "chunk-id": "137", "chunk": "more domain security or privacy \npolicies. In such situations, information owners/ stewards provide guidance at designated policy \nenforcement points between connected systems. Organizations consider mandating specific \narchitectural solutions  to enforce specific security and privacy policies. Enforcement includes  \nprohibiting information t ransfers between connected systems (i.e., allowing access only) , \nverifying write permissions before accepting information from another security or privacy \ndomain or connected system , employing hardware mechanisms to enforce one -way informationNIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 29 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n flows,  and i mplementing trustworthy regrading mechanisms to reassign security or privacy \nattributes and labels.  \nOrganizations commonly employ information flow control policies and enforcement mechanisms \nto control the flow of informa", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1074{"doi": "NIST.SP.800-53r5", "chunk-id": "138", "chunk": "tion between designated sources and  destinations within systems \nand between connected systems. Flow control is based on the characteristics of the information \nand/or the information path. Enforcement occurs, for example, in boundary protection devices \nthat employ rule sets or establish configuration settings that restrict system services, provide a \npacket -filtering capability based on header information, or provide a message -filtering capability \nbased on message content. Organizations also consider the trustworthiness of filtering  and/or \ninspection mechanisms (i.e., hardware, firmware, and software components) that are critical to \ninformation flow enforcement. Control enhancements 3 through 32 primarily address cross-\ndomain solution needs that focus on more advanced filtering techniques, in- depth analysis, and \nstronger flow enforcement mechanisms implemented in cross- domain products, such as high -\nassurance guards. Such capabilities are generally not available in commercial off -the-shelf \nproducts.  Information flow enforcement also applies to co ntrol plane traffic (e.g., routing and \nDNS).  \nRelated Controls :  AC-3, AC-6, AC-16, AC-17, AC-19, AC-21, AU-10, CA-3, CA-9, CM-7, PL-9, PM-24, \nSA-17, SC-4, SC-7, SC-16, SC-31. \nControl Enhancements : \n(1) INFORMATION", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1075{"doi": "NIST.SP.800-53r5", "chunk-id": "139", "chunk": " FLOW ENFORCEMENT | OBJECT SECURITY AND PRIVACY ATTRIBUTES  \nUse [ Assignment: organization- defined security and privacy attributes] associated with \n[Assignment: organization- defined information, source, and destination objects ] to enforce \n[Assignment: organization- defined information flow control policies ] as a basis for flow \ncontrol decisions.  \nDiscussion :  Information flow enforcement mechanisms compare security and privacy \nattributes associated with information ( i.e., data content and structure) and source  and \ndestination objects and respond appropriately when the enforcement mechanisms \nencounter information flows not explicitly allowed by information flow policies. For \nexample, an information object labeled Secret  would be allowed to flow to a destination \nobject labeled Secret , but an information object labeled Top Secret  would not be allowed to \nflow to a destination object labeled Secret . A dataset of personally identifiable information \nmay be tagged with restrictions against combining  with other types of datasets and , thus , \nwould not be allowed to flow to the restricted dataset. Security and privacy attributes can \nalso include  source and destination addresses employed in traffic filter firewalls. Flow \nenforcement using explicit security or pri", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1076{"doi": "NIST.SP.800-53r5", "chunk-id": "140", "chunk": "vacy attributes can be used, for example, to control \nthe release of certain types of information.  \nRelated Controls :  None.  \n(2) INFORMATION FLO W ENFORCEMENT | PROCESSING DOMAINS   \nUse protected processing domains to enforce  [Assignment: organization -defined \ninformation flow control policies ] as a basis for flow control decisions . \nDiscussion :  Protected processing domains with in systems are processing spaces that have \ncontrolled interactions wit h other processing spaces, enabling control of information flows \nbetween these spaces and to/from information objects. A protected processing domain can \nbe provided, for example, by implementing domain and type enforcement. In domain and \ntype enforcement, system processes are assigned to domains , information is identified by \ntypes , and information flows are controlled based on  allowed information accesses ( i.e., \ndetermined by domain and type), allowed signaling among domains, and allowed proce ss \ntransitions to other domains.NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_______________________________________________", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1077{"doi": "NIST.SP.800-53r5", "chunk-id": "141", "chunk": "__________________________________________________  \nCHAPTER THREE    PAGE 30 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n Related Controls :  SC-39. \n(3) INFORMATION FLOW ENFORCEMENT | DYNAMIC INFORMATION FLOW CONTROL   \nEnforce [ Assignment: organization- defined information flow control policies ]. \nDiscussion :  Organizational policies regarding dynamic information flow control include  \nallowing or disallowing information flows based on changing conditions or mission  or \noperational considerations. Changing conditions include  changes in risk tolerance due to \nchanges in the immediacy of mission  or business needs, changes in the threat environment, \nand detection of potentially harmful or adverse events.  \nRelated Controls :  SI-4. \n(4) INFORMATION FLOW ENFORCEMENT | FLOW CONTROL OF ENCRYPTED INFORMATION   \nPrevent encrypted information from bypassing  [Assignment: organization- defined \ninformation flow control mechanisms ] by [Selection (one or more): decrypting the \ninformation; blocking the flow of the encrypted information; terminating communications \nsessions attempting to pass encrypted information; [Assignment: organization- defined \nprocedure or method ]]. \nDiscussion :  Flow control mechanisms include  content ch", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1078{"doi": "NIST.SP.800-53r5", "chunk-id": "142", "chunk": "ecking, security policy filters, and \ndata type identifiers.  The term encryption is extended to cover encoded data not recognized \nby filtering mechanisms.  \nRelated Controls :  SI-4. \n(5) INFORMATION FLOW ENFORCEMENT | EMBEDDED DATA TYPES   \nEnforce  [Assignment: organization- defined limitations ] on embedding data types within \nother data types.  \nDiscussion :  Embedding data types within other data types may result in reduced flow \ncontrol effectiveness. Data type embedding includes  inserting files a s objects within other \nfiles and using compressed or archived data types that may include multiple  embedded data \ntypes. Limitations on data type embedding consider the levels of embedding and prohibit \nlevels of data type embedding that are beyond the capability of the inspection tools . \nRelated Controls :  None.  \n(6) INFORMATION FLOW ENFORCEMENT | METADATA  \nEnforce information flow control based on  [Assignment: organization- defined metadata].  \nDiscussion :  Metadata is information that describe s the characteristics of data. Metadata can \ninclude  structural metadata describing data structures or descriptive m etadata describing \ndata content. Enforcement of  allowed information flows based on metadata enables simpler \nand more effective flow control. Organizations co", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1079{"doi": "NIST.SP.800-53r5", "chunk-id": "143", "chunk": "nsider the trustworthiness of metad ata \nregarding  data accuracy (i.e., knowledge that the metadata values are correct with respect \nto the data),  data integrity (i.e., protecting against unauthorized changes to metadata tags), \nand the binding of metadata to the data payload (i.e., employing  sufficiently strong binding \ntechniques with appropriate assurance).  \nRelated Controls :  AC-16, SI-7. \n(7) INFORMATION FLOW ENFORCEMENT | ONE-WAY FLOW MECHANISMS   \nEnforce one -way information flows through hardware -based flow control mechanisms.  \nDiscussion :  One-way flow mechanisms may also be referred to as a unidirectional network, \nunidirectional security gateway, or data diode. One -way flow mechanisms can be used to \nprevent data from being exported from a higher impact or classified domain or system while \npermitting data from a lower impact or unclassified domain or system to be imported . \nRelated Controls :  None.NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    P", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1080{"doi": "NIST.SP.800-53r5", "chunk-id": "144", "chunk": "AGE 31 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n (8) INFORMATION FLOW ENFORCEMENT | SECURITY AND PRIVACY POLICY FILTERS  \n(a) Enforce information flow control using  [Assignment: organization- defined security or \nprivacy policy  filters ] as a basis for flow control decisions for [ Assignment: \norganization- defined informati on flows ]; and  \n(b) [Selection (one or more): Block; Strip; Modify; Quarantine] data after a filter \nprocessing failure in accordance with  [Assignment: organization- defined security or \nprivacy policy ]. \nDiscussion :  Organization -defined security or privacy policy filters can address data \nstructures and content. For example, security or privacy policy filters for data structures can \ncheck for maximum file lengths, maximum field sizes, and data/file types (for structu red and \nunstructured data). Security or privacy policy filters for data content can check for specific \nwords,  enumerated values or data value ranges , and hidden content. Structured data \npermits the interpretation of data content by applicatio ns. Unstructur ed data refers to \ndigital information without a data structure or with a data structure that does not facilitate \nthe development of rule sets to address the impact or clas", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1081{"doi": "NIST.SP.800-53r5", "chunk-id": "145", "chunk": "sification level of the information \nconveye d by the data or the flow enforcement decisions. Unstructured data consists of \nbitmap objects that are inherently non-language -based (i.e., image, video, or audio files) and \ntextual objects that are based on written or printed languages. Organizations can implement \nmore than one security or privac y policy filter to meet information flow control objectives.  \nRelated Controls :  None.  \n(9) INFORMATION FLOW ENFORCEMENT | HUMAN REVIEWS   \nEnforce the use of human reviews for [ Assignment: organization- defined information \nflows ] under the following conditions:  [Assignment: organization- defined conditions ]. \nDiscussion :  Organizations define security or privacy policy filters for all situations where \nautomated flow control decisions are possible. When a fully automated flow control decision \nis not possible, then a human review may be employed in lieu of or as a complement to \nautomated security or privacy policy f iltering. Human reviews may also be employed as \ndeemed necessary by organizations.  \nRelated Controls :  None.  \n(10) INFORMATION FLOW ENFORCEMENT | ENABLE AND DISABLE SECURITY OR PRIVACY POLICY FILTERS  \nProvide the capability for privileged administrators to enable and disable [ Assignment: \norganization- defined", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1082{"doi": "NIST.SP.800-53r5", "chunk-id": "146", "chunk": " security or privacy policy filters ] under the following conditions:  \n[Assignment: organization- defined conditions ]. \nDiscussion :  For example, as allowed by the system authorization, administrators can enable \nsecurity or privacy policy filters to accommodate approved data types.  Administrators also \nhave the capability to select the filters that are executed on a specific data flow based on the \ntype of data that is being transferred, the source and destination security domains, and \nother security or privacy relevant features, as needed.  \nRelated Controls :  None.  \n(11) INFORMATION FLOW ENFORCEMENT | CONFIGURATION OF SECURITY OR PRIVACY POLICY FILTERS   \nProvide the capability for privileged administrators to configure  [Assignment: \norganization- defined security or privacy policy filters ] to support different security or \nprivacy policies.  \nDiscussion :  Documentation contains detailed information for configuring security or privacy \npolicy filters. For example, administrators can configure security or privacy policy filters to \ninclude the list of inappropriate words that security or privacy policy mechanisms check in \naccordance with the definitions provided by organizations.  \nRelated Controls :  None.NIST  SP 800- 53, REV. 5                                     ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1083{"doi": "NIST.SP.800-53r5", "chunk-id": "147", "chunk": "                                                SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 32 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n (12) INFORMATION FLOW ENFORCEMENT | DATA TYPE IDENTIFIERS   \nWhen transferring information between different security domains,  use [Assignment: \norganization- defined data type identifiers ] to validate data essential for information flow \ndecisions . \nDiscussion :  Data type identifiers include  filenames, file types, file signatures or tokens, and \nmultiple internal file signatures or tokens.  Systems only allow transfer of data that is  \ncompliant with data type format specifications.  Identification and validation of data types is \nbased o n defined specifications associated  with  each allowed data format.  The filename and \nnumber alone are not used for data type id entification. Content is validated syntactically and \nsemantically against its specification to ens ure that it is the proper data type.  \nRelated Controls :  None.  \n(13) INFORMATION FLOW ENFORCEMENT | DECOMPOS", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1084{"doi": "NIST.SP.800-53r5", "chunk-id": "148", "chunk": "ITION INTO POLICY -RELEVANT SUBCOMPONENTS   \nWhen transferring information between different security domains,  decompose \ninformation into [Assignment: organization -defined policy -relevant subcomponents ] for \nsubmission to policy enforcement mechanisms . \nDiscussion :  Decomposing information into policy -relevant subcomponents prior to \ninformation transfer facilitates policy decisions on source, destination, certificates, \nclassification, attachments, and other security - or privacy -related component differentiators.  \nPolic y enforcement mechanisms apply filtering, inspection, and/or sanitization rules to the \npolicy -relevant subcomponents of information to facilitate flow enforcement prior to \ntransferring such information to different security domains.  \nRelated Controls :  None.  \n(14) INFORMATION FLOW ENFORCEMENT | SECURITY OR PRIVACY POLICY FILTER CONSTRAINTS   \nWhen transferring information between different security domains,  implement \n[Assignment: organization- defined security or privacy policy filters ] requiring fully \nenumerated formats that restrict data structure and content . \nDiscussion :  Data structure and content restrictions reduce the range of potential malicious \nor unsanctioned content in cross -domain transactions. Security or privacy policy filt", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1085{"doi": "NIST.SP.800-53r5", "chunk-id": "149", "chunk": "ers that \nrestrict data structures include  restricting file sizes and field lengths. Data content policy \nfilters include  encoding formats for character sets , restricting character data fields to only \ncontain alpha- numeric characters , prohibiting special characters , and validating schema \nstructures . \nRelated Controls :  None.  \n(15) INFORMATION FLOW ENFO RCEMENT | DETECTION OF UNSANCTIONED INFORMATION  \nWhen transferring information between different security domains,  examine the \ninformation for the presence of [Assignment: organization -defined unsanctioned \ninformation] and prohibit the transfer of such information in accordance with the \n[Assignment: organization- defined security or privacy policy ]. \nDiscussion :  Unsanctioned information includes malicious code , information that is \ninappropriate for release from the source network , or executable code that could disrupt or \nharm the services or systems on the destination network.  \nRelated Controls :  SI-3. \n(16) INFORMATION FLOW ENFORCEMENT | INFORMATION TRANSFERS ON INTERCONNECTED SYSTEMS   \n[Withdrawn: Incorporated into AC-4.] \n(17) INFORMATION FLOW ENFORCEMENT | DOMAIN AUTHENTICATIONNIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIV", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1086{"doi": "NIST.SP.800-53r5", "chunk-id": "150", "chunk": "ACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 33 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n Uniquely identify and authenticate source and destination points by [ Selection (one or \nmore): organization;  system ; application ; service ; individual] for information transfer.  \nDiscussion :  Attribution is a critical component of a security and privacy concept of \noperations. The ability to identify source and destination points for information flowing \nwith in syst ems allows the forensic reconstruction of events and encourages policy \ncompliance by attributing policy violations to specific organizations  or individuals. Successful \ndomain authentication requires that system labels distinguish among systems, organizatio ns, \nand individuals involved in preparing, sending, receiving, or disseminating information.  \nAttribution also allows organizations to better maintain the lineage of personally identifiable \ninformation processing as it flows through systems and can facilita te consent tracking, as \nwell as correction, deletion, or acc", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1087{"doi": "NIST.SP.800-53r5", "chunk-id": "151", "chunk": "ess requests from individuals.  \nRelated Controls :  IA-2, IA-3, IA-9. \n(18) INFORMATION FLOW ENFORCEMENT | SECURITY ATTRIBUTE BINDING   \n[Withdrawn: Incorporated into AC-16.] \n(19) INFORMATION FLOW ENFORCEMENT | VALIDATION OF METADATA   \nWhen transferring information between different security domains, implement  \n[Assignment: organization- defined security  or privacy  policy filters ] on metadata . \nDiscussion :  All information (including metadata and the data to which the metadata applies) \nis subject to filtering and inspection.  Some organizations distinguish between metadata and \ndata payloads (i.e., only the data to which the metadata is bound). Other organizations do \nnot make such distinctions and consider metadata and the data to which the metadata \napplies to be  part of the payload.  \nRelated Controls :  None.  \n(20) INFORMATION FLOW ENFORCEMENT | APPROVED SOLUTIONS   \nEmploy [ Assignment: organization- defined solutions in approved configurations ] to control \nthe flow of [ Assignment: organization- defined information] across security domains.  \nDiscussion :  Organizations define approved solutions and configurations in cross -domain \npolicies and guidance in accordance with the types of information flows across classification \nboundaries. The National Security Ag", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1088{"doi": "NIST.SP.800-53r5", "chunk-id": "152", "chunk": "ency ( NSA) National Cross Domain Strategy and \nMan agement Office provides a listing of approved cross -domain solutions.  Contact \nncdsmo@nsa.gov  for more information.  \nRelated Controls :  None.  \n(21) INFORMATION FLOW ENFORCEMENT | PHYSICAL OR LOGICAL SEPARATION OF INFORMATION FLOWS    \nSeparate information flows logically or physically using [ Assignment: organization- defined \nmechanisms and/or techniques ] to accomplish [ Assignment: organization- defined requir ed \nseparations by types of information].  \nDiscussion :  Enforcing the separation of information flows associated with defined type s of \ndata can enhance protection by ensuring that information is not commingled while in transit \nand by enabling flow control by transmission paths that are not otherwise achievable. Types \nof separable information include  inbound and outbound communications traffic, service \nrequests and responses, and information of differing security impact or classification levels.  \nRelated Controls :  SC-32. \n(22) INFORMATION FLOW ENFORCEMENT | ACCESS ONLY    \nProvide access from a single device to computing platforms, applications, or data residing in multiple different security domains, while preventing information flow between the \ndifferent security domains.NIST  SP 800- 53, REV. 5      ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1089{"doi": "NIST.SP.800-53r5", "chunk-id": "153", "chunk": "                                                                               SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 34 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n Discussion :  The  system  provides a capability  for users to access each connected security \ndomain without providing any mechanisms to allow users to transfer data or information \nbetween the different security domains.  An example of an access -only solution is a terminal \nthat provides a user access to i nformation with different security classifications while \nassuredly keeping the information separate.  \nRelated Controls :  None.  \n(23) INFORMATION FLOW ENFORCEMENT | MODIFY NON -RELEASABLE INFORMATION   \nWhen transferring information between different security domains, m odify non -releasable \ninformation by implementing [ Assignment: organization- defined modification action].  \nDiscussion :  Modifying non- releasable information can help prevent a data spill or attack \nwhen informa tion is transferred across security domains. Modification ac", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1090{"doi": "NIST.SP.800-53r5", "chunk-id": "154", "chunk": "tions include  \nmasking, permutation, alteration, removal, or redaction.  \nRelated Controls :  None.  \n(24) INFORMATION FLOW ENFORCEMENT | INTERNAL NORMALIZED FORMAT   \nWhen transferring information between different security domains, parse incoming data \ninto an internal normalized format and regenerate the data to be consistent  with its \nintended specification.  \nDiscussion :  Converting data into normalized forms is one of most of effective mechanisms \nto stop malicious attacks and large classes of data exfiltration.  \nRelated Controls :  None.  \n(25) INFORMATION FLOW ENFORCEMENT | DATA SANITIZATION   \nWhen tr ansferring information between different security domains, sanitize data to \nminimize [Selection (one or more) : deliver y of malicious content, command and control  of \nmalicious code , malicious code augmentation, and steganography encoded data; spillage \nof sensitive information]  in accordance with [Assignment: organization- defined policy ]]. \nDiscussion :  Data sanitization is the process of irreversibly removing or destroying data \nstored on a memory device ( e.g., hard drives, flash memory/ solid state drives, mobile \ndevices, CDs, and DVDs) or in hard copy form . \nRelated Controls :  MP -6. \n(26) INFORMATION FLOW ENFORCEMENT | AUDIT FILTERING ACTIONS   \nWhen tr", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1091{"doi": "NIST.SP.800-53r5", "chunk-id": "155", "chunk": "ansferring information between different security domains, record and audit \ncontent filtering actions and results for the information being filtered.  \nDiscussion :  Content filtering is the process of inspecting information as it traverses a cross-\ndom ain solution and determines if the information meets a predefined policy. Content \nfiltering  actions and the results of filtering actions are recorded for individual messages to \nensure that the correct filter actions were applied. Content filter reports are used to assist in \ntroubleshooting actions  by, for example, determining why message content was mo dified \nand/or why it failed the filtering process.  Audit events are defined in AU-2. Audit records are \ngenerated in AU-12. \nRelated Controls :  AU-2, AU-3, AU-12. \n(27) INFORMATION FLOW ENFORCEMENT | REDUNDANT /INDEPENDENT FILTERING MECHANISMS   \nWhen transferring information between different security domains, implement content \nfiltering solutions that provide redundant  and independent filtering mechanisms for each \ndata type . \nDiscussion :  Content filtering is the process of inspecting information as it traverses a cross-\ndomain solution and determines if the information meets a predefined policy. RedundantNIST  SP 800- 53, REV. 5                                      ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1092{"doi": "NIST.SP.800-53r5", "chunk-id": "156", "chunk": "                                               SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 35 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n and independent con tent filtering eliminates a single point of failure filtering system. \nIndependence is defined as the implementation of a content filter that uses a different code \nbase and supporting libraries (e.g., two JPEG filters using different vendors\u2019 JPEG libraries)  \nand multiple, independent system processes . \nRelated Controls :  None.  \n(28) INFORMATION FLOW ENFORCEMENT | LINEAR FILTER PIPELINES   \nWhen transferring information between different security domains, implement a linear \ncontent filter pipeline that is enforced with discretionary and mandatory access controls.  \nDiscussion :  Content filtering is the process of inspecting information as it traverses a cross -\ndomain solution and determines if the information meets a predefined policy. The use of linear content filter pipelines ensures that filter processes are non -bypassable and always \ninvoked. In gen", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1093{"doi": "NIST.SP.800-53r5", "chunk-id": "157", "chunk": "eral, the use of parallel filtering architectures for content filtering of a single \ndata type introduces bypass and non- invocation issues.  \nRelated Controls :  None.  \n(29) INFORMATION FLOW ENFORCEMENT | FILTER ORCHESTRATION ENGINES   \nWhen transferring information between different security domains, employ content filter \norchestration engines to ensure that : \n(a) Content f iltering mechanisms successfully complete execution without errors; and  \n(b) Content f iltering actions occur in the correct or der and comply with [ Assignment: \norganization- defined policy ]. \nDiscussion :  Content filtering is the process of inspecting information as it traverses a cross-\ndomain solution and determines if the information meets a predefined security policy. An \norchestration engine coordinates the sequencing of activities (manual and automated) in a \ncontent filtering process. Errors are defined as either anomalous actions or unexpected \ntermination of the content filter process. This is not the same as a filter failing content due \nto non-compliance with policy. Content f ilter reports are a commonly used mechanism to \nensure that expected filtering actions are completed successfu lly.  \nRelated Controls :  None.  \n(30) INFORMATION FLOW ENFORCEMENT | FILTER MECHANISMS USING MULTIPLE ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1094{"doi": "NIST.SP.800-53r5", "chunk-id": "158", "chunk": "PROCESSES  \nWhen transferring information between differ ent security domains, implement content \nfiltering mechanisms using mu ltiple processes.  \nDiscussion :  The use of multiple processes to implement content filtering mechanisms \nreduces the likelihood of a single point of failure . \nRelated Controls :  None.  \n(31) INFORMATION FLOW ENFORCEMENT | FAILED CONTENT TRANSFER PREVENTION  \nWhen transferring information between different security domains, prevent the transfer \nof failed content to the receiving domain.  \nDiscussion :  Content that failed filtering checks can corrupt the system if transferred to the \nreceiving domain.  \nRelated Controls :  None.  \n(32) INFORMATION FLOW ENFORCEMENT | PROCESS REQUIREMENTS FOR INFORMATION TRANSFER  \nWhen transferring information between different security domains, the process that \ntransfers information between filter pipelines:  \n(a) Does not filter message content;  \n(b) Validates filtering metadata;NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n______________________________________________________________________________________________", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1095{"doi": "NIST.SP.800-53r5", "chunk-id": "159", "chunk": "___  \nCHAPTER THREE    PAGE 36 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n (c) Ensures the content associated with the filtering metadata has successfully completed \nfiltering; and  \n(d) Transfers the content to the destination filter  pipeline . \nDiscussion :  The processes transferring information between filter pipelines have minimum \ncomplexity and functionality to provide assurance that the processes o perate correctly . \nRelated Controls :  None.  \nReferences :  [SP-800- 160-1], [SP 800- 162], [SP 800 -178], [IR 8112 ]. \nAC-5  SEPARATION OF DUTIES  \nControl : \na. Identify and document  [Assignment: organization -defined duties of individuals  requiring \nseparation ]; and \nb. Define system access authorizations to support separation of duties . \nDiscussion :  Separation of duties addresses the potential for abuse of authorized privileges and \nhelps to reduce the risk of malevolent activity without collusion. Separation of duties includes  \ndividing mission or business functions and support functions among different  individuals or roles,  \nconducting system support functions with different individuals , and ensuring that security \npersonnel who administer access control functions do not also admi nister audit functions. \nBe", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1096{"doi": "NIST.SP.800-53r5", "chunk-id": "160", "chunk": "cause separation of duty violations can span systems and application domains, organizations \nconsider the entirety of systems and system components when developing policy on separation \nof duties.  Separation of duties  is enforced through the account management activities in AC-2, \naccess control mechanisms in  AC-3, and identity management activities in IA-2, IA-4, and IA-12. \nRelated Controls :  AC-2, AC-3, AC-6, AU-9, CM-5, CM-11, CP-9, IA-2, IA-4, IA-5, IA-12, MA-3, MA-5, \nPS-2, SA-8, SA-17. \nControl Enhancements :  None.  \nReferences :  None.  \nAC-6  LEAST PRIVILEGE  \nControl :  Employ the principle of least privilege, allowing only authorized accesses for users (or \nprocesses acting on behalf of users) that  are necessary to accomplish assigned organizational \ntasks.  \nDiscussion :  Organizations employ least privilege for specific d uties and systems. The principle of \nleast privilege is also applied to system processes, ensuring that the processes have access to systems and operate at privilege levels no higher than necessary to accomplish organizational \nmissions or business functions. Organizations consider the creation of additional processes, roles, and accounts as necessary to achieve least privilege. Organizations apply least privilege to the development, implement", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1097{"doi": "NIST.SP.800-53r5", "chunk-id": "161", "chunk": "ation, and operation of organizational systems.  \nRelated Controls :  AC-2, AC-3, AC-5, AC-16, CM-5, CM-11, PL-2, PM-12, SA-8, SA-15, SA-17, SC-38.   \nControl Enhancements :  \n(1) LEAST PRIVILEGE | AUTHORIZE ACCESS TO SECURITY FUNCTIONS   \nAuthorize  access for [ Assignment: organization- defined individuals or roles ] to: \n(a) [Assignment: organization- defined security functions (deployed in hardware, software, \nand firmware) ]; and  \n(b) [Assignment: organization- defined security -relevant information].NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 37 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n Discussion :  Security functions include  establishing system accounts , configuring access \nauthorizations (i.e., permissions, privileges) , configuring settings for  events to be audited , \nand establishing intrusion detection parameters. S ecurity -relevant information include s \nfiltering rules for routers  or fire", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1098{"doi": "NIST.SP.800-53r5", "chunk-id": "162", "chunk": "walls,  configuration parameters for security services, \ncryptographic key management information, and access control lists. A uthorize d personnel \ninclude  security administrators, system administrators, system security officers, system \nprogrammers, and other privileged users. \nRelated Controls :  AC-17, AC-18, AC-19, AU-9, PE-2. \n(2) LEAST PRIVILEGE | NON-PRIVILEGED ACCESS FOR NONSECURITY FUNCTIONS   \nRequire that users of system accounts  (or roles ) with access to [ Assignment: organization-\ndefined security functions or security -relevant information ] use non- privileged accounts or \nroles, when accessing nonsecurity functions. \nDiscussion :  Requiring the use of non -privileged accounts when accessing nonsecurity \nfunctions  limits exposure when operating from within privileged accounts or roles. The \ninclusion of roles addresses situations where organizations implement access control \npolicies,  such as role -based access control , and where a change of role provides the same \ndegree of assurance in the change of access authorizations for the user and the processes \nacting on behalf of the user as would be provided by a change between a privileged and non-\nprivileged account.  \nRelated Controls :  AC-17, AC-18, AC-19, PL-4. \n(3) LEAST PRIVILEGE | NETWORK ACCESS TO PRIVI", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1099{"doi": "NIST.SP.800-53r5", "chunk-id": "163", "chunk": "LEGED COMMANDS   \nAuthorize network access to [ Assignment: organization- defined privileged commands ] \nonly for [ Assignment: organization- defined compelling operational needs ] and document \nthe rationale for such access in the security plan for the system.  \nDiscussion :  Network access is any access across a network connection in lieu of local access \n(i.e., user being physically present at the device).  \nRelated Controls :  AC-17, AC-18, AC-19. \n(4) LEAST  PRIVILEGE | SEPARATE PROCESSING DOMAINS   \nProvide separate processing domains to enable finer -grained allocation of user privileges.  \nDiscussion :  Providing separate processing domains for finer- grained allocation of user \nprivileges includes using virtualization techniques to permit  additional user privileges within \na virtual machine while restricting privileges to other virtual machines or to the underlying \nphysical machine , implementing separate physical domains, and employing hardware  or \nsoftware domain separation mechanisms.  \nRelated Controls :  AC-4, SC-2, SC-3, SC-30, SC-32, SC-39. \n(5) LEAST PRIVILEGE | PRIVILEGED ACCOUNTS   \nRestrict privileged accounts on the system to [ Assignment: organization -defined personnel \nor roles ]. \nDiscussion :  Privileged accounts, including super user accounts, are ty", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1100{"doi": "NIST.SP.800-53r5", "chunk-id": "164", "chunk": "pically described as \nsystem administrator for various types of commercial off- the-shelf operating systems. \nRestricting privileged accounts to specific personnel or roles prevents day -to-day users from \naccessing  privileged information  or privileged functions. Organizations may differentiate in \nthe application of restricting privileged accounts  between allowed privileges for local \naccounts and for domain accounts provided that they retain the ability t o control system \nconfigurations for key parameters and as otherwise necessary to sufficiently mitigate risk.  \nRelated Controls :  IA-2, MA-3, MA-4.NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 38 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n (6) LEAST PRIVILEGE | PRIVILEGED ACCESS BY NON -ORGANIZATIONAL USERS   \nProhibit privileged access to the system by non- organizational users.  \nDiscussion :  An organizational user is an employee  or an individual con", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1101{"doi": "NIST.SP.800-53r5", "chunk-id": "165", "chunk": "sidered  by the  \norganization to have the equivalent status of an employee . Organizational users includ e \ncontractor s, guest researcher s, or individual s detailed from  other  organization s. A non -\norganizational user is a user who is not an organizational user. Polic ies and pr ocedures for \ngranting equivalent status of employees to individuals include  a need -to-know, citizenship, \nand the relationship to the organization . \nRelated Controls :  AC-18, AC-19, IA-2, IA-8. \n(7) LEAST PRIVILEGE | REVIEW OF USER PRIVILEGES  \n(a) Review [ Assignment: organization- defined frequency ] the privileges assigned to \n[Assignment: organization- defined roles or classes of users ] to validate the need for \nsuch privileges; and  \n(b) Reassign or remove privileges, if necessary, to correctly reflect organizational mission \nand business needs . \nDiscussion :  The need for certain assigned user privileges may change over time to reflect \nchanges in organizational mission and business functions, environments of operation, \ntechnologies, or threats . A periodic review of assigned user privileges is necessary to \ndetermine if the rationale for assigning such privileges remains valid. If the need cannot be \nrevalidated, organizations take appropriate corrective actions.  \nRelated Controls :", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1102{"doi": "NIST.SP.800-53r5", "chunk-id": "166", "chunk": "  CA-7. \n(8) LEAST PRIVILEGE | PRIVIL EGE LEVELS FOR CODE EXECUTION   \nPrevent  the following software from executing at higher privilege levels than users \nexecuting the software:  [Assignment: organization- defined software ]. \nDiscussion :  In certain situations, software applications  or programs need to execute with \nelevated privileges to perform required functions. However, depending on the software \nfunctionality and configuration, if the privileges required for execution are at a higher level \nthan the privileges assigned to organizational users invoking such applications or programs, \nthose users may  indirectly be provided with greater privileges than assigned.  \nRelated Controls :  None.  \n(9) LEAST PRIVILEGE | LOG  USE OF PRIVILEGED FUNCTIONS   \nLog the execution of privileged functions.  \nDiscussion :  The m isuse of privileged functions, either intentionally or unintentionally by \nauthorized users or by unauthorized external entities that have compromised system \naccounts, is a serious and ongoing concern and can have significant adverse impacts on \norganization s. Logging and analyzing  the use of privileged functions  is one way to detect \nsuch misuse and , in doing so, help mitigate the risk from insider threats and the advanced \npersistent threat. \nRelated Cont", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1103{"doi": "NIST.SP.800-53r5", "chunk-id": "167", "chunk": "rols :  AU-2, AU-3, AU-12. \n(10) LEAST PRIVILEGE | PROHIBIT NON -PRIVILEGED USERS FROM EXECUTING PRIVILEGED FUNCTIONS   \nPrevent non -privileged users from executing privileged functions.  \nDiscussion :  Privileged functions include  disabling, circumventing, or altering implemented \nsecurity or privacy controls , establishing system accounts,  performing system integrity \nchecks , and administering cryptographic key management activities. Non- privileged users \nare individu als who  do not possess appropriate authorizations. Privileged functions that \nrequire protection from non -privileged users include  circumventing  intrusion detection andNIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 39 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n prevention mechanisms or malicious code protection mechanisms.  Preventing non -\nprivileged  users from executing privileged functions  is enforced by AC-3. \nRelated Controls :  No", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1104{"doi": "NIST.SP.800-53r5", "chunk-id": "168", "chunk": "ne.   \nReferences :  None.  \nAC-7  UNSUCCESSFUL LOGON ATTEMPTS  \n Control : \na. Enforce a limit of [ Assignment: organization- defined number ] consecutive invalid logon \nattempts by a user during a [ Assignment: organization- defined time  period ]; and  \nb. Automatically [Selection (one or more): lock the account  or node for an  [Assignment: \norganization- defined time  period ]; lock the account  or node until released by an \nadministrator ; delay  next logon prompt per [Assignment: organization- defined delay \nalgorithm ]; notify system administrator;  take  other  [Assignment: organization- defined \naction ]] when the maximum number of unsuccessful attempts is exceeded.  \nDiscussion :  The need to limit unsuccessful logon attempts and take subsequent action when the \nmaximum number of attempts is exceeded  applies regardless of whether the logon occurs via a \nlocal or network connection. Due to the potential for denial of service, automatic lockouts \ninitiated by systems are usually temporary and automatically release after a predetermined , \norganization -defined time period . If a delay algorithm is selected, organizations may employ \ndifferent algorithms for different components of the system based on the capabilities of those \ncomponents. Responses to unsuccessful logon", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1105{"doi": "NIST.SP.800-53r5", "chunk-id": "169", "chunk": " attempts may be implemented at the operating \nsystem and the application levels.  Organization -defined actions that may be taken when the \nnumber of allowed consecutive invalid logon attempts  is exceeded include  prompting the user to  \nanswer a secret question in addition to the username and password,  invoking a lockdown mode \nwith limited user capabilitie s (instead of full lockout) , allowing users to only logon from specified \nInternet Protocol ( IP) addresses , requiring a CAPTCHA to prevent automated attacks , or applying \nuser profiles such as location, time of day, IP address, device, or Media Access Contro l (MAC ) \naddress . If automatic system lockout or execution of a delay algorithm is not implemented in \nsupport of the availability objective, organizations consider a combination of other actions to help prevent brute force attacks . In addition to the above, organizations can prompt user s to \nrespond to a secret question before the number of allowed unsuccessful logon attempts is \nexceeded . Automatically unlocking an account after a specified period of time is generally not \npermitted. H owever, exceptions may be required based on operational mission or need.  \nRelated Controls :  AC-2, AC-9, AU-2, AU-6, IA-5. \nControl Enhancements : \n(1) UNSUCCESSFUL LOGON AT", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1106{"doi": "NIST.SP.800-53r5", "chunk-id": "170", "chunk": "TEMPTS | AUTOMATIC ACCOUNT LOCK  \n[Withdrawn: Incorporated into AC-7.] \n(2) UNSUCCESSFUL LOGON ATTEMPTS | PURGE OR WIPE MOBILE DEVICE   \nPurge or wipe information from [ Assignment: organization- defined mobile devices ] based \non [Assignment: organization- defined purging or wiping requirements and techniques ] \nafter [ Assignment: organization- defined number ] consecutive, unsuccessful device logon \nattempts.  \nDiscussion :  A mobil e device is a computing device that has a small form factor such that it \ncan be carried by a single individual; is designed to operate without a physical connection; \npossesses local, non -removable or removable data storage; and includes a self- contained \npower source. Purging or wiping the device applies only to mobile devices for which the \norganization -defined number of unsuccessful logons  occurs. The logon is to the mobileNIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 40 \nThis publication is available free of charge from: h", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1107{"doi": "NIST.SP.800-53r5", "chunk-id": "171", "chunk": "ttps://doi.org/10.6028/NIST.SP.800 -53r5 \n device, not to any one account on the device. Successful logons to accounts on mobil e \ndevices reset the unsuccessful logon count to zero. Purging or wiping may be unnecessary if \nthe information on the device is protected with sufficiently strong encryption mechanisms.  \nRelated Controls :  AC-19, MP-5, MP-6. \n(3) UNSUCCESSFUL LOGON ATTEMPTS | BIOMETRIC ATTEMPT LIMITING  \nLimit the number of unsuccessful biometric logon attempts to [ Assignment: organization-\ndefined number ]. \nDiscussion :  Biometrics are probabilistic in nature. The ability to successfully authenticate \ncan be impacted by many factors, including matching performance and presentation attack \ndetection mechanisms. Organizations select the appropriate number of attempts for users \nbased on organizationally -defined factors.  \nRelated Controls :  IA-3. \n(4) UNSUCCESSFUL LOGON ATTEMPTS | USE OF ALTERNATE AUTHENTICATION FACTOR   \n(a) Allow the use of [ Assignment: organization -defined authentication factors ] that are \ndifferent from the primary authentication factors  after the number of organization -\ndefined consecutive invalid logon attempts have been exceeded ; and \n(b) Enforce a limit of [ Assignment: organiza tion-defined number ] consecutive invalid \nlogon attempt", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1108{"doi": "NIST.SP.800-53r5", "chunk-id": "172", "chunk": "s through use of the alternative factors by a user during a [ Assignment: \norganization- defined time period ]. \nDiscussion :  The use of alternate authentication factors supports the objective of availability \nand allows a user who  has inadvertently been locked out to use additional authentication \nfactors to bypass the lockout.  \nRelated Controls :  IA-3. \nReferences :   [SP 800- 63-3], [SP 800- 124]. \nAC-8  SYSTEM USE NOTIFICATION  \nControl : \na. Display [ Assignment: organization- defined system use notification message or banner ] to \nusers before granting access to the system that provides privacy and security notices \nconsistent with applicable laws, executive orders, directives, regulations, policies, standards, \nand guidelines and state that:  \n1. Users are accessing a U.S. Government  system;  \n2. System usage may be monitored, recorded, and subject to audit;  \n3. Unauthorized use of the system is prohibited and subject to criminal and civil penalties; \nand \n4. Use of the system indicates consent to monitoring and recording;  \nb. Retain the notification m essage or banner on the screen until users acknowledge the usage \nconditions and take explicit actions to log on to or further access the system; and  \nc. For publicly accessible systems:  \n1. Display system use infor", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1109{"doi": "NIST.SP.800-53r5", "chunk-id": "173", "chunk": "mation [Assignment: organization -defined conditions ], before \ngranting further access to the publicly accessible system;  \n2. Display references, if any, to monitoring, recording, or auditing that are consistent with \nprivacy accommodations for such systems that generally prohibit t hose activities; andNIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 41 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n 3. Include a description of the authorized uses of the system.  \nDiscussion :  System use notifications can be implemented using messages or warning banners \ndisplayed before individuals log in to systems. System use notifications are used on ly for access \nvia logon interfaces with human users. Notifications are not required when human interfaces do \nnot exist. Based on an assessment of risk, organizations consider whether or not a secondary \nsystem use notification is needed to access applicatio ns or other system reso", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1110{"doi": "NIST.SP.800-53r5", "chunk-id": "174", "chunk": "urces after the \ninitial network logon. Organizations consider system use notification messages or banners displayed in multiple languages based on organizational needs and the demographics of system \nusers. Organizations consult with the privacy office for input regarding privacy messaging and the \nOffice of t he General Counsel or organizational equivalent for legal review and approval of \nwarning banner content . \nRelated Controls :  AC-14, PL-4, SI-4. \nControl Enhancements :  None.  \nReferences :  None.  \nAC-9  PREVIOUS LOGON NOTIFICATION  \nControl :  Notify the user, upon successful logon to the system, of the date and time of the last \nlogon.  \nDiscussion :  Previous logon notification is applicable to system  access  via human user interfaces \nand access  to systems that occur s in other types of architectures. Information about the last \nsuccessful logon allows the user to recognize if the date and time provided is not consistent with the user\u2019s last access.  \nRelated Controls :  AC-7, PL-4. \nControl Enhancements : \n(1) PREVIOUS LOGON NOTIFICATION | UNSUCCESSFUL LOGONS  \nNotify the user, upon successful logon, of the number of unsuccessful logon attempts since \nthe last successful logon.  \nDiscussion :  Information about the number of u nsuccessful logon attempts since th", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1111{"doi": "NIST.SP.800-53r5", "chunk-id": "175", "chunk": "e last \nsuccessful logon allows the user to recognize if the number of unsuccessful logon attempts is consistent with the user\u2019s actual logon attempts.  \nRelated Controls :  None.  \n(2) PREVIOUS LOGON NOTIFICATION | SUCCESSFUL AND UNSUCCESSFUL LOGONS  \nNotify the user, upon successful logon, of the number of [ Selection: successful logons; \nunsuccessful logon attempts; both] during [ Assignment: organization- defined  time  period ]. \nDiscussion :  Information about the number of successful and unsuccessful logon attempts \nwithin a specified time period allows the user to recognize if the number and type of logon \nattempts are consistent with the user\u2019s actual logon attempts.  \nRelated Controls :  None.  \n(3) PREVIOUS LOGON NOTIFICATION | NOTIFICATION OF ACCOUNT CHANGES  \nNotify the user, upon successful logon, of changes to [ Assignment: organization- defined \nsecurity -related characteristics or parameters of the user\u2019s account] during [ Assignment: \norganization- defined time period ]. \nDiscussion :  Information about changes to security -related account characteristics within a \nspecified time period allows users to recognize if changes were made without their knowledge.NIST  SP 800- 53, REV. 5                                                                                   ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1112{"doi": "NIST.SP.800-53r5", "chunk-id": "176", "chunk": "  SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 42 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n Related Control s:  None.  \n(4) PREVIOUS LOGON NOTIFICATION | ADDITIONAL LOGON INFORMATION   \nNotify the user, upon successful logon, of the following additional information: \n[Assignment: organization- defined additional information] . \nDiscussion :  Organizations can specify additional information to be provided to users upon \nlogon , including the location of the last logon. User location is defined as information that \ncan be determined by systems, such as  Internet Protocol (IP) addresses from which network \nlogons occurred, notifications of local logons, or device identifiers.  \nRelated Controls :  None.  \nReferences :  None.  \nAC-10  CONCURRENT SESSION CONTROL  \nControl :  Limit the number of concurrent sessions for each [ Assignment: organization- defined \naccount and/or account type] to [ Assignment: organization -defined number ]. \nDiscussion :  Organizations may define the maximum number of concurrent sessions for ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1113{"doi": "NIST.SP.800-53r5", "chunk-id": "177", "chunk": "system \naccounts globally, by account type, by account, or any combination thereof . For example, \norganizations may limit the number of concurrent sessions for system administrators or other \nindividuals working in particularly sensitive domains or mission -critical applications. Concurrent \nsession control addresses concurrent sessions for system accounts . It does not,  however, address \nconcurrent sessions by single users via multiple syste m accounts.  \nRelated Controls :  SC-23. \nControl Enhancements :  None.  \nReferences :  None.  \nAC-11  DEVICE LOCK  \nControl : \na. Prevent further access to the system by [ Selection (one or more): initiating a device lock after \n[Assignment: organization- defined time period ] of inactivity ; requiring the user to initiate a \ndevice lock before leaving the system unattended] ; and  \nb. Retain the device lock until the user reestablishes access using established identification and \nauthentication procedures.  \nDiscussion :  Device locks are temporary actions taken to prevent logical access to organizational \nsystems when users stop work and move away from the immediate vicinity of  those systems but \ndo not want to log out because of the temporary nature of their absences. Device locks can be \nimplemented at the operating system level  or ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1114{"doi": "NIST.SP.800-53r5", "chunk-id": "178", "chunk": "at the application level. A proximity lock may be \nused to initiate the device lock (e.g., via a Bl uetooth -enabled device or dongle). User -initiated  \ndevice locking is behavior or policy -based and,  as such, requires users to take physical action to \ninitiate the device lock. Device locks are not an acceptable substitute for logging out of systems, \nsuch as  when  organizations require users to log out at the end of workdays.  \nRelated Controls :  AC-2, AC-7, IA-11, PL-4. \nControl Enhancements : \n(1) DEVICE LOCK | PATTERN -HIDING DISPLAYS  \nConceal, via the device lock, information previously visible on the display with a publicly \nviewable image.NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 43 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n Discussion :  The pattern -hiding display can include static or dynamic images, such as \npatterns used with screen savers, photographic images, solid colors, clock, battery", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1115{"doi": "NIST.SP.800-53r5", "chunk-id": "179", "chunk": " life \nindicator, or a blank screen with the caveat that controlled unclassified  information is not \ndisplayed.  \nRelated Controls :  None.  \nReferences :  None.  \nAC-12  SESSION TERMINATION  \nControl :  Automatically terminate a user session after [ Assignment: organization -defined \nconditions or trigger events requiring session disconnect ]. \nDiscussion :  Session termination addresses the termination of user- initiated logical sessions (in \ncontrast to SC-10, which addresses the termination of network connections associated with \ncommunications sessions (i.e., network disconnect) ). A logical session (for local, network, and \nremote access) is initiated whenever a user (or process acting on behalf of a user) accesses an \norganizational system. Such user sessions can be terminated without terminating network \nsessions. Session termination ends  all processes associated with a user\u2019s logical session except \nfor those processes that are specifically created by the user (i.e., session owner) to continue after \nthe session is terminated. Conditions or trigger events that requir e automatic termination  of the \nsession  include  organization -defined periods of user inactivity, targeted responses to certain \ntypes of incidents, or time -of-day restrictions on system use.  \nRelated", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1116{"doi": "NIST.SP.800-53r5", "chunk-id": "180", "chunk": " Controls :  MA -4, SC-10, SC-23. \nControl Enhancements : \n(1) SESSION TERMINATION | USER -INITIATED LOGOUTS   \nProvide a logout capability for user -initiated communications sessions whenever \nauthentication is used to gain access to [ Assignment: organization- defined information \nresources ]. \nDiscussion :  Information resources to which users gain access via authentication include  local \nworkstations, databases, and password -protected websites  or web -based services.  \nRelated Controls :  None.  \n(2) SESSION TERMINATION | TERMINATION MESSAGE   \nDisplay an explicit logout message to users indicating the termination of authenticated \ncommunications sessions.  \nDiscussion :  Logout messages for web access  can be displayed after authenticated sessions \nhave been terminated. However, for certain  types of sessions,  including  file transfer protocol \n(FTP) sessions, systems typically send logout messages as final messages prior to terminating \nsessions.  \nRelated Controls :  None.  \n(3) SESSION TERMINATION | TIMEOUT WARNING MESSAGE   \nDisplay an explicit message to users indicating that the session will end in [Assignment: \norganization- defined time until end of session ]. \nDiscussion :  To increase usability, notify users of pending session termination and prompt \nusers to c", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1117{"doi": "NIST.SP.800-53r5", "chunk-id": "181", "chunk": "ontinue the session.  The pending session termination time period is based on the \nparameters defined in the AC-12 base control.  \nRelated Controls :  None.  \nReferences :  None.NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 44 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n AC-13 SUPERVISION AND REVIEW \u2014  ACCESS CONTROL  \n[Withdrawn: Incorporated into AC-2 and AU-6.] \nAC-14  PERMITTED ACTIONS WITHOUT IDENTIFICATION OR AUTHENTICATION  \nControl : \na. Identify [ Assignment: organization- defined user actions ] that can be performed on the \nsystem without identification or authentication consistent with organizational mission and \nbusiness functions; and  \nb. Document and provide supporting rationale in the security plan for the system, user actions \nnot requiring identi fication or authentication.  \nDiscussion :  Specific user actions may be permitted without identification or authentication if \norganizations determine", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1118{"doi": "NIST.SP.800-53r5", "chunk-id": "182", "chunk": " that identification and  authentication are not required for the specified \nuser actions . Organizations may al low a limited number of user actions without identification or \nauthentication , including when individuals access public websites or other publicly accessible \nfederal systems , when individuals use mobile phones to receive calls,  or when facsimiles are \nreceived. Organizations identify actions that normally require identification or authentication but \nmay , under certain circumstances, allow identification or authentication mechanisms to be \nbypassed. Such bypasses may occur, for example, via a software -readable physical switch that \ncommands bypass of the logon functionality and is protected from accidental or unmonitored \nuse. Permitting actions without identification or authentication  does not apply to situations \nwhere identification and authentication have already occurred and are not repeated but rather \nto situations where identification and authentication have not yet occurred. Organizations may \ndecide that there are no user actions that can be performed on organizational systems withou t \nidentification and authentication,  and therefore, the value for the assignment  operation can be \n\u201cnone. \u201d \nRelated Controls :  AC-8, IA-2, PL-2. \nControl Enhancement", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1119{"doi": "NIST.SP.800-53r5", "chunk-id": "183", "chunk": "s :  None.  \n(1) PERMITTED ACTIONS WITHOUT IDENTIFICATION OR AUTHENTICATION | NECESSARY USES  \n[Withdrawn: Incorporated into AC-14.] \nReferences :  None.  \nAC-15 AUTOMATED MARKING  \n[Withdrawn: Incorporated into MP-3.] \nAC-16  SECURITY AND PRIVACY ATTRIBUTES  \nControl : \na. Provide the means to associate [ Assignment: organization- defined types of security and \nprivacy attributes ] with  [Assignment: organization -defined security and privacy attribute \nvalues ] for information in storage, in process, and/or in transmission;  \nb. Ensure that the attribute associations are made and retained with the information;  \nc. Establish the following permitted  security and privacy attributes  from the attributes defined \nin AC-16a for [ Assignment: organization- defined systems ]: [Assignment: organization- defined \nsecurity and privacy attributes ];NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 45 \nThis publication is available free of charge from: https://doi.org/10.6028", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1120{"doi": "NIST.SP.800-53r5", "chunk-id": "184", "chunk": "/NIST.SP.800 -53r5 \n d. Determine the following permitted attribute  values or ranges for each of the established \nattributes : [Assignment: organization- defined attribute values or ranges  for established \nattributes] ; \ne. Audit changes to attributes; and  \nf. Review [Assignment: organization- defined security and privacy attributes ] for applicability \n[Assignment: organization- defined frequency ]. \nDiscussion :  Information is represented internally within systems using abstractions known as \ndata structures. Internal data s tructures can represent different types of entities, both active and \npassive. Active entities, also known as subjects, are typically associated with individuals, devices, \nor processes acting on behalf of individuals. Passive entities, also known as objects , are typically \nassociated with data structures , such as records, buffers, tables, files, inter- process pipes, and \ncommunications ports. Security attributes, a form of metadata, are abstractions that represent \nthe basic properties or characteristics of active and passive entities with respect to safeguarding \ninformation. Privacy attributes, which may be used independentl y or in conjunction with security \nattributes, represent the basic properties or characteristics of active or passive entiti", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1121{"doi": "NIST.SP.800-53r5", "chunk-id": "185", "chunk": "es with \nrespect to the management of personally identifiable information. Attributes can be either \nexplicitly or implicitly associate d with the information contained in organizational systems or \nsystem components.  \nAttributes may be associated with active entities (i.e., subjects) that have the potential to send or \nreceive information, cause information to flow among objects, or change the system state. These \nattributes may also be associated with passive entities (i.e., objects) that contain or receive information. The association of attributes to subjects and objects by a system is referred to as \nbinding and is inclusive of setting the attribute value and the attribute type. A ttributes , when \nbound to data or information, permit the enforcement of security and privacy policies for access \ncontrol and information flow control , including data retention limits, permitted uses of \npersonally id entifiable information , and identification of personal information within data \nobjects . Such enforcement occurs through organizational processes or system functions or \nmechanisms. The b inding techniques implemented by systems affect the strength of attribute \nbinding to information. Binding strength and the assurance associated with binding techniques \nplay important part s i", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1122{"doi": "NIST.SP.800-53r5", "chunk-id": "186", "chunk": "n the trust that organizations have in the information flow enforcement \nprocess. The binding techniques affect the number and degree of additional reviews required by \norganizations. The content or assigned values of attribu tes can directly affect the ability of \nindividuals to access organizational information.  \nOrganizations can define the types of attributes needed for systems to support missions or \nbusiness functions. There are many values that can be assigned to a security  attribute. By \nspecifying the permitted attribute ranges and values,  organizations  ensure that attribute values \nare meaningful and relevant. Labeling refers to the association of attributes with the subjects \nand objects  represented by the internal data str uctures within systems. This facilitates system -\nbased enforcement of information security and privacy policies. Labels include  classification of \ninformation in accordance with legal and compliance requirements  (e.g., top secret, secret, \nconfidential, contr olled unclassified) , information impact level; high value asset information , \naccess authorizations , nationality ; data life cycle protection (i.e., encryption and data expiration) , \npersonally identifiable information processing permissions,  including individual consent to \nperson", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1123{"doi": "NIST.SP.800-53r5", "chunk-id": "187", "chunk": "ally identifiable information processing , and contractor affiliation. A related term to \nlabeling is marking. Marking refers to the association of attributes with objects in a human -\nreadable form  and displayed on system  media . Marking  enables manual, procedural, or process -\nbased enforcement of information security and privacy policies.  Security and privacy labels may \nhave the same value as media markings (e.g., top secret , secret, confidential ). See MP-3\n (Media  \nMarking).NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 46 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n Related Controls :  AC-3, AC-4, AC-6, AC-21, AC-25, AU-2, AU-10, MP-3, PE-22, PT-2, PT-3, PT-4, \nSC-11, SC-16, SI-12, SI-18. \nControl Enhancements :  \n(1) SECURITY AND PRIVACY ATTRIBUTES | DYNAMIC ATTRIBUTE ASSOCIATION  \nDynamically associate security and privacy attributes with [ Assignment: organization-\ndefined subjects and objects] in ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1124{"doi": "NIST.SP.800-53r5", "chunk-id": "188", "chunk": "accordance with  the following  security and privacy policies  \nas information is created and combined : [Assignment: organization- defined security and \nprivacy policies ]. \nDiscussion :  Dynamic association of attributes is appropriate whenever the security or \nprivacy characteristics of information change over time. Attributes may change  due to \ninformation aggregation issues (i.e., characteristics of individual data  elements a re different \nfrom  the combined elements) , changes in individual access authorizations (i.e., privileges) , \nchanges in the security category of information , or changes in security or privacy policies.  \nAttributes may also change situationally.  \nRelated Controls :  None.  \n(2) SECURITY AND PRIVACY ATTRIBUTES | ATTRIBUTE VALUE CHANGES BY AUTHORIZED INDIVIDUALS   \nProvide authorized individuals (or processes acting on behalf of individuals) the capability \nto define or change the value of associated security and privacy attributes.  \nDiscussion :  The content or assigned values of attributes can directly affect the ability of \nindividuals to access organizational information. Therefor e, it is important for systems to be \nable to limit the ability to create or modify attributes to authorized individuals.  \nRelated Controls :  None.  \n(3) SECURITY A", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1125{"doi": "NIST.SP.800-53r5", "chunk-id": "189", "chunk": "ND PRIVACY ATTRIBUTES | MAINTENANCE OF ATTRIBUTE ASSOCIATIONS BY SYSTEM   \nMaintain the association and integrity of [ Assignment: organization- defined security and \nprivacy attributes] to [ Assignment: organization- defined subjects and objects ]. \nDiscussion :  Maintaining the association and integrity of security and privacy attributes to \nsubjects and objects with sufficient assurance helps to ensure that the attribute associations \ncan be used as the basis of automated policy actions. The integrity of specific i tems, such as \nsecurity configuration files, may be maintained through the use of an integrity monitoring mechanism that detects anomalies and changes that deviate from \u201cknown good\u201d baselines. \nAutomated policy actions include  retention date expirations, acc ess control decisions, \ninformation flow control decisions , and information disclosure decisions.  \nRelated Controls :  None.  \n(4) SECURITY AND PRIVACY ATTRIBUTES | ASSOCIATION OF ATTRIBUTES BY AUTHORIZED INDIVIDUALS   \nProvide the capability to associate [ Assignment: organization- defined security and privacy \nattributes] with [ Assignment: organization- defined subjects and objects ] by authorized \nindividuals (or processes acting on behalf of individuals).  \nDiscussion :  Systems,  in gener al, provide th", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1126{"doi": "NIST.SP.800-53r5", "chunk-id": "190", "chunk": "e capability for privileged users to assign security \nand privacy attributes to system -defined subjects (e.g., users) and objects (e.g., directories, \nfiles, and ports). Some systems provide additional capability for general users to assign \nsecurity and privacy attributes to additional objects (e.g., files, emails). The association of \nattributes by authorized individuals is described in the design documentation. The support \nprovided by systems can include  prompting users to select security and privacy attributes to \nbe associated with information objects , employing automated mechanisms to categorize \ninformation with attributes based on defined policies , or ensuring that the combination of \nthe security or privacy attributes selected i s valid. Organizations consider the creation, \ndeletion, or modification of attributes when defining auditable events.NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 47 \nThis publication is available free of charge from: https", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1127{"doi": "NIST.SP.800-53r5", "chunk-id": "191", "chunk": "://doi.org/10.6028/NIST.SP.800 -53r5 \n Related Controls :  None.  \n(5) SECURITY AND PRIVACY ATTRIBUTES | ATTRIBUTE DISPLAYS ON OBJECTS TO BE OUTPUT   \nDisplay security and privacy attributes in human- readable form on each object that the \nsystem transmits to output devices to identify [ Assignment: organization -defined  special \ndissemination, handling, or distribution instructions ] using [ Assignment: organi zation-\ndefined  human- readable, standard naming conventions ]. \nDiscussion :  System outputs include  printed pages, screens, or equivalent  items. System \noutput devices include  printers, notebook computers, video displays, smart  phones, and \ntablets . To mitigate the risk of unauthorized exposure of information  (e.g. , shoulder surfing) , \nthe outputs display full attribute values when unmasked by the subscriber.  \nRelated Controls :  None. \n(6) SECURITY AND PRIVACY ATTRIBUTES | MAINTENANCE OF ATTRIBUTE ASSOCIATION  \nRequire personnel to associate and  maintain the association of [ Assignment: organization-\ndefined security and privacy attributes ] with [ Assignment: organization- defined subjects \nand object s] in accordance with [ Assignment: organization- defined security and privacy \npolicies ]. \nDiscussion :  Maintaining attribute association  requires individ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1128{"doi": "NIST.SP.800-53r5", "chunk-id": "192", "chunk": "ual users (as opposed to the \nsystem) to maintain asso ciations of defined security and privacy attributes with subjects and \nobjects . \nRelated Controls :  None.  \n(7) SECURITY AND PRIVACY ATTRIBUTES | CONSISTENT ATTRIBUTE INTERPRETATION  \nProvide a consistent interpretation of security and privacy attributes transmitted between \ndistributed system components.  \nDiscussion :  To enforce security and privacy policies across multiple system components in \ndistributed systems, organizations provide a consistent interpretation of security and privacy \nattributes employed  in access  enforcement  and flow enforcement decisions. Organizations \ncan establish agreements and processes to help ensure that distributed system components \nimplement attributes with consistent interpretations in au tomated access enforcement and \nflow enforcement actions.  \nRelated Controls :  None.  \n(8) SECURITY AND PRIVACY ATTRIBUTES | ASSOCIATION TECHNIQUES AND TECHNOLOGIES   \nImplement [ Assignment: organization- defined techniques and technologies ] in associating \nsecurity and privacy attributes to information.  \nDiscussion :  The association of security and privacy attributes to information within systems \nis important for conducting automated access enforcement and flow enforcement actions . \nThe asso", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1129{"doi": "NIST.SP.800-53r5", "chunk-id": "193", "chunk": "ciation of such attributes  to information  (i.e., binding) can be accomplished with \ntechnologies and techniques that provid e different levels of assurance. For example, systems \ncan cryptographically bind attributes to information using digital sig natures that support \ncryptographic keys protected by hardware devices (sometimes known as hardware roots of \ntrust).  \nRelated Controls :  SC-12, SC-13. \n(9) SECURITY AND PRIVACY ATTRIBUTES | ATTRIBUTE REASSIGNMENT \u2014 REGRADING MECHANISMS  \nChange  security and privacy attributes associated with information only via regrading \nmechanisms validated using [ Assignment: organization- defined techniques or procedures ]. \nDiscussion :  A regrading mechanism is a trusted process authorized to re -classify and re -label \ndata in accordance with a defined policy exception. Validated regrading mechanisms areNIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 48 \nThis publication is available free of charge from: https://doi.org/10", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1130{"doi": "NIST.SP.800-53r5", "chunk-id": "194", "chunk": ".6028/NIST.SP.800 -53r5 \n used by organizations to p rovide the requisite levels of assurance for attribute reassignment \nactivities. The validation is facilitated by ensuring that regrading mechanisms are single \npurpose and of limited function. Since security and privacy attribute changes  can directly \naffect  policy enforcement actions, implementing  trustworthy regrading mechanisms is \nnecessary to help ensure that such mechanisms perform in a consistent and correct mode of \noperation.  \nRelated Controls :  None.   \n(10) SECURITY AND PRIVACY ATTRIBUTES | ATTRIBUTE CONFIGURATION BY AUTHORIZED INDIVIDUALS   \nProvide authorized individuals the capability to define or change the type and value of security and privacy attributes available for associa tion with subjects and objects.  \nDiscussion :  The content or assigned values of security and privacy attributes can directly \naffect the ability of individuals to access organizational information. Thus , it is important for \nsystems to be able to limit the ab ility to create or modify the type and value of attributes \navailable for association with subjects and objects to authorized individuals only.  \nRelated Controls :  None.  \nReferences :  [OMB A -130], [FIPS 140- 3], [FIPS 186-4], [SP 800- 162], [SP 800- 178]. \nAC-17  REMOTE ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1131{"doi": "NIST.SP.800-53r5", "chunk-id": "195", "chunk": "ACCESS  \nControl : \na. Establish and document usage restrictions, configuration/connection requirements, and implementation guidance for each type of remote access allowed; and  \nb. Authorize each type of remote access to the system prior to allowing such connections.  \nDiscussion :  Remote access is access to organizational systems (or processes acting on behalf of \nusers) that communicat e through external networks such as the Internet. Types of remote access \ninclude  dial-up, broadband, and wireless. Organizations use  encr ypted virtual private networks \n(VPNs) to enhance confidentiality and integrity for  remote connections. The use of encrypted \nVPNs provides sufficient assurance to the organization that it can effectively treat such \nconnections as internal networks if the cr yptographic mechanisms used are implemented in \naccordance with applicable laws, e xecutive orders, directives, regulations, policies, standards, \nand guidelines. Still, VPN connections traverse external networks, and the encrypted VPN does \nnot enhance the av ailability of remote connections. VPNs with encrypted tunnels can also affect \nthe ability to adequately monitor network communications traffic for malicious code. Remote access controls apply to systems other than public web servers or systems", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1132{"doi": "NIST.SP.800-53r5", "chunk-id": "196", "chunk": " designed for  public \naccess. \nAuthorization of each remote access type  addresses authorization prior to allowing \nremote access without specifying the specific formats for such authorization. While organizations \nmay use information exchange and system connection security  agreements to manage  remote \naccess connections  to other systems , such agreements are addressed as part of CA -3. Enforcing \naccess restrictions for remote access  is addressed via AC-3. \nRelated Controls :  AC-2, AC-3, AC-4, AC-18, AC-19, AC-20, CA-3, CM-10, IA-2, IA-3, IA-8, MA-4, PE-\n17, PL-2, PL-4, SC-10, SC-12, SC-13, SI-4. \nControl Enhancements : \n(1) REMOTE ACCESS | MONITOR ING AND CONTROL   \nEmploy automated mechanisms to monitor and control remote access methods.  \nDiscussion :  Monitoring and control of remote access methods allows organizations to \ndetect attacks and help ensure compliance with remote access policies by auditing the \nconnection activities of remote users on a variety of system components , including servers,NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n____________________________", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1133{"doi": "NIST.SP.800-53r5", "chunk-id": "197", "chunk": "_____________________________________________________________________  \nCHAPTER THREE    PAGE 49 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n notebook computers, workstations, smart phones, and tablets.  Audit logging for remote \naccess is enforced by AU-2. Audit events are defined in AU -2a. \nRelated C ontrols :  AU-2, AU-6, AU-12, AU-14. \n(2) REMOTE ACCESS | PROTECTION OF CONFIDENTIALITY AND INTEGRITY USING ENCRYPTION   \nImplement cryptographic mechanisms to protect the confidentiality and integrity of \nremote access sessions.  \nDiscussion :  Virtual private networks can be used to protect the confidentiality and integrity \nof remote access sessions. Transport Layer Security (TLS) is an example of a cryptographic \nprotocol that provides end -to-end communications security over networks and is used  for \nInternet communications and online transactions.  \nRelated Controls :  SC-8, SC-12, SC-13. \n(3) REMOTE ACCESS | MANAGED ACCESS CONTROL POINTS   \nRoute remote accesses through authorized and managed network access control points.  \nDiscussion :  Organizations consider the Trusted Internet Connections (TIC) initiative [DHS \nTIC] requirements for external network connections since l imiting the number of access \ncontrol points for ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1134{"doi": "NIST.SP.800-53r5", "chunk-id": "198", "chunk": "remote access reduces attack surface s. \nRelated Controls :  SC-7. \n(4) REMOTE ACCESS | PRIVILEGED COMMANDS AND ACCESS  \n(a) Authorize the execution of privileged commands and access to security -relevant \ninformation  via remote access only in a format that provides assessable  evidence  and \nfor the following needs : [Assignment: organization- defined needs ]; and  \n(b) Document the rationale for remote  access in the security plan for the system.  \nDiscussion :  Remote access to systems represents a significant potential vulnerability that \ncan be exploited by adversaries. As such, restricting the execution of privileged  commands \nand access to security -relevant information via remote access reduces the exposure of the \norganization and the susceptibility to threats by ad versaries to the remote access capability.  \nRelated Controls :  AC-6, SC-12, SC-13. \n(5) REMOTE ACCESS | MONITORING FOR UNAUTHORIZED CONNECTIONS   \n[Withdrawn: Incorporated into SI-4.] \n(6) REMOTE ACCESS | PROTECTION OF  MECHANISM  INFORMATION   \nProtect information about remote access mechanisms from unauthorized use and \ndisclosure.  \nDiscussion :  Remote access to organizational information by non -organizational entities can \nincrease the risk of unauthorized use and disclosure about remote access mech", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1135{"doi": "NIST.SP.800-53r5", "chunk-id": "199", "chunk": "anisms. The \norganization considers including remote access requirements in  the information exchange \nagreements with other organizations , as applicable . Remote access requirements can also be \nincluded in rules of behavior (see PL-4) and access agreements (see PS -6). \nRelated Controls :  AT-2, AT-3, PS-6. \n(7) REMOTE ACCESS | ADDITIONAL PROTECTION FOR SECURITY FUNCTION ACCESS  \n[Withdrawn: Incorporated into AC-3(10) .] \n(8) REMOTE ACCESS | DISABLE NONSECURE NETWORK PROTOCOLS   \n[Withdrawn: Incorporated into CM-7.] \n(9) REMOTE ACCESS | DISCONNECT OR DISABLE ACCESSNIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 50 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n Provide the capability to disconnect or disable remote access to the system within \n[Assignment: organization- defined time period ]. \nDiscussion :  The speed of system disconnect or disablement varies based on the criticality of \nmissions or business functi", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1136{"doi": "NIST.SP.800-53r5", "chunk-id": "200", "chunk": "ons and the need to eliminate immediate or future remote access \nto systems.  \nRelated Controls :  None.  \n(10) REMOTE ACCESS | AUTHENTICATE REMOTE COMMANDS   \nImplement [ Assignment: organization- defined mechanisms ] to authenticate [ Assignment: \norganization- defined remote commands ]. \nDiscussion :  Authenticating remote commands protects against unauthorized commands and \nthe replay of authorized commands. The ability to authenticate remote commands  is \nimportant for remote systems for which  loss, malfunction, misdirection, or exploitation \nwould have immediate or serious consequences, such as  injury , death , property damage,  \nloss of high  value assets , failure of mission or business functions,  or compromise of classified \nor controlled unclassified information. Authentication mechanisms for remote commands \nensure that systems accept and execute commands in the order intended, execute only \nauthorized commands, and reject unauthorized commands. Crypto graphic mechanisms can \nbe used , for example, to authenticate remote commands.  \nRelated Controls :  SC-12, SC-13, SC-23. \nReferences :  [SP 800 -46], [SP 800- 77], [SP 800-113], [SP 800-114], [SP 800-121], [IR 7966 ]. \nAC-18  WIRELESS ACCESS  \nControl : \na. Establish configuration requirements, connection requiremen", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1137{"doi": "NIST.SP.800-53r5", "chunk-id": "201", "chunk": "ts, and implementation guidance for each type of wireless access; and  \nb. Authorize each type of wireless access to the system prior to allowing such connections.  \nDiscussion :  Wireless technologies include  microwave, packet radio (ultra -high frequency or very \nhigh frequency), 802.11x, and Bluetooth. Wireless networks use authentication protocols that \nprovide authenticator  protection and mutual authentication.  \nRelated Controls :  AC-2, AC-3, AC-17, AC-19, CA-9, CM-7, IA-2, IA-3, IA-8, PL-4, SC-40, SC-43, SI-4. \nControl Enhancements : \n(1) WIRELESS ACCESS | AUTHENTICATION AND ENCRYPTION  \nProtect wireless access to the system using authentication of [ Selection (one or more): \nusers; devices ] and encryption.  \nDiscussion :  Wireless networking capabilities represent a significant potential vulnerability \nthat can be exploited by adversaries. To protect systems with wireless access points, strong authentication of users and devices along with strong  encryption can reduce susceptibility to \nthreats by adversaries involving wireless technologies.  \nRelated Controls :  SC-8, SC-12, SC-13. \n(2) WIRELESS ACCESS | MONITORING UNAUTHORIZED CONNECTIONS  \n[Withdrawn: Incorporated into SI-4.] \n(3) WIRELESS ACCESS | DISABLE WIRELESS NETWORKING   \nDisable, when not intended for use,", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1138{"doi": "NIST.SP.800-53r5", "chunk-id": "202", "chunk": " wireless networking capabilities  embedded within \nsystem components prior to issuance and deployment.NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 51 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n Discussion :  Wireless networking capabilities that are embedded within system components \nrepresent a significant potential vulnerability that can be exploited by ad versaries. Disabling \nwireless capabilities when not needed for essential organizational missions or functions can \nreduce susceptibility to threats by adversaries involving wireless technologies.  \nRelated Controls :  None.  \n(4) WIRELESS ACCESS | RESTRICT CONFIGURATIONS BY USERS   \nIdentify and explicitly authorize users allowed to independently configure wireless networking capabilities.  \nDiscussion :  Organizational authorizations to allow selected users to configure wirele ss \nnetworking capabilit ies are enforced , in part, by the access enforcement", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1139{"doi": "NIST.SP.800-53r5", "chunk-id": "203", "chunk": " mechanisms \nemployed within organizational systems.  \nRelated Controls :  SC-7, SC-15. \n(5) WIRELESS ACCESS | ANTENNAS AND TRANSMISSION POWER LEVELS   \nSelect radio antennas and calibrate transmission power levels to reduce the probability \nthat signals from wireless access points can be received outside of organization -controlled \nboundarie s. \nDiscussion :  Actions that may be taken  to limit unauthorized use of wireless communications \noutside of organization -controlled boundaries include  reducing the power of wireless \ntransmissions so that the transmissions are less likely to emit a signal tha t can be captured \noutside of the physical perimeters of the organization , employing measures such as \nemissions security to control wireless emanations,  and using directional or beamforming \nantennas that reduce the likelihood that unintended receivers will be able to intercept \nsignals. Prior to taking such mitigating actions, organizations can conduct periodic wireless \nsurveys to understand the radio freq uency profile of organizational systems as well as other \nsystems that may be operating in the area.  \nRelated Controls :  PE-19. \nReferences :  [SP 8 00-94], [SP 8 00-97]. \nAC-19  ACCESS CONTROL FOR MOBILE DEVICES  \nControl : \na. Establish configuration requirements, connec", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1140{"doi": "NIST.SP.800-53r5", "chunk-id": "204", "chunk": "tion requirements, and implementation \nguidance for organization- controlled mobile devices , to include when such devices are \noutside of controlled areas ; and \nb. Authorize the connection of mobile devices to organizational systems.  \nDiscussion :  A mobile device is a computing device that has a small form factor such that it can \neasily be carried by a single individual; is designed to  operate without a physical connection; \npossesses local, non -removable or removable data storage; and includes a self- contained power \nsource. Mobile device functionality may also include voice communication capabilities, on- board \nsensors that allow the dev ice to capture information, and/or built -in features for synchronizing \nlocal data with remote locations. Examples include  smart phones  and tablets. Mobile devices are \ntypically associated with a single individual. The processing, storage, and transmission capability \nof the mobile device may be comparable to or merely a subset of notebook/desktop systems, \ndepending on the nature and intended purpose of the device.  Protection and control of mobile \ndevices is behavior or policy -based and requires users to take physical action to protect and \ncontrol such devices when outside of controlled areas. Controlled areas are spaces for w", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1141{"doi": "NIST.SP.800-53r5", "chunk-id": "205", "chunk": "hich \norganizations provide physical or procedural controls  to meet the requirements established f or \nprotecting information and systems.NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 52 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n Due to the large variety of mobile devices with different characteristics and capabilities, \norganizational restrictions may vary for the different classes  or types of such devices. Usage \nrestrictions and specific impl ementation guidance for mobile devices include  configuration \nmanagement, device identification and authentication, implementation of mandatory protective \nsoftware, scanning devices for malicious code, updating virus protection software, scanning for \ncritic al software updates and patches, conducting primary operating system (and possibly other \nresident software) integrity checks, and disabling unnecessary hardware.  \nUsage restrictions and authorization to connec", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1142{"doi": "NIST.SP.800-53r5", "chunk-id": "206", "chunk": "t may vary among organizational systems. For \nexample, the organization may authorize the connection of mobile devices to its network and \nimpose a set of usage restrictions,  while a system owner may withhold authorization for mobile \ndevice connection to specific applications or impose additional usage re strictions before allowing \nmobile device connections to a system. Adequate security for mobile devices goes beyond the \nrequirements specified in AC-19. Many safeguards  for mobile devices are reflected in other \ncontrols. AC-20 addresses mobile devices that are not organization -controlled.  \nRelated Controls :  AC-3, AC-4, AC-7, AC-11, AC-17, AC-18, AC-20, CA-9, CM-2, CM-6, IA-2, IA-3, \nMP-2, MP-4, MP-5, MP-7, PL-4, SC-7, SC-34, SC-43, SI-3, SI-4. \nControl Enhancements : \n(1) ACCESS CONTROL FOR MOBILE DEVICES | USE OF WRITABLE AND PORTABLE STORAGE DEVICES  \n[Withdrawn: Incorporated into MP-7.] \n(2) ACCESS CONTROL FOR MOBILE DEVICES | USE OF PERSONALLY OWNED PORTABLE STORAGE DEVICES  \n[Withdrawn: Incorporated into MP-7.] \n(3) ACCESS CONTROL FOR MOBILE DEVICES | USE OF PORTAB LE STORAGE DEVICES WITH NO \nIDENTIFIABLE OWNER  \n[Withdrawn: Incorporated into MP-7.] \n(4) ACCESS CONTROL FOR MOBILE DEVICES | RESTRICTIONS FOR CLASSIFIED INFORMATION  \n(a) Prohibit the use of unclassifi", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1143{"doi": "NIST.SP.800-53r5", "chunk-id": "207", "chunk": "ed mobile devices in facilities containing systems \nprocessing, storing, or transmitting classified information unless specifically permitted \nby the authorizing official; and  \n(b) Enforce the following restrictions on individuals pe rmitted by the authorizing official \nto use unclassified mobile devices in facilities containing systems processing, storing, \nor transmitting classified information:  \n(1) Connection of unclassified mobile devices to classified systems is prohibited;  \n(2) Connection of unclassified mobile devices to unclassified systems requires \napproval from the authorizing official;  \n(3) Use of internal or external modems or wireless interfaces within the unclassified \nmobile devices is prohibited; and  \n(4) Unclassified mobile devices and the information stored on those devices are \nsubject to random reviews and inspections by [ Assignment: organization- defined \nsecurity officials ], and if classified information is found, the incident handling \npolicy is followed.  \n(c) Restrict the connection of classified mobile devices to classified systems in accordance with [ Assignment: organization- defined security policies ]. \nDiscussion :  None.  \nRelated Controls :  CM -8, IR-4. \n(5) ACCESS CONTROL FOR MOBILE DEVICES | FULL DEVICE OR  CONTAINER -BASED ENCRYPTIONN", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1144{"doi": "NIST.SP.800-53r5", "chunk-id": "208", "chunk": "IST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 53 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n Employ [ Selection: full -device encryption; container -based encryption] to protect the \nconfidentiality and integrity of information on [ Assignment: or ganization -defined mobile \ndevices ]. \nDiscussion :  Container -based encryption provides a more fine -grained approach to data and  \ninformation encryption on mobile devices , including  encrypting selected data structures \nsuch as files, records, or fields.  \nRelated Controls :  SC-12,  SC-13, SC-28. \nReferences :  [SP 8 00-114], [SP 800 -124]. \nAC-20  USE OF EXTERNAL SYSTEMS  \nControl : \na. [Selection (one or more): Establish  [Assignment: organization -defined terms and conditions ]; \nIdentify  [Assignment: organization- defined controls asserted to be implemented on external \nsystems]], consistent with the trust relationships established with other organizations \n", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1145{"doi": "NIST.SP.800-53r5", "chunk-id": "209", "chunk": "owning, operating, and/or maintaining external systems, allowing authorized individuals to:  \n1. Access the system from external systems; and  \n2. Process, store, or transmit organization -controlled information using external systems; \nor \nb. Prohibit the use of [ Assignment: organizationally -defined types of external systems ]. \nDiscussion :  External systems are systems that are used by but not part of organizational systems , \nand for which the organization has no direct control over the implementation of required \ncontrols or the assessment of control effectiveness. External systems include  personally owned \nsystems, components, or devices; privately owned computing and communications devices in commercial or public facilities; systems owned or controlled by nonfederal organizations; \nsystems managed by contractors; and federal information systems that are not owned by, \noperated by, or under the direct supervision or authority of the organization. External systems \nalso include systems owned or operated by other components within the same organization and \nsystems within the organization with different authorization boundaries . Organizations have the \noption to prohibit the use of any  type of external system or prohibit the use of specified types of \nexternal systems, (", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1146{"doi": "NIST.SP.800-53r5", "chunk-id": "210", "chunk": "e. g., prohibit  the use of any external system that is not organizationally  owned \nor prohibit the use of personally -owned systems).  \nFor some external systems (i.e., systems operated by other organizations ), the trust relationships \nthat have been established between those organizations and the originating organization may be such that no explicit terms and conditions are required. Syste ms within these organizations may \nnot be considered external. These situations occur when, for example, there are pre- existing \ninformation exchange  agreements (either implicit or explicit) established between organizations \nor components  or when such agreem ents are specified by applicable laws, e xecutive orders, \ndirectives, regulations, policies, or standards . Authorized individuals include  organizational \npersonnel, contractors, or other individuals with authorized access to organizational systems and \nover w hich organizations have the authority to impose specific rules of behavior regarding  \nsystem access. R estrictions that organizations impose on authorized individuals need not be \nuniform, as th e restrictions may vary depending on trust relationships between organizations. \nTherefore, organizations may choose to impose different security restrictions on contractors \nthan o", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1147{"doi": "NIST.SP.800-53r5", "chunk-id": "211", "chunk": "n state, local, or tribal governments.  \nExternal systems used to access public interfaces to organizational systems are outside the scope \nof AC-20\n. Organizations establish specific terms and conditions for the use of external systems in \naccordance with organizational security policies and procedures. At a minimum , terms and \nconditions address the specific types of applic ations that can be accessed on organizationalNIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 54 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n systems from external systems and the highest security category of information that can be \nprocessed, stored, or transmitted on external systems. If the terms and conditions with the \nowners of the external syst ems cannot be established, organizations may impose restrictions on \norganizational personnel using those external systems.  \nRelated Controls :  AC-2, AC-3, AC-17, AC-19, CA-3, PL-2, PL-4, SA-9", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1148{"doi": "NIST.SP.800-53r5", "chunk-id": "212", "chunk": ", SC-7. \nControl Enhancements : \n(1) USE OF EXTERNAL SYSTEMS | LIMITS ON AUTHORIZED USE   \nPermit authorized individuals to use an external system to access the system or to process, \nstore, or transmit organization -controlled information only after:  \n(a) Verification of the implementation of controls on the external system as specified in \nthe organization\u2019s security and privacy policies and security and privacy plans; or  \n(b) Retention of approved system connection or processing agreements with the \norganizational entity hosting th e external system.  \nDiscussion :  Limiting authorized use recognizes circumstances where individuals using \nexternal systems may need to access organizational systems. O rganizations need assurance  \nthat the external systems contain the necessary controls so as  not to compromise, damage, \nor otherwise harm organizational systems. Verification that the required controls have been \nimplemented can be achieved  by external, independent assessments, attestations, or other \nmeans, depending on the confidence level requir ed by organizations.  \nRelated Controls :  CA-2. \n(2) USE OF EXTERNAL SYSTEMS | PORTABLE STORAGE DEVICES \u2014 RESTRICTED USE  \nRestrict the use of organization -controlled portable storage devices by authorized \nindividuals on external", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1149{"doi": "NIST.SP.800-53r5", "chunk-id": "213", "chunk": " systems using  [Assignment: organization- defined restrictions ]. \nDiscussion :  Limits on the use of organization -controlled portable storage devices in external \nsystems include  restrictions on how the devices may be used and under what conditions the \ndevices may be used.  \nRelated Controls :  MP -7, SC-41. \n(3) USE OF EXTERNAL SYSTEMS | NON-ORGANIZATIONALLY OWNED SYSTEMS  \u2014 RESTRICTED USE   \nRestrict the use of non -organizationally owned systems or system components to process, \nstore, or transmit organizational information using  [Assignment: organization- defined \nrestrictions] .  \nDiscussion :  Non -organizationally owned systems or system components include  systems or \nsystem components owned by other organizations as well as personally owned devices. \nThere are potential risks to using non -organizationally owned systems or components. In \nsome cases, the risk is sufficiently high as to prohibit such use  (see AC-20 b.). In other cases, \nthe use of such systems or system components may be allowed but restricted in some way. \nRestrictions include  requiring the implementation of approved controls prior to authorizing \nthe connection of non -organizationally owned systems and components; limiting access to \ntypes of information, services, or applications; using virtua", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1150{"doi": "NIST.SP.800-53r5", "chunk-id": "214", "chunk": "lization techniques to limit \nprocessing and storage activities to servers or system components provisioned by the \norganization; and  agreeing to the terms and conditions for usage. Organizations consult with \nthe Office of the General Counsel regarding legal issues associated with using personally owned devices, including requirements for conducting forensic analyses during \ninvestigatio ns after an incident.  \nRelated Controls :  None.  \n(4) USE OF EXTERNAL SYSTEMS | NETWORK ACCESSIBLE STORAGE DEVICES \u2014 PROHIBITED USENIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 55 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n Prohibit the use of [ Assignment: organization- defined network accessible storage devices ] \nin external systems.  \nDiscussion :  Network- accessible storage devices in external systems include  online storage \ndevices in public, hybrid, or community cloud- based systems.  \nRelated Controls :  None.  \n(5", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1151{"doi": "NIST.SP.800-53r5", "chunk-id": "215", "chunk": ") USE OF EXTERNAL SYSTEMS | PORTABLE STORAGE DEVICES \u2014 PROHIBITED USE  \nProhibit the use of organization -controlled portable storage devices by authorized \nindividuals on external systems.  \nDiscussion :  Limits on the use of organization -controlled portable storage devices in external \nsystems include a complete prohibition of the use of such devices.  Prohibiting such use is \nenforced using technical methods and/or nontechnical (i.e., process -based) methods.  \nRelated Controls :  MP -7, PL-4, PS-6, SC-41. \nReferences :  [FIPS 199] , [SP 800- 171], [SP 800- 172]. \nAC-21  INFORMATION SHARING  \nControl : \na. Enable  authorized users to determine whether access authorizations assigned to a sharing \npartner match the information\u2019s access and use restrictions for [ Assignment: organization -\ndefined information sharing circumstances where user discretion is required]; and  \nb. Employ [Assignment: organization- defined automated mechanisms or manual processes ] to \nassist users in making information sharing and collaboration decisions.  \nDiscussion :  Information sharing applies to information that may be restricted in some manner \nbased  on some formal or administrative determination. Examples of such information include, \ncontract -sensitive information, classified information re", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1152{"doi": "NIST.SP.800-53r5", "chunk-id": "216", "chunk": "lated to special access programs or \ncompartments, privileged  information, proprietary information, and personally identifiable \ninformation. Security and privacy risk assessments as well as applicable laws, regulations, and \npolicies can provide useful inputs to these determinations. Depending on the circumstances, \nsharing partners may be defined at the i ndividual, group, or organizational level. Information \nmay be defined by content, type, security category, or special access program  or compartment.  \nAccess restrictions may include  non-disclosure agreements (NDA).  Information flow techniques \nand security a ttributes may be used to provide automated assistance to users making sharing \nand collaboration decisions.  \nRelated Controls :  AC-3, AC-4, AC-16, PT-2, PT-7, RA-3, SC-15.  \n Control Enhancements :  \n(1) INFORMATION SHARING | AUTOMATED DECISION SUPPORT   \nEmploy [ Assignment: organization- defined automated mechanisms]  to enforce  \ninformation -sharing decisions by authorized users based on access authorizations of \nsharing partners and access restrictions on information to be shared.  \nDiscussion :  Automated mechanisms are used to enforce information sharing decisions . \nRelated Controls :  None.  \n(2) INFORMATION SHARING | INFORMATION SEARCH AND RETRIEVAL   \nIm", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1153{"doi": "NIST.SP.800-53r5", "chunk-id": "217", "chunk": "plement information search and retrieval services that enforce [ Assignment: \norganization- defined information sharing restrictions ]. \nDiscussion :  Information search and retrieval services identify information system resources \nrelevant to an information need .NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 56 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n Related Controls :  None.  \nReferences :  [OMB A -130], [SP 800-150], [IR 8062 ].  \nAC-22  PUBLICLY ACCESSIBLE CONTENT  \nControl : \na. Designate individuals authorized to make  information publicly accessible;  \nb. Train authorized individuals to ensure that publicly accessible information does not contain \nnonpublic information;  \nc. Review the proposed content of information prior to posting onto the publicly accessible \nsystem to ensure that nonpublic information is not included; and  \nd. Review the content on the publicly accessible system for nonpublic inf", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1154{"doi": "NIST.SP.800-53r5", "chunk-id": "218", "chunk": "ormation [Assignment: organization- defined frequency ] and remove such information, if discovered.  \nDiscussion :  In accordance with applicable laws, e xecutive orders, directives, policies, regulations, \nstandards, and guidelines , the public is not authorized to have access to nonpublic information , \nincluding information protected under the [PRIVACT ] and proprietary information. Publicly \naccessible content addresses systems that are controlled by the organizatio n and accessible to \nthe public, typically without identification or authentication. Posting information on non -\norganization al systems (e.g., non- organizational public websites, forums, and social media)  is \ncovered by organizational policy.  While organizations may have individuals who are responsible \nfor developing and implementing policies about the information that can be made publicly \naccessible, publicly accessible content  addresses the management of the individuals who make \nsuch information publicly accessible.  \nRelated Control s:  AC-3, AT-2, AT-3, AU-13. \nControl Enhancements :  None.  \nReferences :  [PRIVACT ]. \nAC-23  DATA MINING PROTECTION  \nControl :  Employ [ Assignment: organization -defined data mining prevention and detection \ntechniques ] for [ Assignment: organization- defined data sto", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1155{"doi": "NIST.SP.800-53r5", "chunk-id": "219", "chunk": "rage objects ] to detect and protect \nagainst unauthorized data mining.  \nDiscussion :  Data mining is an analytical process that attempts to find correlations or patterns in \nlarge data sets for the purpose of data or knowledge discovery. Data storage objects include  \ndatabase records and database fields.  Sensitive information can be extracted from data mining  \noperations . When information is personally identifiable information, it may lead to unanticipated \nrevelations about individuals and give rise to privacy risks. Prior to performing data mining \nactivit ies, organizations determine whether such activities are authorized. Organizations may be \nsubject to applicable laws, executive orders, directives, regulations, or policies that address data \nmining requirements. Organizational personnel consult with the se nior agency official for privacy \nand legal counsel regarding such requirements.  \nData mining prevention and detection techniques include  limiting the number and frequency of \ndatabase queries to increase the work factor needed to determine the contents  of databases , \nlimiting types of responses provided to database queries,  applying differential privacy techniques \nor homomorphic encryption , and notifying personnel when atypical database queries or accesses \n", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1156{"doi": "NIST.SP.800-53r5", "chunk-id": "220", "chunk": "occur. Data mining protection focuses on protect ing information from data mining while such \ninformation resides in organizational data stores. In contrast, AU -13 focuses on monitoring for \norganizational information that may have been mined or otherwise obtained from data storesNIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 57 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n and is available as open -source information residing on external sites, such as social networking \nor social media websites.  \n[EO 13587 ] requires the establishment of an insider threat program for deterring, detecting, and \nmitigating insider threats, including the safeguarding of sensitive information from exploitation, \ncompromise, or othe r unauthorized disclosure.  Data mining protection requires organizations to \nidentify appropriate techniques to prevent and detect unnecessary or unauthorized data mining. Data mining  can be used by an", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1157{"doi": "NIST.SP.800-53r5", "chunk-id": "221", "chunk": " insider to collect organizational information for the purpose  of \nexfiltration.  \nRelated Controls :  PM -12, PT-2. \nControl Enhancements :  None.  \nReferences :  [EO 13587 ]. \nAC-24  ACCESS CONTROL DECISIONS  \nControl :  [Selection: Establish procedures ; Implement mechanisms ] to ensure [ Assignment: \norganization- defined access control decisions ] are applied to each access request prior to access \nenforcement.  \nDiscussion :  Access control decisions (also known as authorization decisions) occur when \nauthorization information is applied to specific accesses. In contrast, access enforcement occurs \nwhen systems enforce access control decisions.  While it is common to have access control \ndecisions and access enforcement implemented by the same entity, it is not required,  and it is \nnot always an optimal implementation choice. For some architectures and distributed systems, \ndifferent entit ies may make  access control decisions and enforce  access.  \nRelated Controls :  AC-2, AC-3. \n Control Enhancements : \n(1) ACCESS CONTROL DECISIONS | TRANSMIT ACCESS AUTHORIZATION INFORMATION   \nTransmit [ Assignment: organization- defined access authorization information] using \n[Assignment: organization- defined controls ] to [ Assignment: organization- defined \nsystems] that enforce", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1158{"doi": "NIST.SP.800-53r5", "chunk-id": "222", "chunk": " access control decisions.  \nDiscussion :  Authorization processes and access control decisions may occur in separate \nparts of systems  or in separate systems. In such instances, authorization information is \ntransmitted securely (e.g., using cryptographic mechanisms) so that timely acce ss control \ndecisions can be enforced at the appropriate locations. To support the access control decisions, it may be necessary to transmit as part of the access authorization information \nsupporting security and privacy attributes. This is because  in distributed systems, there are \nvarious access control decisions that need to be made , and different entities make these \ndecisions in a serial fashion, each requiring those attributes to make the decisions. \nProtecting access authorization information ensures that such information cannot be \naltered, spoofed, or compromised during transmission.  \nRelated Controls :  AU-10. \n(2) ACCESS CONTROL DECISIONS | NO USER OR PROCESS IDENTITY  \nEnforce access control decisions based on [ Assignment: organization- defined security or \nprivacy attributes] that do not include the identity of the user or process acting on behalf \nof the user.  \nDiscussion :  In certain situations, it is important that access control decisions can be made \nwithout information ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1159{"doi": "NIST.SP.800-53r5", "chunk-id": "223", "chunk": "regarding the identity of the users issuing the requests. These are \ngenerally instances where preserving individual privacy is of paramount importance. I n otherNIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 58 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n situations, user identification information is simply not needed for access control decisions,  \nand especially in the case of distributed systems, transmitting such information with the \nneeded degree of assurance may be very expensive or difficult t o accomplish.  MAC, RBAC, \nABAC, and label -based control policies, for example, might not include user identity as an \nattribute.  \nRelated Controls :  None.  \nReferences :  [SP 800 -162], [SP 8 00-178]. \nAC-25  REFERENCE MONITOR   \n Control :  Implement a reference monitor for [ Assignment: organization- defined access control \npolicies ] that is tamperproof, always invoked, and small enough to be subject to anal", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1160{"doi": "NIST.SP.800-53r5", "chunk-id": "224", "chunk": "ysis and \ntesting, the completeness of which can be assured.  \nDiscussion :  A reference monitor is a set of design requirements on a reference validation \nmechanism that , as a key component of an operating system, enforces an access control policy \nover all subjects and objects. A reference validation mechanism is always invoked , tamper -proof,  \nand small enough to be subject to analysis and tests, the completeness of which can be assured \n(i.e., verifiable). Information is represented internally within systems using abstractions known as \ndata structures. Internal data structures can represent different types of entities, both active and \npassive. Active entities, also known as subjects, are associated with individuals, devices, or \nprocesses acting on behalf of individuals. Passive entities, also known as objects, are associated \nwith data structures , such as records, buffers, communications ports, tables, files,  and inter -\nprocess pipes. Reference monitors enforce access control policies  that restrict access to obje cts \nbased on the identity of subjects or groups to which the subjects belong.  The system enforces \nthe access control policy based on the rule set established by the policy. The tamper -proof \nproperty of the reference monitor prevents determined adversar", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1161{"doi": "NIST.SP.800-53r5", "chunk-id": "225", "chunk": "ies from compromising the \nfunctioning of the reference validation mechanism. The always invoked property prevents \nadversaries from bypassing the mechanism and violating the security policy. The smallness \nproperty helps to ensure completeness in the analysis and testing of the mechanism to detect \nany weaknesses or deficiencies (i.e., latent flaws) that would prevent the enforcement of the \nsecurity policy.  \nRelated Controls :  AC-3, AC-16, SA-8, SA-17, SC-3, SC-11, SC-39, SI-13. \nControl Enhancements :  None.  \nReferences :  None.NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 59 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n 3.2   AWARENESS  AND  TRAINING  \nQuick link to Awareness and Training Summary Table  \n \nAT-1 POLICY AND PROCEDURES  \nControl : \na. Develop, document, and disseminate to [ Assignment: organization- defined personnel or \nroles ]: \n1. [Selection (one or more): Organization- level; Mission/busin", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1162{"doi": "NIST.SP.800-53r5", "chunk-id": "226", "chunk": "ess process- level; System -\nlevel ] awareness and training policy that:  \n(a) Addresses purpose, scope, roles, responsibilities, management commitment, \ncoordination  among organizational entities, and compliance; and  \n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, \nstandards, and guidelines; and \n2. Procedures to facilitate the implementation of the awareness and training policy and  \nthe associated awareness and training controls;  \nb. Designate an [ Assignment: organization- defined official ] to manage the development, \ndocumentation, and dissemination of the awareness and training policy and procedures; and  \nc. Review and update the current awa reness and training:  \n1. Policy [Assignment: organization- defined frequency ] and following [Assignment: \norganization- defined events ]; and \n2. Procedures [ Assignment: organization- defined frequency ] and following [ Assignment: \norganization- defined events ]. \nDiscussion :  Awareness and training policy and procedures address the controls in the AT family \nthat are implemented within systems and organizations. The risk management strategy is an \nimportant factor in establishing such policies and procedures. Policies and procedures contribute \nto security and privacy assurance. T", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1163{"doi": "NIST.SP.800-53r5", "chunk-id": "227", "chunk": "herefore, it is important that security a nd privacy programs \ncollaborate on the development  of awareness and training policy and procedures . Security and \nprivacy program policies and procedures at the organization level are preferable, in general, and \nmay obviate the need for mission - or system -specific policies and procedures. The policy can be \nincluded as part of the general security and privacy policy or be represented by multiple policies \nthat reflect the complex nature of organizations. Procedures can be established for security and \nprivacy programs , for mission  or business processes,  and for systems, if needed. Procedures \ndescribe how the policies or controls are implemented and can be directed at the individual or \nrole that is the object of the procedure. Procedures can be documented in system security and \nprivacy plans or in one or more separate documents. Events that may precipitate an update to \nawareness and training policy and procedures include  assessment or audit findings, security  \nincidents  or breaches , or changes in applicable  laws, executive orders, directives, regulations, \npolicies, standards, and guidelines . Simply r estating controls does not constitute an \norganizational policy or procedure . \nRelated Controls :  PM -9, PS-8, SI-12. \n", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1164{"doi": "NIST.SP.800-53r5", "chunk-id": "228", "chunk": "Control Enhancements :  None.  \nReferences :  [OMB A -130], [SP 800- 12], [ SP 800- 30], [SP 800- 39], [ SP 800- 50], [SP 8 00-100].NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 60 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n AT-2 LITERACY  TRAINING  AND AWARENESS  \nControl : \na. Provide security and privacy literacy  training to system users (including managers, senior \nexecutives, and contractors):  \n1. As part of initial training for new users  and [ Assignment: organization- defined \nfrequency ] thereafter; and  \n2. When  required by system changes  or following [Assignment: organization- defined \nevents ]; \nb. Employ the following techniques to increase the security and privacy awareness of system \nusers [Assignment: organization -defined awareness techniques ]; \nc. Update literacy training  and awareness content  [Assignment: organization- defined \nfrequency ] and following [ Assignment: organization -defin", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1165{"doi": "NIST.SP.800-53r5", "chunk-id": "229", "chunk": "ed events ]; and  \nd. Incorporate lessons learned from internal or external security incidents or breaches  into \nliteracy  training  and awareness techniques . \nDiscussion :  Organizations provide basic  and advanced levels of literacy  training  to system users,  \nincluding measures to tes t the knowledge level of users. Organizations determine the content of \nliteracy  training and awareness based on specific organizational requirements , the systems to \nwhich personnel have authorized access , and work environments (e.g., telework) . The content \nincludes an understanding of the need for security and privacy as well as actions by users to \nmaintain security and personal privacy and to respond to suspected incidents. The content \naddresses the need for operations security  and the handling of personally identifiable \ninformation . \nAwareness techniques include  displaying posters, offering supplies inscribed with security and \nprivacy reminders, displaying logon screen messages, generating email advisories or notices from \norgani zational officials, and conducting awareness events. Literacy  training after  the initial \ntraining described in AT-2a.1 is conducted at a minimum frequency consistent with applicable \nlaws, directives, regulations, and policies. Subsequent literacy ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1166{"doi": "NIST.SP.800-53r5", "chunk-id": "230", "chunk": " training may be satisfied by one or \nmore short ad hoc sessions and include  topical information on recent attack schemes , changes to \norganizational security and privacy policies , revised security and privacy expectations , or a subset \nof topics from the initial training.  Updating literacy  training and awareness content on a regular \nbasis helps to ensure that the content remains relevant. Events that may precipitate an update to \nliteracy training and awareness content include, but are not limited to, assessment or audit \nfindings, security incidents  or breaches , or changes in applicable laws, executive orders, \ndirectives, regulations, policies, standards, and guidelines . \nRelated Contr ols:  AC-3, AC-17, AC-22, AT-3, AT-4, CP-3, IA-4, IR-2, IR-7, IR-9, PL-4, PM-13, PM-21, \nPS-7, PT-2, SA-8, SA-16. \nControl Enhancements : \n(1) LITERACY TRAINING  AND AWARENESS | PRACTICAL EXERCISES   \nProvide  practical exercises in literacy  training that simulate events and incidents.  \nDiscussion :  Practical exercises include  no-notice social engineering attempts to collect \ninformation, gain unauthorized access, or simulate the adverse impact of opening malicious \nemail attachments or invoking, via spear phishing attacks, malicious web links.  \nRelated Controls :  CA-2, CA-7, CP-", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1167{"doi": "NIST.SP.800-53r5", "chunk-id": "231", "chunk": "4, IR-3. \n(2) LITERACY TRAINING  AND AWARENESS | INSIDER THREAT   \nProvide  literacy  training on recognizing and reporting potential indicators of insider threat.NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 61 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n Discussion :  Potential indicators and possible precursors of insider threat can include  \nbehaviors such as inordinate, long -term job dissatisfaction ; attempts to gain access to \ninformation not required for job performance ; unexplained access to financial resources ; \nbullying or harassment of fellow employees ; workplace violence ; and other serious violations \nof policies, procedures, directives, regulations, rules, or practices. Literacy  training includes  \nhow to communicate the concerns of employees and management regarding potential \nindicators of insider threat through  channels established by the organization and in \naccordance with established po", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1168{"doi": "NIST.SP.800-53r5", "chunk-id": "232", "chunk": "licies and pr ocedures. Organizations may consider tailoring \ninsider threat awareness topics to the role . For example, training for managers may be \nfocused on changes in the behavior of team  members, while training for employees may be \nfocused on more general observations.  \nRelated Controls :  PM -12. \n(3) LITERACY TRAINING  AND AWARENESS | SOCIAL ENGINEERING AND MINING  \nProvide  literacy  training  on recognizing and reporting potential and actual instances of \nsocial engineering and social mining.  \nDiscussion :  Social engineering is an attempt to trick an individual  into revealing information \nor taking an action that can be used to breach , compromise , or otherwise adversely impact  a \nsystem. Social engineering include s phishing, pretexting, impersonation, baiting, quid pro \nquo, thread -jacking, social media exploitation, and tailgating . Social mining is an attempt  to \ngather information about the organization that may be used to support future attacks. \nLiteracy  training includes information on how to communicate the concerns of employees \nand management regarding potential and actual instances of social engineering and data \nmining through organizational channels based on established policies and procedures. \nRelated Controls :  None.  \n(4) LITERACY TRAINING", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1169{"doi": "NIST.SP.800-53r5", "chunk-id": "233", "chunk": "  AND AWARENESS | SUSPICIOUS COMMUNICATIONS AND ANOMALOUS SYSTEM \nBEHAVIOR  \nProvide literacy  training on recogniz ing suspicious communications and anomalous \nbehavior in organizational systems  using [ Assignment: organization- defined indicators of \nmalicious code ]. \nDiscussion :  A well -trained workforce provides another organizational control  that can be \nemployed as part of a defense -in-depth strategy to protect against malicious code coming \ninto organizations via email or the web applications. Personnel are trained to look for indications of potentially suspicious email (e.g., receiving an unexpected email, receiving an \nema il containing strange or poor grammar, or receiving an email from an unfamiliar sender \nthat appears to be from a known sponsor or contractor ). Personnel are also trained on how \nto respond to suspicious email or web communications. For this process to work effectively, personnel are trained and made aware of what constitutes suspicious communications. \nTraining personnel on how to recognize anoma lous behaviors in systems can provide \norganizations with early warning for the presence of malicious code. Recognition of \nanomalous behavior by organizational personnel can supplement malicious code detection and protection tools and systems employed", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1170{"doi": "NIST.SP.800-53r5", "chunk-id": "234", "chunk": " by or ganizations.  \nRelated Controls :  None.  \n(5) LITERACY TRAINING  AND AWARENESS | ADVANCED PERSISTENT THREAT   \nProvide  literacy  training on the advanced persistent threat.  \nDiscussion :  An effective way to detect advanced persistent threats (APT)  and to preclude \nsuccess ful attacks  is to provide specific literacy  training for individuals. Threat literacy \ntraining include s educating individuals on the various ways that APTs can infiltrate the \norganization  (e.g., through websites, emails, advertisement pop-ups, articles, and socialNIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 62 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n engineering ). Effective training include s techniques for recognizing suspicious emails, use of \nremovable systems in non -secure settings, and the potential targeting of individuals at \nhome.  \nRelated Controls :  None.  \n(6) LITERACY TRAINING  AND AWARENESS | CYBER THREAT E", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1171{"doi": "NIST.SP.800-53r5", "chunk-id": "235", "chunk": "NVIRONMENT   \n(a) Provide literacy  training on the cyber threat environment; and  \n(b) Reflect  current cyber threat information in system operations.  \nDiscussion :  Since threats continue to change over time, threat literacy  training by the \norganization is dynamic. Moreover, threat literacy  training is not performed in isolation from \nthe system operations that support organizational mission and business functions.  \nRelated Controls :  RA -3. \nReferences :  [OMB A -130], [SP 800-50], [ SP 800- 160-2], [SP 800 -181], [ODNI CTF ]. \nAT-3 ROLE-BASED TRAINING  \nControl : \na. Provide role -based security and privacy training to personnel with  the following roles and \nresponsibilities:  [Assignment: organization- defined roles and responsibilities ]: \n1. Before authorizing access to the system, information, or performing assigned duties, \nand [ Assignment: organization- defined frequency] thereafter; and  \n2. When required by system c hanges;  \nb. Update role-based training  content  [Assignment: organization- defined frequency ] and \nfollowing [Assignment: organization- defined events ]; and  \nc. Incorporate lessons learned from internal or external security incidents or breaches  into \nrole-based trainin g. \nDiscussion :  Organizations determine the content of training based o", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1172{"doi": "NIST.SP.800-53r5", "chunk-id": "236", "chunk": "n the assigned roles and \nresponsibilities of individuals as well as the security and privacy requirements of organizations \nand the systems to which personnel have authorized access, including technical training \nspecifically tailored for assigned duties. Roles that may require role -based training include  senior \nleaders or management officials (e.g., head of agency/chief executive officer, chief information \nofficer, senior accountable official for risk management,  senior agency information security \nofficer, senior agency official for privacy), system owners; authorizing offi cials; system security \nofficers; privacy officers; acquisition and procurement officials; enterprise architects; systems \nengineers; software developers; systems security engineers; privacy engineers ; system, network, \nand database administrators; auditors; personnel conducting configuration management \nactivities; personnel performing verification and validation activities; personnel with  access to \nsystem -level software; control assessors; personnel with contingency planning and incident \nresponse duties; pers onnel with privacy management responsibilities; and personnel with  access \nto personally identifiable information.  \nComprehensive role- based training addresses management, operational, a", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1173{"doi": "NIST.SP.800-53r5", "chunk-id": "237", "chunk": "nd technical roles and \nresponsibilities covering physical, personnel, an d technical controls . Role -based training also \nincludes policies, procedures, tools, methods, and artifacts for the security and privacy roles \ndefined. Organizations provide the training necessary for individuals to fulfill their responsibilities \nrelated t o operations and supply chain  risk management  within the context of organizational \nsecurity and privacy programs. Role -based training also applies to contractors who provid e \nservices to federal agencies.  Types  of training  include  web -based and computer -based training , \nclassroom -style training , and ha nds-on training (including micro -training).  Updating role -basedNIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 63 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n training on a regular basis helps to ensure that the content remains relevant and effective. \nEvents that may pr", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1174{"doi": "NIST.SP.800-53r5", "chunk-id": "238", "chunk": "ecipitate an update to role -based training content include, but are not limited \nto, assessment or audit findings, security incidents or breaches , or changes in applicable laws, \nexecutive orders, directives, regulations, policies, standards, and guidelines.  \nRelated Controls :  AC -3, AC-17, AC-22, AT-2, AT-4, CP-3, IR-2, IR-4, IR-7, IR-9, PL-4, PM-13, PM-23, \nPS-7, PS-9, SA-3, SA-8, SA-11, SA-16, SR-5, SR-6, SR-11. \nControl Enhancements : \n(1) ROLE -BASED TRAINING | ENVIRONMENTAL CONTROLS   \nProvide [ Assignment: organization- defined personnel or roles ] with initial and \n[Assignment: organization- defined frequency ] training in the employment and operation \nof environmental controls.  \nDiscussion :  Environmental controls include  fire suppression and  detection devices  or \nsystems, sprinkler systems, handheld fire extinguishers, fixed fire hoses, smoke detectors, \ntemperature  or humidity, heating, ventilation, air conditioning, and power within the facility.  \nRelated Controls :  PE-1, PE-11, PE-13, PE-14, PE-15. \n(2) ROLE -BASED TRAINING | PHYSICAL SECURITY CONTROLS  \nProvide [ Assignment: organization- defined personnel or roles ] with initial and \n[Assignment: organization- defined frequency ] training in the employment and operation \nof physical security controls. ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1175{"doi": "NIST.SP.800-53r5", "chunk-id": "239", "chunk": " \nDiscussion :  Physical security controls include  physical access contr ol devices, physical \nintrusion and detection alarms,  operating procedures for facility security guards, and \nmonitoring  or surveillance equipment.  \nRelated Controls :  PE-2, PE-3, PE-4. \n(3) ROLE -BASED TRAINING | PRACTICAL EXERCISES  \nProvide  practical exercises in security and privacy training that reinforce training \nobjectives.  \nDiscussion :  Practical exercises for security include  training for software developers that \naddresses  simulated attacks that exploit common software vulnerabilities or spear or whale \nphishing attacks targeted at senior leaders  or executives. Practical exercises for privacy  \ninclude  modules with quizzes on identifying and process ing personally identifiable \ninformation  in various scenarios or scenarios on conducting privacy impact  assessments.  \nRelated Controls :  None.  \n(4) ROLE -BASED TRAINING | SUSPICIOUS COMMUNICATIONS AND ANOMALOUS SYSTEM BEHAVIOR  \n[With drawn: Moved to AT-2(4)]. \n(5) ROLE -BASED TRAINING | PROCESSING  PERSONALLY IDENTIFIABLE INFORMATION  \nProvide [Assignment: organization- defined personnel or roles ] with initial and \n[Assignment: organization- defined frequency ] training  in the employment and operation \nof personally identifiable inf", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1176{"doi": "NIST.SP.800-53r5", "chunk-id": "240", "chunk": "ormation processing and transparency controls.   \nDiscussion :  Personally identifiable information processing and transparency controls include \nthe organization\u2019s authority to process personally identifiable information and personally \nidentifiable information  processing purposes. Role -based training f or federal agencies  \naddresses the types of information that may constitute personally identifiable information \nand the risks, considerations, and obligations associated with its processing. Such training \nalso considers  the authority to process personally identifiable information documented in \nprivacy policies and notices, system of records notices, computer matching agreements andNIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 64 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n notices, privacy impact assessments, [PRIVACT ] statements, contracts, information sharing \nagreements, memoranda of understanding, and", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1177{"doi": "NIST.SP.800-53r5", "chunk-id": "241", "chunk": "/or other documentation.   \nRelated Controls :  PT- 2, PT-3, PT-5, PT-6. \nReferences :  [OMB A -130], [SP 800- 50], [SP 800- 181]. \nAT-4 TRAINING RECORDS  \nControl : \na. Document and monitor information security and privacy training activities , including security \nand privacy awareness training and specific role -based se curity and privacy training; and  \nb. Retain individual training records for [ Assignment: organization- defined time  period ]. \nDiscussion :  Documentation for specialized training may be maintained by individual supervisors \nat the discretion  of the organization. The National Archives and Records Administration provides \nguidance on records retention for federal agencies . \nRelated Controls :  AT-2, AT-3, CP-3, IR-2, PM-14, SI-12. \nControl Enhancements :  None.  \nReferences :  [OMB A -130]. \nAT-5 CONTACTS WITH SECURITY GROUPS AND ASSOCIATIONS  \n[Withdrawn: Incorporated into PM-15.] \nAT-6 TRAINING FEEDBACK  \nControl :  Provide feedback on organizational training results to the following personnel \n[Assignment: organization- defined frequency ]: [Assignment: organization -defined personnel ]. \nDiscussion :  Training feedback includes awareness training results and role -based training results.  \nTraining results, especially failures of personnel in critical r", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1178{"doi": "NIST.SP.800-53r5", "chunk-id": "242", "chunk": "oles, can be indicative of a potentially \nserious problem. Therefore, it is important that senior managers are made aware of such \nsituations so that they can take appropriate response actions. Training feedback supports the \nevaluation  and update of organization al training described in AT-2b and AT-3b. \nRelated Controls :  None . \nControl Enhancements :  None.  \nReferences :  None .NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 65 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n 3.3   AUDIT  AND  ACCOUNTABILITY  \nQuick link to Audit and Accountability Summary Table  \nAU-1 POLICY AND PROCEDURES  \nControl : \na. Develop, document, and disseminate to [ Assignment: organization- defined personnel or \nroles ]: \n1. [Selection (one or more): Organization- level; Mission/business process- level; System -\nlevel ] audit and accountability policy that:  \n(a) Addresses purpose, scope, roles, responsibilities, management commitm", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1179{"doi": "NIST.SP.800-53r5", "chunk-id": "243", "chunk": "ent, \ncoordination among organizational entities, and compliance; and  \n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and \n2. Procedures to facilitate the implementation of the audit and accountabil ity policy and \nthe associated audit and accountability controls;  \nb. Designate an [ Assignment: organization- defined official ] to manage the development, \ndocumentation, and dissemination of the audit and accountability policy and procedures; and \nc. Review and upda te the current audit and accountability:  \n1. Policy [Assignment: organization- defined frequency ] and following [Assignment: \norganization- defined events ]; and \n2. Procedures [ Assignment: organization- defined frequency ] and following [ Assignment: \norganization- define d events ]. \nDiscussion :  Audit and accountability policy and procedures address the controls in the AU family  \nthat are  implemented within systems and organizations. The risk management strategy is an \nimportant factor in establishing such policies and procedures. Policies and procedures contribute \nto security and privacy assurance. Therefore, it is important that security and privacy programs \ncollaborate on the development  of audit and accountability policy and proce", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1180{"doi": "NIST.SP.800-53r5", "chunk-id": "244", "chunk": "dures . Security and \nprivacy program policies and procedures at the organization level are preferable, in general, and \nmay obviate the need for mission - or syste m-specific policies and procedures. The policy can be \nincluded as part of the general security and privacy policy or be represented by multiple policies \nthat reflect the complex nature of organizations. Procedures can be established for security and \nprivac y programs , for mission  or business processes,  and for systems, if needed. Procedures \ndescribe how the policies or controls are implemented and can be directed at the individual or \nrole that is the object of the procedure. Procedures can be documented in s ystem security and \nprivacy plans or in one or more separate documents. Events that may precipitate an update to \naudit and accountability policy and procedures include  assessment or audit findings, security  \nincidents  or breaches , or changes in applicable laws, executive orders, directives, regulations, \npolicies, standards, and guidelines . Simply r estating controls does not constitute an \norganizational policy or procedure . \nRelated Controls :  PM -9, PS-8, SI-12. \nControl Enhancements :  None.  \nReferences :  [SP 800 -12], [SP 800- 30], [SP 800- 39], [ SP 800- 100].NIST  SP 800- 53, REV. 5       ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1181{"doi": "NIST.SP.800-53r5", "chunk-id": "245", "chunk": "                                                                              SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 66 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n AU-2 EVENT  LOGGING  \n Control : \na. Identify  the types of event s that the system is capable of logging in support of the audit \nfunction : [Assignment: organization -defined event  types that the system is capable of \nlogging];  \nb. Coordinate the event  logging function with other organizational entities requiring audit -\nrelated information to guide and inform the selection criteria for event s to be logged ; \nc. Specify  the following event types for logging within the system:  [Assignment: organization-\ndefined event  types  (subset of the event  types  defined in AU-2a.) along with the frequency of \n(or situatio n requiring) logging for each identified event  type ]; \nd. Provide a rationale for why the event types selected for logging are deemed to be adequate \nto support after -the-fact investigations of incidents ; and  \ne. Review and update", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1182{"doi": "NIST.SP.800-53r5", "chunk-id": "246", "chunk": " the event types selected for logging [ Assignment: organization- defined \nfrequency ]. \nDiscussion :  An event is an observable occurrence in a system. The types of event s that require \nlogging are those events that are significant and relevant to the security of systems  and the \nprivacy of individuals. Event logging also supports specific monitoring and auditing needs.  Event \ntypes include  password changes , failed logons or failed accesses related to systems,  security or \nprivacy attribute changes , administrative privilege usage , PIV credential usage , data action \nchanges , query parameters , or external credential usage. In determining the set of event types  \nthat require logging, organizations consider the monitoring and auditing appropriate for each of \nthe controls to be implemented.  For completeness, event logging includes all protocols that are \noperational and supported by the system.  \nTo balance monitoring and auditing requirements with o ther system needs, event logging \nrequires identifying the  subset of event types that are  logged  at a given point in time. For \nexample, organizations may determine that systems need the capability to log every file access \nsuccessful and unsuccessful, but not activate that capability except for specific circumstances du", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1183{"doi": "NIST.SP.800-53r5", "chunk-id": "247", "chunk": "e \nto the potential burden on system performance.  The types of events that organizations desire to  \nbe logged may change. Reviewing and updating the set of logged events is necessary to help \nensure that the events remain relevant and con tinue to support the needs of the organization.  \nOrganizations consider how the types of logging events can reveal information about individuals \nthat may give rise to privacy risk and how best to mitigate such risks. For example, there is the \npotential to reveal  personally identifiable information in the audit trail , especially if the logging \nevent is based on patterns or time of usage.  \nEvent  logging requirements, including the need to log specific event  types , may be referenced in \nother controls and control enhancements . These include  AC-2(4), AC-3(10) , AC-6(9), AC-17(1) , \nCM-3f, CM-5(1), IA-3(3.b) , MA-4(1), MP-4(2), PE-3, PM-21, PT-7, RA-8, SC-7(9), SC-7(15) , SI-3(8), \nSI-4(22) , SI-7(8), and SI-10(1) . Organizations include event types that are required by applicable \nlaws, executive orders, directives, policies, regulations, standards , and guidelines . Audit records \ncan be generated at various levels, including at the packet level as information travers es the \nnetwork. Selecting the appropriate level of  event  logging", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1184{"doi": "NIST.SP.800-53r5", "chunk-id": "248", "chunk": "  is an important part of a monitoring \nand audit ing capability and can identify  the root causes of problems. When  defini ng event types,  \norganizations  consider the logging  necessary to cover related event types , such as the steps in \ndistributed, transaction -based processes and the actions that occur in service -oriented \narchitectures.  \nRelated Controls :  AC-2, AC-3, AC-6, AC-7, AC-8, AC-16, AC-17, AU-3, AU-4, AU-5, AU-6, AU-7, AU-\n11, AU-12, CM-3, CM-5, CM-6, CM-13, IA-3, MA-4, MP-4, PE-3, PM-21, PT-2, PT-7, RA-8, SA-8, SC-\n7, SC-18, SI-3, SI-4, SI-7, SI-10, SI-11.NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 67 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n Control Enhancements : \n(1) EVENT  LOGGING  | COMPILATION OF AUDIT RECORDS FROM MULTIPLE SOURCES  \n[Withdrawn: Incorporated into AU-12.] \n(2) EVENT  LOGGING  | SELECTION OF AUDIT EVENTS BY COMPONENT  \n[Withdrawn: Incorporated into AU-12.] \n(3) EVE", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1185{"doi": "NIST.SP.800-53r5", "chunk-id": "249", "chunk": "NT  LOGGING  | REVIEWS AND UPDATES  \n[Withdrawn: Incorporated into AU-2.] \n(4) EVENT  LOGGING  | PRIVILEGED FUNCTIONS  \n[Withdrawn: Incorporated into AC-6(9).] \nReferences :  [OMB A -130], [SP 800-92].    \nAU-3 CONTENT OF AUDIT RECORDS  \n Control :  Ensure that audit records contain information that establishes the following:  \na. What type of event occurred;  \nb. When the event occurred;  \nc. Where the event occurred ; \nd. Source of the event ; \ne. Outcome of the event ; and  \nf. Identity of any individuals, subjects , or objects/entities associated with the event.  \nDiscussion :  Audit record content that may be necessary to support the auditing function \nincludes  event descriptions (item a), time stamps ( item b), source and destination addresses \n(item c), user or process identifiers ( items d and f), success or fail indications ( item e), and \nfilenames involved ( items a, c, e, and f) . Event outcomes include indicators of event success or \nfailure and event -specific results, such as the system security a nd privacy posture  after the event \noccurred. Organizations consider how audit records can reveal information about individuals that \nmay give rise to privacy risk s and how best to mitigate such risks.  For example, there is the \npotential to reveal  personally identif", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1186{"doi": "NIST.SP.800-53r5", "chunk-id": "250", "chunk": "iable information in the audit trail , especially if the trail \nrecords inputs or is based on patterns or time of usage.  \nRelated Controls :  AU-2, AU-8, AU-12, AU-14, MA-4, PL-9, SA-8, SI-7, SI-11. \nControl Enhancements : \n(1) CONTENT OF AUDIT RECORDS | ADDITIONAL AUDIT INFORMATION   \nGenerate audit records containing  the following additional information:  [Assignment: \norganization- defined additional information] . \nDiscussion :  The ability to add information generated in audit records is dependent on \nsystem functionality to configure the audit record content. Organizations may consider \nadditional information in audit records including , but not limited to,  access control or flow \ncontrol rules invoked  and individual identities of group account users . Organizations may \nalso consider limiting additional audit record information to only information that is \nexplicitly needed for audit requirements. This facilitates the use of audi t trails and audit logs \nby not including information in audit records that could potentially be misleading , make it \nmore difficult to locate information of interest, or increase the risk to individuals' privacy . \nRelated Controls :  None.NIST  SP 800- 53, REV. 5                                                                               ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1187{"doi": "NIST.SP.800-53r5", "chunk-id": "251", "chunk": "      SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 68 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n (2) CONTENT OF AUDIT RECORDS | CENTRALIZED MANAGEMENT OF PLANNED AUDIT RECORD CONTENT  \n[With drawn: Incorporated into PL-9.] \n(3) CONTENT OF AUDIT RECORDS | LIMIT PERSONALLY IDENTIFIABLE INFORMATION ELEMENTS   \nLimit personally identifiable information contained in audit records to  the following \nelements  identified in the privacy risk assessment: [ Assignment: organization- defined \nelements ]. \nDiscussion :  Limiting personally identifiable information in audit records when such \ninformation is not needed for operational purposes helps reduce the level of privacy risk \ncreated by a system. \nRelated Controls :  RA-3. \nReferences :  [OMB A -130], [IR 8062 ].  \nAU-4 AUDIT LOG STORAGE CAPACITY  \nControl :  Allocate audit log storage capacity to accommodate [ Assignment: organization- defined \naudit log retention requirements ]. \nDiscussion :  Organizations consider the types of audit logging to be performed and the audit", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1188{"doi": "NIST.SP.800-53r5", "chunk-id": "252", "chunk": " log \nprocessing requirements when allocating audit log storage capacity. Allocating sufficient audit \nlog storage capacity reduces the likelihood of such capacity being exceede d and resulting in the \npotential loss or reduction of audit  logging  capability.  \nRelated Controls :  AU-2, AU-5, AU-6, AU-7, AU-9, AU-11, AU-12, AU-14, SI-4. \nControl Enhancements : \n(1) AUDIT LOG STORAGE CAPACITY | TRANSFER TO ALTERNATE STORAGE   \nTransfer  audit logs [Assignment: organization- defined frequency ] to a different system , \nsystem component, or media  other than the system or system component conducting the \nlogging . \nDiscussion :  Audit log transfer , also known as o ff-loading , is a common process in systems \nwith limited audit log storage capacity  and thus supports availability of the audit logs. T he \ninitial audit log storage is only used in a transitory fashion until the system can communicate \nwith the secondary or alternate system allocated to audit log storage, at which point the \naudit logs are transferred. Transferring audit logs to alternate storage  is similar to AU-9(2) in \nthat audit logs are transferred to a different entity. However, the purpose of selecting AU-\n9(2) is to protect the confidentiality and integrity of audit records. Organizations can select \neither c", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1189{"doi": "NIST.SP.800-53r5", "chunk-id": "253", "chunk": "ontrol enhance ment to obtain the benefit of increased audit log storage capacity and \npreserving the confidentiality, integrity, and availability of audit records and logs.  \nRelated Controls :  None.  \nReferences :  None.  \nAU-5 RESPONSE TO AUDIT LOGGING PROCESS FAILURES  \nControl : \na. Alert [ Assignment: organization- defined personnel or roles ] within [Assignment: \norganization- defined time  period ] in the event of an audit logging process failure ; and  \nb. Take the following additional actions: [ Assignment: organization- defined additional actions ]. \nDiscussion :  Audit logging process failures include  software and hardware errors , failures in audit \nlog capturing mechanisms , and reaching or exceeding audit log storage capacity. Organization -\ndefined actions include  overwriting oldest audit records , shutting down the system , and stoppingNIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 69 \nThis publication is available free of charge from: https://", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1190{"doi": "NIST.SP.800-53r5", "chunk-id": "254", "chunk": "doi.org/10.6028/NIST.SP.800 -53r5 \n the generation of audit records. Organizations may choose to define additional actions for audit  \nlogging process failures based on the type of failure, the location of the failure, the severity of \nthe failure, or a combination of such factors. When the audit logging process failure is related to \nstorage, the response is carried out for  the audit log storage repository (i.e., the distinct system \ncomponent where the audit logs are stored) , the system on which the audit logs reside , the total \naudit log storage capacity of the organization (i.e., all audit log  storage repositories combined), or \nall three . Organizations may decide to take no additional actions after alerting designated roles \nor personnel. \nRelated Controls :  AU-2, AU-4, AU-7, AU-9, AU-11, AU-12, AU-14, SI-4, SI-12. \nControl Enhancements : \n(1) RESPONSE TO AUDIT LOGGING PROCESS FAILURES | STORAGE CAPACITY WARNING  \nProvide a warning to [ Assignment: organization- defined personnel, roles, and/or locations ] \nwithin [ Assignment: organization- defined time period ] when allocated audit log storage \nvolume reaches [ Assignment: organization -defined percentage ] of repository maximum \naudit log storage capacity . \nDiscussion :  Organizations may have multiple audit log  s", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1191{"doi": "NIST.SP.800-53r5", "chunk-id": "255", "chunk": "torage repositories distributed \nacross multiple system components with each repository having different storage volu me \ncapacities.  \nRelated Controls :  None.  \n(2) RESPONSE TO AUDIT LOGGING PROCESS FAILURES | REAL-TIME ALERTS   \nProvide an alert with in [Assignment: organization- defined real -time  period ] to \n[Assignment: organization- defined personnel, roles, and/or locations ] when  the following \naudit failure events occur:  [Assignment: organization- defined audit logging failure events \nrequiring real -time alerts ]. \nDiscussion :  Alerts provide organizations with urgent messages. Real -time alerts provide \nthese messages at information technology speed (i.e., the time from event detection to alert \noccurs in seconds or less).  \nRelated Controls :  None.  \n(3) RESPONSE TO AUDIT LOGGING PROCESS FAILURES | CONFIGURABLE TRAFFIC VOLUME THRESHOLDS  \nEnforce configurable network communications traffic volume thresholds reflecting limits on audit log storage capacity and [ Selection: reject; delay ] network traffic above  those \nthresholds.  \nDiscussion :  Organizations have the capability to reject or delay the processing of network \ncommunications traffic if audit logging information about such traffic is determined to \nexceed the storage capacity of the system audit log", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1192{"doi": "NIST.SP.800-53r5", "chunk-id": "256", "chunk": "ging function. The rejection or delay \nresponse is triggered by the established organizational traffic volume thresholds that can be \nadjusted based on changes to audit log storage capacity.  \nRelated Controls :  None.  \n(4) RESPONSE TO AUDIT LOGGING PROCESS FAILURES | SHUTDOWN ON FAILURE   \nInvoke a [ Selection: full system shutdown; partial system shutdown; degraded operational \nmode with limited mission or business functionality available] in the event of [ Assignment: \norganization- defined audit logging failures ], unless an alternate audit logging capability \nexists.  \nDiscussion :  Organizations determine the types of audit logging failures that can trigger \nautomatic system shutdowns or degraded operations. Beca use of the importance of \nensuring mission and business continuity, organizations may determine that the nature of \nthe audit logging failure is not so severe that it warrants a complete shutdown of the systemNIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE ", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1193{"doi": "NIST.SP.800-53r5", "chunk-id": "257", "chunk": "   PAGE 70 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n supporting the core organizational mission and business functions . In those instances, partial \nsystem shutdowns or operating in a degraded mode with reduced capability may be viable \nalternatives.  \nRelated Controls :  AU-15. \n(5) RESPONSE TO AUDIT LOGGING PROCESS FAILURES | ALTERNATE AUDIT LOGGING CAPABILITY   \nProvide an alternate audit logging capability in the event of a failure in primary audit \nlogging capability that implements [ Assignment: organization- defined alternate audit \nlogging functionality ]. \nDiscussion :  Since an alternate audit logging capability may be a short -term protection  \nsolution employed  until the failure in the primary audit logging capability is corrected, \norganizations may determine that the alternate audit logging capability need only provide a \nsubset of the primary audit logging functionality that is impacted by the failure.  \nRelated Controls :  AU-9. \nReferences :  None.   \nAU-6 AUDIT RECORD REVIEW, ANALYSIS, AND REPORTING  \nControl : \na. Review and analyze system audit records [ Assignment: organization- defined frequency ] for \nindications of [ Assignment: organization- defined inappropriate or unusual activity ] and the \npotent", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1194{"doi": "NIST.SP.800-53r5", "chunk-id": "258", "chunk": "ial impact of the inappropriate or unusual activity ; \nb. Report findings to [ Assignment: organization- defined personnel or roles ]; and \nc. Adjust the level of audit record review, analysis, and reporting within the system when there \nis a change in risk based on law enforcement information, intelligence information, or other \ncredible sources of information.  \nDiscussion :  Audit record review, analysis, and reporting covers information security - and privacy-\nrelated  logging performed by organizations , including logging that results from the monitoring of \naccount usage, remote access, wireless connectivity, mobile device connection, configuration \nsettings, syst em component inventory, use of maintenance tools and non -local maintenance, \nphysical access, temperature and humidity, equipment delivery and  removal, communications at \nsystem interfaces , and use of mobile code  or Voice over Internet Protocol ( VoIP ). Findings can be \nreported to organizational entities that include  the incident response team, help desk, and \nsecurity or privacy offices . If organizations are prohibited from reviewing and analyzing audit \nrecord s or unable to conduct such activities, the re view  or analysis may be  carried out by other \norganizations granted such authority. The frequency", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1195{"doi": "NIST.SP.800-53r5", "chunk-id": "259", "chunk": ", scope, and/or depth of the audit record \nreview, analysis, and reporting may be adjusted to meet organizational needs based on new \ninformation received.  \nRelate d Controls :  AC-2, AC-3, AC-5, AC-6, AC-7, AC-17, AU-7, AU-16, CA-2, CA-7, CM-2, CM-5, \nCM-6, CM-10, CM-11, IA-2, IA-3, IA-5, IA-8, IR-5, MA-4, MP-4, PE-3, PE-6, RA-5, SA-8, SC-7, SI-3, \nSI-4, SI-7. \nControl Enhancements : \n(1) AUDIT RECORD REVIEW , ANALYSIS , AND REPORTING | AUTOMATED PROCESS INTEGRATION   \nIntegrate audit record review, analysis, and reporting processes using [ Assignment: \norganization- defined automated mechanisms ]. \nDiscussion :  Organizational processes that benefit from integrated audit record review, \nanalysis, and reporting include  incident response, continuous monitoring, contingency \nplanning, investigation and response to suspicious activities, and Inspector General audits.NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n_________________________________________________________________________________________________  \nCHAPTER THREE    PAGE 71 \nThis publication is available free of charge fro", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1196{"doi": "NIST.SP.800-53r5", "chunk-id": "260", "chunk": "m: https://doi.org/10.6028/NIST.SP.800 -53r5 \n Related Controls :  PM -7. \n(2) AUDIT RECORD REVIEW , ANALYSIS , AND REPORTING | AUTOMATED SECURITY ALERTS   \n[With drawn: Incorporated into SI-4.] \n(3) AUDIT RECORD REVIEW , ANALYSIS , AND REPORTING | CORRELATE AUDIT RECORD REPOSITORIES   \nAnalyze and correlate audit records across different repositories to gain organization -wide \nsituational awareness.  \nDiscussion :  Organization -wide situational awareness includes awareness across all three \nlevels of risk management (i.e., organizational  level , mission /business process level , and \ninformation system  level ) and supports cross -organization awareness.  \nRelated Controls :  AU-12, IR-4. \n(4) AUDIT  RECORD  REVIEW , ANALYSIS , AND REPORTING | CENTRAL REVIEW AND ANALYSIS   \nProvide and implement the capability to centrally review and analyze audit records from \nmultiple components within the system.  \nDiscussion :  Automated mechanisms for centralized reviews and analyses include  Security \nInformation and Event Management products.  \nRelated Controls :  AU-2, AU-12. \n(5) AUDIT RECORD REVIEW , ANALYSIS , AND REPORTING | INTEGRATED ANALYSIS OF AUDIT RECORDS  \nIntegrate analysis of audit records with analysis of [ Selection (one or more): vulnerability \nscanning information; pe", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1197{"doi": "NIST.SP.800-53r5", "chunk-id": "261", "chunk": "rformance data; system monitoring information;  [Assignment: \norganization- defined data/information collected from other sources ]] to further enhance \nthe ability to identify inappropriate or unusual activity.  \nDiscussion :  Integrated analysis of audit records does not require vulnerability scanning, the \ngeneration of performance data, or system moni toring. Rather, integrated analysis requires \nthat the analysis  of information generated  by scanning, monitoring, or other data collection \nactivities is integrated with the analysis of audit record information. Security Information \nand Event Management tools can facilitate audit record aggregation  or consolidation from \nmultiple system components as well as audit record correlation and analysis. The use of \nstandardized audit record analysis scripts developed by organizations (with localized script \nadjustments, as necessary) provides more cost -effective approaches for analyzing audit \nrecord information collected. The correlation of audit record information  with vulnerability \nscanning information is important in determining the veracity of vulnerability scans of the system and in correlating attack detection events with scanning results. Correlation with \nperformance data can uncover denial -of-service attacks  or other", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1198{"doi": "NIST.SP.800-53r5", "chunk-id": "262", "chunk": " types of attacks that result \nin the unauthorized use of resources. Correlation with system monitoring information can \nassist in uncovering attacks and in better relating audit information to operational situations.  \nRelated Controls :  AU-12, IR-4. \n(6) AUDIT RECORD REVIEW , ANALYSIS , AND REPORTING | CORRELATION WITH PHYSICAL MONITORING   \nCorrelate information from audit records with information obtained from monitoring \nphysical access to further enhance the ability to identify suspicious, inappropriate, \nunusual, or malevolent activity.  \nDiscussion :  The correlation of physical audit record information and the audit records  from \nsystems may assist organizations in identifying suspicious behavior or supporting evidence of such behavior. For example, the correlation of an individual\u2019s identity for logical access to \ncertain systems with the additional physical security information that the individual was \npresent at the facility when the logica l access occurred may be useful in investigations.  \nRelated Controls :  None.NIST  SP 800- 53, REV. 5                                                                                     SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS                                                                  \n______", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1199{"doi": "NIST.SP.800-53r5", "chunk-id": "263", "chunk": "___________________________________________________________________________________________  \nCHAPTER THREE    PAGE 72 \nThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800 -53r5 \n (7) AUDIT RECORD REVIEW , ANALYSIS , AND REPORTING | PERMITTED ACTIONS   \nSpecify the permitted actions for each [ Selection (one or more): system process; role; user ] \nassociated with the review, analysis, and reporting of audit record information.  \nDiscussion :  Organizations specify permitted actions for system processes, roles, and  users \nassociated with the review, analysis, and reporting of audit records through system account \nmanagement activities. Specifying permitted actions on audit record information is a way to \nenforce the principle of least privilege. Permitted actions are enforced by the system and \ninclude  read, write, execute, append, and delete. \nRelated Controls :  None.  \n(8) AUDIT RECORD REVIEW , ANALYSIS , AND REPORTING | FULL TEXT ANALYSIS OF PRIVILEGED \nCOMMANDS   \nPerform a full text analysis of logged privileged commands in a physically distinct \ncomponent or subsystem of the system, or other system that is dedicated to that analysis.  \nDiscussion :  Full text analysis of priv ileged commands requires a distinct environment for the \nanaly", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}1200{"doi": "NIST.SP.800-53r5", "chunk-id": "264", "chunk": "sis of audit record information related to privileged users without compromising such \ninformation on the system where the users have elevated privileges , including the capability \nto execute privi leged commands. Full text analysis refers to analysis that considers the full \ntext of privileged commands (i.e., commands and parameters) as opposed to analysis that \nconsiders only the name of the command. Full text analysis includes the use of pattern \nmatching and heuristics.  \nRelated Controls :  AU-3, AU-9, AU-11, AU-12. \n(9) AUDIT RECORD REVIEW , ANALYSIS , AND REPORTING | CORRE LATION WITH INFORMATION FROM \nNONTECHNICAL SOURCES  \nCorrelate information from nontechnical sources with audit record information to enhance \norganization -wide situational awareness.  \nDiscussion :  Nontechnical sources include  records that document organizational policy \nviolations related to harassment incidents and  the improper use of  information assets. Such \ninformation can lead to a directed analytical effort to detect potential malicious insider \nactivity. Organizations limit access to information that is available from nontechnical sources  \ndue to its sensitive nature. Limited access minimize s the potential for inadvertent release of \nprivacy- related information to individuals who  do no", "id": "NIST.SP.800-53r5", "title": "NIST.SP.800-53r5", "source": "NIST.SP.800-53r5", "authors": [], "categories": [], "references": []}

Showing the first 1,200 of 2229 lines. Download the file for the rest.