UNCLASSIFIED FOR OFFICIAL USE ONLY 1 2 3 4 5 National Security Agency Information Assurance Directorate 6 7 8 9 10 11 12 13 14 15 16 U Global Information Grid Information Assurance Capability Technology Roadmap 17 18 19 20 21 22 Version 1 0 Final Draft 23 24 25 26 26 October 2004 27 28 29 30 31 32 Prepared by IA Architecture Office I11 UNCLASSIFIED FOR OFFICIAL USE ONLY UNCLASSIFIED FOR OFFICIAL USE ONLY 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 U This page intentionally left blank UNCLASSIFIED FOR OFFICIAL USE ONLY UNCLASSIFIED FOR OFFICIAL USE ONLY U TABLE OF CONTENTS 51 52 Section Title 53 U Revision History xv 54 U Executive Summary I 55 1 U Introduction 1-1 56 1 1 U Purpose 1-1 57 1 2 U Scope 1-2 58 1 3 U Approach 1-2 59 60 2 U IA System Enablers and their Technologies 2-1 2 1 U Identification and Authentication 2 1-1 61 2 1 1 U GIG Benefits due to I A 2 1-2 62 2 1 2 U I A Description 2 1-2 63 2 1 3 U I A Technologies 2 1-4 64 2 1 3 1 U Authentication Tokens 2 1-5 65 2 1 3 2 U Biometrics 2 1-15 66 2 1 3 3 U Device Service Authentication 2 1-25 67 2 1 3 4 U Authentication Protocols 2 1-35 68 2 1 3 5 U Authentication Confidence 2 1-43 69 2 1 3 6 U Single Sign-On 2 1-46 70 2 1 4 U I A Gap Analysis 2 1-59 71 2 1 5 U Identification and Authentication Recommendations and Timelines2 1-62 72 2 2 U Policy-Based Access Control 2 2-1 73 2 2 1 U GIG Benefits due to Policy-Based Access Control 2 2-2 74 2 2 2 U Policy-Based Access Control Description 2 2-2 75 2 2 2 1 U Core RAdAC Functions 2 2-2 76 2 2 2 2 U Assured Metadata and Data Describing Enterprise Elements 2 2-4 77 2 2 2 3 U Digital Access Control Policy 2 2-5 i UNCLASSIFIED FOR OFFICIAL USE ONLY Page UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2 2 4 78 79 U IA Enabler Dependencies 2 2-6 2 2 3 U Policy-Based Access Control Technologies 2 2-6 80 2 2 3 1 U Core RAdAC 2 2-7 81 2 2 3 2 U Assured Metadata 2 2-15 82 2 2 3 3 U Digital Access Control Policy 2 2-40 83 2 2 4 U Distributed Policy Based Access Control Gap Analysis 2 2-44 84 2 2 4 1 U Core RAdAC Gap Analysis 2 2-44 85 2 2 4 2 U Assured Metadata Gap Analysis 2 2-46 86 2 2 4 3 U Digital Access Control Policy Gap Analysis 2 2-49 87 88 2 2 5 U Policy Based Access Control Recommendations and Timelines 2 2-50 2 3 U Protection of User Information 2 3-1 89 2 3 1 U GIG Benefits Due to Protection of User Information 2 3-2 90 2 3 2 U Protection of User Information Description 2 3-3 91 2 3 3 U Protection of User Information Technologies 2 3-7 92 2 3 3 1 U Technologies for Protecting Data-at-Rest 2 3-8 93 2 3 3 2 U Technologies for Protecting Data-in-Transit 2 3-10 94 2 3 3 3 U Trusted Platforms 2 3-87 95 2 3 3 4 U Trusted Applications 2 3-98 96 2 3 3 5 U Cross Domain Solution Technologies 2 3-106 97 2 3 3 6 U Non-Repudiation 2 3-116 98 2 3 4 U Protection of User Information Gap Analysis 2 3-126 99 2 3 5 U Protection of User Information Recommendations and Technology Timelines 2 3-130 100 101 2 3 5 1 U Data-in-Transit 2 3-130 102 2 3 5 2 U Cross Domain Solutions 2 3-132 103 104 2 4 U Dynamic Policy Management 2 4-1 2 4 1 U GIG Benefits due to Dynamic Policy Management 2 4-2 UNCLASSIFIED FOR OFFICIAL USE ONLY ii UNCLASSIFIED FOR OFFICIAL USE ONLY 105 2 4 2 U Dynamic Policy Management Description 2 4-2 106 2 4 3 U Dynamic Policy Management Technologies 2 4-6 107 2 4 3 1 U FOUO Development of Policies 2 4-6 108 2 4 3 2 U Distribution of Policies 2 4-22 109 2 4 3 3 U Policy Management Architectures 2 4-29 110 2 4 4 U Dynamic Policy Management Gap Analysis 2 4-31 111 2 4 5 U Dynamic Policy Management Recommendations and Timelines 2 4-33 112 2 4 5 1 U Standards 2 4-33 113 2 4 5 2 U Technology 2 4-34 114 2 4 5 3 U Infrastructure 2 4-34 115 2 5 U Assured Resource Allocation 2 5-1 116 2 5 1 U GIG Benefits of Assured Resource Allocation 2 5-3 117 2 5 2 U Assured Resource Allocation Description 2 5-3 118 2 5 3 U Technologies 2 5-5 119 2 5 3 1 U FOUO IA Policy-Based Routing 2 5-6 120 2 5 3 2 U FOUO Operational-Based Resource Allocation 2 5-17 121 2 5 3 3 122 U FOUO Integrity of Network Fault Monitoring Recovery and Integrity of Network Management Control 2 5-26 123 2 5 4 U Assured Resource Allocation Gap Analysis 2 5-38 124 2 5 5 U Assured Resource Allocation Recommendations and Technology Timelines 2 5-40 125 126 2 6 U Network Defense and Situational Awareness 2 6-1 127 2 6 1 U GIG Benefits due to Network Defense and Situational Awareness 2 6-2 128 2 6 2 U Network Defense and Situational Awareness Description 2 6-3 129 2 6 3 U Network Defense and Situational Awareness Technologies 2 6-8 130 2 6 3 1 U Protect Technologies 2 6-9 131 2 6 3 2 U Deception Technologies 2 6-14 UNCLASSIFIED FOR OFFICIAL USE ONLY iii UNCLASSIFIED FOR OFFICIAL USE ONLY 132 2 6 3 3 U Situational Awareness 2 6-21 133 2 6 3 4 U Network Mapping 2 6-26 134 2 6 3 5 U Intrusion Detection Systems 2 6-30 135 2 6 3 6 U Intrusion Prevention Systems IPSs 2 6-37 136 2 6 3 7 U User Activity Profiling 2 6-39 137 2 6 3 8 U Cyber Attack Attribution 2 6-44 138 2 6 3 9 U Correlation Technologies 2 6-49 139 2 6 3 10 U CND Response Actions 2 6-54 140 2 6 3 11 U Automated IAVA Patch Management 2 6-58 141 2 6 4 U Network Defense and Situational Awareness Gap Analysis 2 6-63 142 2 6 5 U Network Defense and Situational Awareness Recommendations and Timelines 2 6-66 143 144 2 6 5 1 U Standards 2 6-66 145 2 6 5 2 U Technology 2 6-66 146 2 6 5 3 U Infrastructure 2 6-69 147 2 6 5 4 U Technology Timelines 2 6-69 148 2 7 U Management of IA Mechanisms and Assets 2 7-1 149 2 7 1 U GIG Benefits due to Management of IA Mechanisms and Assets 2 7-1 150 2 7 2 U Management of IA Mechanisms and Assets Description 2 7-1 151 2 7 2 1 U Identity Management 2 7-2 152 2 7 2 2 U Privilege Management 2 7-5 153 2 7 2 3 U Key Management 2 7-9 154 2 7 2 4 U Certificate Management 2 7-11 155 2 7 2 5 U Configuration Management of IA Devices and Software 2 7-14 156 2 7 2 6 U Inventory Management 2 7-16 157 2 7 2 7 U Compromise Management of IA Devices 2 7-16 158 2 7 2 8 U Audit Management 2 7-17 UNCLASSIFIED FOR OFFICIAL USE ONLY iv UNCLASSIFIED FOR OFFICIAL USE ONLY 2 7 3 U Management of IA Mechanisms Assets Technologies 2 7-18 159 160 2 7 3 1 U Identity Management 2 7-18 161 2 7 3 2 U Privilege Management 2 7-26 162 2 7 3 3 U Key Management 2 7-33 163 2 7 3 4 U Certificate Management 2 7-49 164 2 7 3 5 U Configuration Management of IA Devices and Software 2 7-59 165 2 7 3 6 U Inventory Management 2 7-68 166 2 7 3 7 U Compromise Management of IA Devices 2 7-76 167 2 7 3 8 U Audit Management 2 7-82 2 7 4 U Management of IA Mechanisms Assets Gap Analysis 2 7-93 168 169 2 7 4 1 U Identity Management 2 7-96 170 2 7 4 2 U Privilege Management 2 7-96 171 2 7 4 3 U Key Management 2 7-97 172 2 7 4 4 U Certificate Management 2 7-97 173 2 7 4 5 U Configuration Management of IA Devices and Software 2 7-98 174 2 7 4 6 U Inventory Management 2 7-99 175 2 7 4 7 U Compromise Management of IA Devices 2 7-99 176 2 7 4 8 U Audit Management 2 7-99 2 7 5 U Management of IA Mechanisms and Assets Recommendations and Timelines 2 7-100 177 178 179 2 7 5 1 U Standards 2 7-100 180 2 7 5 2 U Technology 2 7-101 181 2 7 5 3 U Infrastructure 2 7-101 182 183 3 U Summary 3-1 3 1 U FOUO Assured information Sharing Summary 3 1-3 184 3 1 1 U Identification and Authentication Technologies 3 1-3 185 3 1 2 U Access Control and Data Labeling Technologies 3 1-5 UNCLASSIFIED FOR OFFICIAL USE ONLY v UNCLASSIFIED FOR OFFICIAL USE ONLY 186 3 1 3 U Cross-Domain Technologies 3 1-7 187 3 1 4 U Trusted Platform Technologies 3 1-9 188 3 2 U Highly Available Enterprise Summary 3 2-11 190 3 2 1 U FOUO IA Policy-based Routing for Mobile Tactical Environments Technologies 3 2-11 191 3 2 2 U End-to-End Resource Allocation Technologies 3 2-12 192 3 2 3 U FOUO Edge-to-Edge Boundary Protection Technologies 3 2-13 193 3 2 4 U Secure Voice Technologies 3 2-13 194 3 2 5 U Enforcement of QoP in Transit Technologies 3 2-14 195 3 2 6 U FOUO Protection of High Risk Link Technologies 3 2-14 189 196 3 3 U Assured Enterprise Management and Control Summary 3 3-15 197 3 3 1 U Identity Management Technologies 3 3-16 198 3 3 2 U Inventory Management Technologies 3 3-16 199 3 3 3 U Privilege Management Technologies 3 3-17 200 3 3 4 U Key Management Technologies 3 3-18 201 3 3 5 U Certificate Management Technologies 3 3-19 202 3 3 6 U Configuration Management Technologies 3 3-20 203 3 3 7 U Policy Management Technologies 3 3-20 204 3 3 8 U Audit Management Technologies 3 3-22 205 3 3 9 U Confidentiality Integrity of Network Management Control Technologies 3 3-23 206 207 3 4 U Cyber Situational Awareness and Network Defense Summary 3 4-24 208 3 4 1 U Protection Technologies 3 4-25 209 3 4 2 U Monitoring Technologies 3 4-25 210 3 4 3 U Detection Technologies 3 4-26 211 3 4 4 U Analysis Technologies 3 4-28 212 3 4 5 U Response Technologies 3 4-29 UNCLASSIFIED FOR OFFICIAL USE ONLY vi UNCLASSIFIED FOR OFFICIAL USE ONLY 213 4 U Acronyms and Abbreviations 4-1 214 215 Appendices 216 U FOUO Appendix A Mapping of technologies to IA System Enablers A-2 217 U FOUO Appendix B TV-1 for IA A-6 218 U FOUO Appendix C TV-2 for IA A-23 219 UNCLASSIFIED FOR OFFICIAL USE ONLY vii UNCLASSIFIED FOR OFFICIAL USE ONLY U LIST OF FIGURES 220 221 Figure Title Page 222 Figure 1 3-1 U GIG Mission Concepts IA Cornerstones and IA System Enablers 1-3 223 Figure 1 3-2 U Iterative Development of the GIG IA Capability Technology Roadmap 1-5 224 Figure 2 1-1 U Examples of time-driven hardware tokens 2 1-6 225 Figure 2 1-2 U DoD Common Access Card 2 1-10 226 Figure 2 1-3 U Example of a Hybrid Device 2 1-14 227 Figure 2 1-4 U Biometric System Block Diagram 2 1-15 228 Figure 2 1-5 U Network Authentication Framework 2 1-37 229 Figure 2 1-6 U Device Authentication Framework 2 1-37 230 Figure 2 1-7 U Centralized Architecture for Single Sign-On 2 1-48 231 Figure 2 1-8 U Federated KEBEROS Based Single Sign-On 2 1-50 232 Figure 2 1-9 U Federated PKI-based Single Sign-on 2 1-51 233 Figure 2 1-10 U Federated SAML-Based Single Sign-On 2 1-52 234 Figure 2 2-1 U RAdAC Functional Model 2 2-3 235 Figure 2 2-2 U Codifying the Net-Centric Data Strategy 2 2-22 236 Figure 2 2-3 U Encapsulation Notional Diagram 2 2-38 237 Figure 2 2-4 U Policy-Based Access Control Gap Closure Timelines 2 2-51 238 Figure 2 3-1 U Context of Non Real-Time Application Security 2 3-11 239 Figure 2 3-2 U Layered Protocol Wrapping Concept 2 3-12 240 Figure 2 3-3 U CMS Supports S MIME and Other Secure Applications 2 3-16 241 Figure 2 3-4 U TLS Handshake Protocol 2 3-23 242 Figure 2 3-5 U Model for Web Services Security 2 3-30 243 Figure 2 3-6 U FNBDT Location in Network Protocol Stack 2 3-33 244 Figure 2 3-7 U Packet Jitter Mitigation Process 2 3-35 245 Figure 2 3-8 U FOUO FNBDT Frame Structure for Signaling Reliability and Reliable UNCLASSIFIED FOR OFFICIAL USE ONLY viii UNCLASSIFIED FOR OFFICIAL USE ONLY 246 Transport Data Mode 2 3-36 247 248 Figure 2 3-9 U FOUO FNBDT 2400 bps MELP Blank and Burst Superframe Structure 2 3-37 249 Figure 2 3-10 U FOUO FNBDT 7200 bps G 729D Superframe Structure 2 3-37 250 Figure 2 3-11 U Media Gateway Protocol Stack Illustration 2 3-41 251 Figure 2 3-12 U FOUO Secure Voice Gateway Functionality 2 3-42 252 Figure 2 3-13 U Real-Time Protocol 2 3-46 253 Figure 2 3-14 U RTCP Sender Report Format- Sender Report SR 2 3-48 254 Figure 2 3-15 U SRTP Format 2 3-50 255 Figure 2 3-16 U SRTCP Format 2 3-50 256 Figure 2 3-17 U FOUO FNBDT over V 150 1 Modem Relay 2 3-52 257 Figure 2 3-18 U V 150 1 Simple Packet Relay Transport for IP networks 2 3-52 258 Figure 2 3-19 U FOUO State Variable Stepping 2 3-62 259 Figure 2 3-20 U SIP Architecture 2 3-78 260 Figure 2 3-21 U H 323 Network Elements 2 3-80 261 Figure 2 3-22 U Legacy Manifestation of Cross-Domain Solutions 2 3-106 262 Figure 2 3-23 U Controlled Interface Example 2 3-107 263 Figure 2 3-24 U Two MSL Architectures 2 3-108 264 Figure 2 3-25 U Technology Timeline for Protection of User Information Date in Transit 2 3-132 265 267 Figure 2 3-26 U Technology Timeline for Protection of User Information Cross Domain Solutions 2 3-133 268 Figure 2 4-1 U Notional Architectural Framework for Dynamic Policy Management 2 4-3 269 Figure 2 4-2 U Berners-Lee's Seven Layer Model of the Semantic Web 2 4-19 270 Figure 2 4-3 U Technology Timeline for Dynamic Policy Management 2 4-35 271 Figure 2 5-1 U FOUO The Role and Components of Assured Resource Allocation 2 5-2 272 Figure 2 5-2 U FOUO IA Policy-Based Routing 2 5-6 266 UNCLASSIFIED FOR OFFICIAL USE ONLY ix UNCLASSIFIED FOR OFFICIAL USE ONLY 274 Figure 2 5-3 U FOUO Security-Aware ad-hoc Routing SAR in Tactical Wireless Application 2 5-10 275 Figure 2 5-4 U OSPF Implemented With QoS IA Policy-Based Routing Extensions 2 5-14 276 Figure 2 5-5 U DeSiDeRaTa Architecture for Operational-Based Resource Allocation 2 5-18 277 Figure 2 5-6 U Joint Resource Allocation Across GIG Networks 2 5-21 278 Figure 2 5-7 U Basic Elements of SNMP Operation 2 5-26 279 Figure 2 5-8 U SNMPv3 Security Capabilities 2 5-27 280 Figure 2 5-9 U SNMPv3 Message Format Security Components 2 5-28 281 Figure 2 5-10 U SNMPv3 View-based Access Control Model VACM Logic 2 5-29 282 Figure 2 5-11 U Technology Timeline for Assured Resource Allocation 2 5-41 283 Figure 2 6-1 U Representative Sensor Configuration 2 6-4 284 Figure 2 6-2 U Representative Flow of Situational Awareness Data 2 6-5 285 Figure 2 6-3 U Vulnerabilities Reported from CERT 2 6-59 286 Figure 2 6-4 U Technology Timeline for Network Defense and Situational Awareness 2 6-69 287 Figure 2 7-1 U FOUO Assured Sharing Context Diagram Emphasizing Privileges 2 7-6 288 Figure 2 7-2 U Example of Multiple Identities Assigned to a Single User 2 7-18 289 Figure 2 7-3 U FOUO ECU and Technology Evolution 2 7-33 290 Figure 2 7-4 U Current Key Management Infrastructures 2 7-33 291 Figure 2 7-5 U FOUO KMI - Envisioned Infrastructure 2 7-35 292 Figure 2 7-6 U FOUO KMI Protected Channel Layers 2 7-39 293 Figure 2 7-7 U XKMS Environment 2 7-40 294 Figure 2 7-8 U DoD and Commercial Certificate-Managed Infrastructures 2 7-49 295 Figure 2 7-9 U PKI Technology Model 2 7-50 296 Figure 2 7-10 U RFID Operation 2 7-69 297 Figure 2 7-11 U Audit Life Cycle 2 7-82 298 Figure 2 7-12 U Audit Trail Information Flow 2 7-84 273 UNCLASSIFIED FOR OFFICIAL USE ONLY x UNCLASSIFIED FOR OFFICIAL USE ONLY 299 Figure 2 7-13 U Audit Logs - Protection 2 7-86 300 Figure 2 7-14 U Aggregation and Normalization 2 7-88 301 302 Figure 2 7-15 U Interfaces - Agents and Pipes between Log Devices and the Collection Monitoring Processes 2 7-89 303 Figure 2 7-16 U Technology Timeline for Assured Resource Allocation 2 7-102 304 Figure 3 1-1 U FOUO Technology Timeline for Assured Information Sharing 3 1-3 305 Figure 3 2-1 U FOUO Technology Timeline for Highly Available Enterprise 3 2-11 306 Figure 3 3-1 U FOUO Technology Timeline for Assure Enterprise Management and Control 3 3-15 307 308 309 Figure 3 4-1 U FOUO Technology Timeline for Cyber Situational Awareness and Network Defense 3 4-24 UNCLASSIFIED FOR OFFICIAL USE ONLY xi UNCLASSIFIED FOR OFFICIAL USE ONLY U LIST OF TABLES 310 311 Table Title Page 312 Table 1 3-2 U Example of a Technology Adequacy Matrix 2-4 313 Table 2 1-1 U Hardware Token Standards 2 1-9 314 Table 2 1-2 U Biometric Standards 2 1-21 315 Table 2 1-3 U Technology Adequacy for Tokens and Biometrics 2 1-60 316 Table 2 1-4 U Technology Adequacy for Single Sign-On and Authentication 2 1-61 317 Table 2 2-1 U Access Control Standards 2 2-11 318 Table 2 2-2 U Technologies Supporting Access Control 2 2-12 319 Table 2 2-3 U Minimum Set of IA Attributes for Access Control Decisions 2 2-18 320 Table 2 2-4 U IC and CES Metadata Working Groups Attribute Comparison 2 2-20 321 Table 2 2-5 U Metadata Standards 2 2-24 322 Table 2 2-6 U Metadata Gap Analysis 2 2-27 323 Table 2 2-7 U Metadata Tool Standards 2 2-35 324 Table 2 2-8 U Standards on Cryptographic Binding 2 2-39 325 Table 2 2-9 U Technology Adequacy for Access Control 2 2-46 326 Table 2 2-10 U Technology Adequacy for Metadata 2 2-48 327 Table 2 3-1 U Traditional Layered Application Security Standards 2 3-19 328 Table 2 3-2 U Session Security Standards 2 3-26 329 Table 2 3-3 U Web Services Security Standards 2 3-31 330 Table 2 3-4 U FNBDT Standards 2 3-38 331 Table 2 3-5 U Secure Voice over IP Standards 2 3-57 332 Table 2 3-6 U FOUO HAIPE ESP Tunnel Mode Encapsulation 2 3-60 333 Table 2 3-7 U FOUO HAIPE State Variable Content 2 3-61 334 Table 2 3-8 U FOUO IP Security Technology Readiness Levels 2 3-64 335 Table 2 3-9 U FOUO Standards Applicable to IP Security Technology 2 3-66 336 Table 2 3-10 U FOUO Standards Applicable to VPN Technology 2 3-73 UNCLASSIFIED FOR OFFICIAL USE ONLY xii UNCLASSIFIED FOR OFFICIAL USE ONLY 337 Table 2 3-11 U Secure VoIP Call Control Standards 2 3-84 338 Table 2 3-12 U CDS Standards 2 3-114 339 Table 2 3-13 U Non-Repudiation Standards 2 3-124 340 Table 2 3-14 U FOUO Secure Voice Technology Gap Analysis 2 3-126 341 342 Table 2 3-15 U FOUO Gap Analysis for Non-real-time Application Layer Technologies 2 3-128 343 Table 2 3-16 U FOUO CDS Technology Gap Assessment 2 3-129 344 Table 2 4-1 U Access Control Standards 2 4-10 345 Table 2 4-2 U Trust Anchor Standards 2 4-13 346 Table 2 4-3 U Policy Language Standards 2 4-20 347 Table 2 4-4 U Distribution Standards 2 4-24 348 Table 2 4-5 U Distribution Security Standards 2 4-28 349 Table 2 4-6 U Directory Standards 2 4-31 350 Table 2 4-7 U Technology Adequacy for Dynamic Policy Management 2 4-33 351 Table 2 5-1 U Technology Adequacy for Assured Resource Allocation 2 5-39 352 Table 2 6-1 U Standards for Intrusion Detection Systems 2 6-33 353 Table 2 6-2 U Network Defense Situational Awareness Technology Gap Assessment 2 6-64 354 Table 2 6-3 U FOUO Summary of Technology Gaps 2 6-67 355 Table 2 7-1 U Identity Management Standards 2 7-24 356 Table 2 7-2 U Comparisons of PKI and PMI 2 7-28 357 Table 2 7-3 U Privilege Management Standards 2 7-31 358 Table 2 7-4 U Key Management Standards 2 7-47 359 Table 2 7-5 U Key Management and Certificate Management Standards 2 7-54 360 Table 2 7-6 U Configuration Management Standards 2 7-64 361 Table 2 7-7 U Frequency Ranges for RFID Systems 2 7-70 362 Table 2 7-8 U Inventory Management RFID Standards 2 7-72 363 Table 2 7-9 U Compromise Management Standards 2 7-79 364 Table 2 7-10 U Audit Management Standards 2 7-91 UNCLASSIFIED FOR OFFICIAL USE ONLY xiii UNCLASSIFIED FOR OFFICIAL USE ONLY 365 Table 2 7-11 U Technology Adequacy for Management of IA Mechanisms and Assets 2 7-94 366 Table A-1 U FOUO Mapping of Technologies to IA System Enablers A-2 367 Table B-1 U FOUO TV-1 for IA A-6 368 Table C-1 U FOUO TV-2 for IA A-23 UNCLASSIFIED FOR OFFICIAL USE ONLY xiv UNCLASSIFIED FOR OFFICIAL USE ONLY U REVISION HISTORY 369 This Table is U FOUO Revision Number Revision 1 0 Initial Draft Revision 1 0 Final Draft Description Date Initial baseline document that describes the Capability Technology Roadmap Primary focus is on Identification and Authentication technologies 30 June 2004 General Revised Summary and Executive Summary based on latest technology research and ability to meet Transition Strategy for each Cornerstone Reorganized introduction and eliminated Global Information Grid GIG Mission Concept description Added introduction to Section 2 that explains application of TRLs adequacy levels and technology timelines in subsequent sections Deleted Appendix on IA Pillars added appendix with mapping of technologies to section where described and updated TV-1 and TV-2 15 Oct 2004 2 1 Identification and Authentication Refined Enabler description pulling out Identity Management since it is covered in Enabler 7 Management of IA Mechanisms and Assets Reorganized technologies and add material on Authentication Protocols Clarified other text Revised gap analysis to reflect adequacy of current technologies to meet 2008 needs Revised recommendations to reflect results of gap analysis 2 2 Policy-Based Access Control Editorial Clean-up Expanded Functionality Description Technologies content added and subsection structure changed to reflect results of Technology Analysis Results Major Technology Subsections Core RAdAC Assured Metadata Digital Access Control Policy Technologies content added and subsection structure changed to reflect results of Technology Gap Analysis Results Major Technology Subsections Core RAdAC Assured Metadata Digital Access Control Policy Section revised to reflect roll-up of Gap Closure recommendation from the major Access Control technology subsections Also eliminated Standards Technology and Infrastructure subsections as this information subsumed into each major technology subsection 2 3 Protection of User Information Added material on Trusted Platforms Combined previously empty sections on Trusted Platforms and Trusted Operating Systems Added material on Trusted Applications Section was previously empty Added material on Web Security and Application Layer Security Added material on FNBDT and VoIP technologies 2 4 Dynamic Policy Management UNCLASSIFIED FOR OFFICIAL USE ONLY xv UNCLASSIFIED FOR OFFICIAL USE ONLY Updated description based upon revised Notional Architecture which is better aligned with RFCs Technologies content added and subsection structure changed to reflect results of Technology Analysis Results Major Technology Subsections Development of Policies Distribution of Policies Policy Architectures Technology gap information added to reflect results of Technology Gap Analysis Results Major Technology Gaps Expanded policy languages policy modeling and simulation tools policy deconfliction tools and tools or compilers to translate policy language into a device interpretable language Section revised to reflect roll-up of Gap Closure recommendation from the major Policy Management technology subsections Also updated timeline for technologies 2 5 Assured Resource Allocations Technologies content added Major Technology Subsections IA PolicyBased Routing Operational-Based Resource Allocation Integrity of Network Fault Monitoring Recovery and Integrity of Network Management Control Technologies content added along with Technology Adequacy matrix Section revised to include Recommendations list and edited Technology Timeline figure 2 6 Network Defense and Situational Awareness Protect Technologies content added Situational Awareness Maturity content added Technologies content added and subsection structure changed to reflect results of Technology Gap Analysis Results Major Technology Subsections Core RAdAC Assured Metadata Digital Access Control Policy Intrusion Detection Systems content added Intrusion Prevention Systems content added Cyber Attack Attribution - Editorial clean-up based on comments from John Lowry Correlation Technologies Technical Detail content added CND Response Actions content added 2 7 Management of IA Mechanisms and Assets Key Management - Elaborated on the Maturity Section and the Technology Readiness level TRL Audit Management Modified based on comments and feedback These had to do with Maturity subsection through Complementary Technologies Added material on Configuration Management of IA Assets Compromise Management and Inventory Management Modifications and additions were made in order to better represent the Technology Gap Analysis Results Standards Technology Infrastructure and Timelines were all enhanced with additional inputs The tables were reconfigured values assigned and summarized This Table is U FOUO 370 UNCLASSIFIED FOR OFFICIAL USE ONLY xvi UNCLASSIFIED FOR OFFICIAL USE ONLY U EXECUTIVE SUMMARY 371 372 373 374 375 376 377 378 379 380 381 382 U FOUO The Office Secretary of Defense Networks and Information Integration OSD NII tasked the National Security Agency NSA to develop the Information Assurance IA component of the Global Information Grid GIG This GIG IA Capability Technology Roadmap document together with several other documents-- including the GIG IA Reference Capability Document RCD --describe the IA component of the GIG U The GIG IA Capability Technology Roadmap identifies the technologies needed to implement the GIG IA Vision and it provides a partial evaluation of current and indevelopment technologies that can or will be able to support GIG needs As such the objectives of this document are to o U Establish within the context of the GIG IA engineering process an effective methodology to discover and examine relevant technologies for the purpose of providing guidance to GIG program decision makers and GIG research sponsors o U Provide an assessment of the maturity and suitability of relevant IA technologies to meet GIG IA-required capabilities focusing in particular on the 2008 milestones of the transition strategy outlined in the GIG IA RCD o U Identify gaps in standards and technologies that will prevent attainment of GIG IA capabilities and recommend specific actions to take in closing those gaps o U Serve as a means for members of the GIG community and stake holders to gain visibility into the technology roadmap process and provide feedback on appropriate topics such as standards or significant technologies overlooked during the study to date 383 384 385 386 387 388 389 390 391 392 393 397 U In meeting these objectives this document provides decision makers with the information needed to write new or revise existing standards and policies develop implementation guidance make research funding decisions and devise technology development strategies 398 U Scope 394 395 396 399 400 401 402 403 404 405 U The GIG IA Capability Technology Roadmap document presents a fairly complete view of all the technologies that can or should be used to implement IA in the GIG Those that can support the GIG IA vision are examined in detail Results are presented to describe the ability of the most promising technologies to fulfill needed GIG IA capabilities in terms of technical capability maturity development schedule and availability Interdependencies between needed capabilities technology timelines and gaps between capability needs and technology availability are also described UNCLASSIFIED FOR OFFICIAL USE ONLY I UNCLASSIFIED FOR OFFICIAL USE ONLY 416 U FOUO In developing the roadmap the team compared the state trends and forecasts of commercial and government technologies available today against the needed capabilities defined in the RCD Three main categories of information were used The first is documentation and analyses performed by the NSA as part of development of the IA component of the GIG architecture This information includes the GIG Mission Concepts the As Is state of GIG programs and the GIG risk analysis The second category of information includes current IA standards technology trends and forecasts available from commercial sources such as Gartner IDC etc and Government trends and forecasts The third type of information--to be used in subsequent versions of the GIG IA Capability Technology Roadmap document--is previously-determined technology gaps 417 U Results 406 407 408 409 410 411 412 413 414 415 418 419 420 421 422 423 424 425 426 427 428 429 430 U FOUO The analyses were carried out in the context of the capabilities outlined in the RCD and the Transition Strategy In particular the team assessed the maturity and adequacy of the technologies in meeting the 2008 Vision milestones Increment I U The results show that nearly all the Increment I milestones can be achieved if actions are taken immediately to address identified technology or capability gaps The roadmap provides over 75 specific recommendations to address these gaps Recommendations range from monitoring ongoing technologies and standards development efforts to ensure compliance with GIG IA needs to initiating new technology research to support post2008 milestones and standards development efforts We believe that most milestones can be achieved if immediate action is taken on these recommendations U In our estimation five milestones defined in the Transition Strategy are unachievable by the specified dates o U FOUO Limited support for end-to-end resource allocation milestone Operationally-based resource allocation technologies are very immature especially considering the constraints and limitations of a secure Black Core Since there is much research remaining to be done in this area it is our opinion that a limited capability for allocating resources end-to-end will not be available until 2012--four years after the objective date The operational impact is a delay in moving from today's best effort service for all to efficient resource allocation schemes that ensure priority users receive needed services based on mission criticality to efficient resource allocation schemes o U FOUO All human users identified in accordance with GIG ID standard milestone Currently standards neither exist nor are under development for establishing and maintaining unique persistent and non-forgeable identities as will be needed for the GIG Because of the coordination that will be required across multiple communities such standards will not likely be in place to support subsequent technology development in time to meet a 2008 objective however 2010 is an achievable date for this milestone No impact on 2008 operational objectives are expected but delays in meeting 2012 operational objectives is likely These include 1 achieving closer collaboration within Communities of UNCLASSIFIED FOR OFFICIAL USE ONLY 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 II UNCLASSIFIED FOR OFFICIAL USE ONLY Interest COI 2 implementing a global sign-on capability and 3 achieving Risk-Adaptive Access Control RAdAC 448 449 450 451 o U FOUO Over-the-network keying for wired and wireless devices milestone Efforts are planned for developing the needed security technologies However an initial capability will not be fielded until 2010 two years after the deadline Low bandwidth devices such as wireless nodes will not be supported until 2012 and coalition networks will not be addressed until 2016 The operational impact is a continued dependence on manual re-keying which 1 requires greater manpower and costs for handling and safeguarding key material which will become more troublesome as additional IP encryptors are deployed as the GIG matures and 2 causes slower response to key compromises risking more widespread damage o U FOUO Configuration management standards ratified milestone Remote configuration products abound but standards do not yet exist for the secure management of IA-enabled devices Due to the time needed to draft coordinate and achieve consensus among the engineering community such standards will likely not be ratified before 2008 two years later than the milestone called out in the Transition Strategy The operational impact is a delay in achieving a consolidated network view This reduces the overall security posture of the GIG and prevents policy-based network management o U FOUO Audit format and exchange standard ratified milestone Auditing products are available today but the absence of standards holds-up product integration into the GIG Developing the needed audit standards and achieving industry acceptance is not likely to be achieved until 2008 two years after the milestone This will delay the ability to carry-out forensic analysis of attacks and thus hamper computer network defense 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 U Section 3 provides a summary of the identified gaps and recommendations 475 U While this version of the document provides the first comprehensive coverage of the technologies technology assessment is an iterative process As additional capability needs are identified and IA technologies mature subsequent analyses will provide recommendations to re-direct current development efforts and initiate new research as needed to meet the GIG visions These analyses will be documented in subsequent versions of this document which will be issued on an annual basis 476 477 478 479 480 UNCLASSIFIED FOR OFFICIAL USE ONLY III UNCLASSIFIED FOR OFFICIAL USE ONLY 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 1 U INTRODUCTION 1 1 U PURPOSE U FOUO The GIG IA Capability Technology Roadmap document is part of the November 2004 deliverables of the Information Assurance IA Component of Global Information Grid GIG Architecture Office Secretary of Defense Networks and Information Integration OSD NII tasked development of the IA component of the GIG architecture to the National Security Agency NSA U FOUO Since the tasking by OSD NII the NSA has translated the GIG Vision into derived GIG capabilities and associated IA capabilities The GIG IA Reference Capability Document RCD details the IA derived capabilities by describing the general attributes of each capability Thresholds and objectives are then defined for each attribute The thresholds are considered nearterm GIG IA requirements to meet the 2008 Vision while the objectives are the capabilities required to meet the GIG 2020 Vision U FOUO The GIG IA Capability Technology Roadmap identifies the current technology trends in IA and compares the trends against the thresholds and objectives identified in the RCD The result is an availability timeline of anticipated technologies required to support the GIG 2020 Vision U FOUO The GIG IA Capability Technology Roadmap document analyzes the technology trends and technology forecasts both commercial and government available today against the capabilities defined in the RCD The results of the analysis are 501 o U Capability inter-dependencies 502 o U Technology timelines 503 o U Gaps between capability needs and technology availability 504 505 U FOUO The GIG IA Capability Technology Roadmap document also provides background information and analysis to support decision makers with regard to 506 o U New Updated standards 507 o U Infrastructure guidance 508 o U Technology research to fund 509 o U Technology strategy development UNCLASSIFIED FOR OFFICIAL USE ONLY 1-1 UNCLASSIFIED FOR OFFICIAL USE ONLY 510 511 512 513 514 515 516 517 518 519 520 521 1 2 U SCOPE U FOUO Section 2 Information Assurance IA System Enabler and Their Technologies is divided into seven subsections based on the Fundamental System Enablers Each subsection describes the IA System Enabler covers the GIG implications of the System Enabler and describes its related technologies The related technologies define research areas for technology trends and forecasts to support the development of the technology timelines and the capability technology gap analysis U Section 3 Summary contains a discussion of the technology improvement recommendations needed to meet the Transition Strategy defined in the RCD for each Cornerstone When technologies are missing or unable to meet the strategy the discussion highlights the impacted operational capability The four Cornerstones defined in the GIG IA Operational Concepts Overview document are 522 o U Assured Information Sharing 523 o U Highly Available Enterprise 524 o U Assured Enterprise Management and Control 525 o U Cyber Situational Awareness and Network Defense 526 U Section 4 lists acronyms and abbreviations 527 U FOUO Appendix A provides a mapping of technologies to IA System Enablers 528 U FOUO Appendix B Technical View TV -1 for IA contains standards that exist today that had not previously been identified as needed to satisfy capabilities listed in the RCD 529 530 531 532 533 534 535 536 537 538 U FOUO Appendix C TV-2 for IA contains standards that have been identified as needed to satisfy capabilities listed in the RCD but that do not exist today 1 3 U APPROACH U FOUO The primary guiding principle is to achieve the Objective Goals described in the RCD This means identifying the necessary technology evolution to fill the gaps between today's IA technology and what is needed for the GIG 2020 Vision's objective system The IA Risk Assessment helps prioritize--based on security risks--which gaps need to be filled sooner than others The gap analysis must consider the GIG capability timeline to identify the criticality of each gap UNCLASSIFIED FOR OFFICIAL USE ONLY 1-2 UNCLASSIFIED FOR OFFICIAL USE ONLY 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 U FOUO The GIG IA Capability Technology Roadmap document is built upon three main categories of information The first category is documentation and analysis performed by the NSA while developing the IA component of the GIG architecture This information includes the GIG Mission Concepts As Is state of GIG programs and GIG threats as identified by the GIG Risk Assessment activities The GIG Mission Concepts capture the NSA's understanding of the capabilities required by the GIG based on the To Be GIG vision as defined by the GIG 2020 architecture and documentation The As Is input captures the IA capabilities currently planned by ongoing GIG programs such as Net-Centric Enterprise Services NCES GIG Bandwidth Expansion GIG-BE Transformational Satellite TSAT Communications and the Joint Tactical Radio System JTRS The GIG Risk Assessment identifies threats to the GIG that must be countered These threats could be countered in a number of ways including technology standards and policies U FOUO The primary document used in development of the GIG IA Capability Technology Roadmap is the RCD This includes a description of the GIG Mission Concepts and identifies a set of IA Cornerstones which define the high level IA capabilities required to support the GIG Mission Concepts This document describes the technologies needed to support the GIG Mission Concepts and IA Cornerstones but organizes these around the IA System Enablers The technologies are organized by IA System Enablers because most technologies map to a single Enabler while they are associated with multiple IA Cornerstones The Summary of this document describes which technologies are needed to support the system capabilities described in the Transition Strategy for each IA Cornerstone Figure 1 3-1 depicts the GIG Mission Concepts IA Cornerstones and IA System Enablers GIG Vision Operational Mission Concepts Information Assurance Cornerstones IA System Enablers Provide Common Information Services Provide Worldwide Access Assured Information Sharing Provide Dynamic Provide Dynamic Group Resource Formation Allocation Defend the GIG Mgmt Control GIG Networks Resources Cyber Situational Awareness Network Defense Highly Available Enterprise Assured Enterprise Management Control Identification Authentication Policy Based Access Control Protection of User Information Dynamic Policy Management Assured Resource Allocation Network Defense Situational Awareness Management of IA Mechanisms Assets 561 562 Figure 1 3-1 U GIG Mission Concepts IA Cornerstones and IA System Enablers UNCLASSIFIED FOR OFFICIAL USE ONLY 1-3 UNCLASSIFIED FOR OFFICIAL USE ONLY 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 U FOUO The second category of information includes the IA standards in place today technology trends and forecasts available from commercial sources i e Gartner IDC and government trends and forecasts U FOUO The third category of information consists of already defined gaps The expectation is that the process of developing the GIG IA Capability Technology Roadmap document is an iterative one And the gaps identified today will drive various activities to close the gaps These activities could take the form of research product development standards implementation implementation guidance and policy guidance The technology development cycle to satisfy a capability could encompass all the previously mentioned forms U FOUO The document summary contains an indication of the technology improvement needed to meet the transition strategy--defined in the RCD--for each Cornerstone When technologies are missing or unable to meet the strategy the description highlights the impacted operational capability U FOUO Any recommendations could be in the form of the need for research product enhancements new or enhanced standards or new or enhanced infrastructure These recommendations together with other background information and analysis in this document are intended to provide decision makers with the information needed for the following decisions 580 o U Revise or write new standards and policies 581 o U Develop implementation guidance 582 o U Determine direction of research funding 583 o U Devise technology development strategies 584 o U Develop technology implementation plans 585 586 U FOUO Figure 1 3-2 graphically represents the iterative development of the GIG IA Capability Technology Roadmap UNCLASSIFIED FOR OFFICIAL USE ONLY 1-4 UNCLASSIFIED FOR OFFICIAL USE ONLY IA Standards Technology Forecasts Technology Trends Previously Identified Gaps Technology Gap Analysis Recommendations GIG Mission Concepts GIG Threats Define Technology Gaps Gap Gap Gap111 Steps to Gap Evolve from Gap12 Gap 2 Evolve from Gap Gap1n Close Gap1 One analysis Evolve from One Cycle toanalysis Next Onetoanalysis Cycle Next Cycle to Next Maturity As Is Research Product Development Standards Implementation Guidance Infrastructure This figure is U 587 588 Figure 1 3-2 U Iterative Development of the GIG IA Capability Technology Roadmap 589 U As a technology progresses through the development cycle the current state of the development is input into the analysis process The result of the analysis could be the closing of a gap or the identification of additional gaps between capabilities and the technology 590 591 592 593 594 U The work of this document is an iterative process that will require re-analyses as additional capability needs are identified and technologies mature Future releases of this document will be issued on an annual basis UNCLASSIFIED FOR OFFICIAL USE ONLY 1-5 UNCLASSIFIED FOR OFFICIAL USE ONLY 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 2 U IA SYSTEM ENABLERS AND THEIR TECHNOLOGIES U FOUO Information assurance IA is essential to meet the six GIG Mission Concepts Without IA the GIG would not only fail to provide the right information at the right time at the right place in support of warfighting business enterprise information environment and national intelligence but the GIG could also be a haven for other nation states cyber terrorists hackers and malicious insiders to further disrupt operations in support of national objectives U FOUO While a large body of technologies exist to at least partially provide the IA capabilities stipulated by the GIG IA Vision evolution of most existing technologies is needed and new technologies must be invented This section of the document identifies the needed IA technologies--both existing and to be developed Preliminary assessments of technology maturity and identified gaps are presented which should aid decision makers in guiding existing and starting new technology development efforts U For convenience of analysis and organization the IA technologies are categorized and presented in the context of the IA Enablers1 they support This binning into IA Enablers ensures minimal technology overlap and complete coverage of the needed IA capabilities to better support technical gap analysis The IA Enablers used to organize the subsequent subsections are 612 o U Identification and Authentication 613 o U Policy-Based Access Control 614 o U Protection of User Information 615 o U Dynamic Policy Management 616 o U Assured Resource Allocation 617 o U Network Defense and Situational Awareness 618 o U Management of IA Mechanisms and Assets 619 620 621 622 623 624 625 626 627 628 U FOUO Each subsection presents all aspects and benefits of the associated IA Enabler The IA Enabler itself is described and key features of the IA Enabler are defined An overview of the supporting types of technologies is presented organized around the IA Enabler Each technology is described in sufficient detail to support gap analysis Finally results of the technology gap analyses are presented and technology development timelines and recommendations for the IA Enabler are provided The technology timelines showing the date that each technology will be available for integration into the GIG are optimistic they are based on ideal circumstances e g adequate funding and appropriate technical manpower are available to begin and execute the recommended research or existing developments continue as currently planned Adverse budgetary decisions will obviously delay the availability of the technologies for use 1 U The seven IA Enablers are core constructs that together provide the IA component of the GIG These serve as architectural building blocks for enabling the GIG Mission Concepts UNCLASSIFIED FOR OFFICIAL USE ONLY 2-1 UNCLASSIFIED FOR OFFICIAL USE ONLY 629 630 631 632 633 634 635 636 U FOUO A fairly comprehensive description is presented for each technology but only to the extent needed to support recommendations for subsequent development efforts Details of specific product implementations are avoided where possible to avoid conferring vendor endorsement which distracts from the purpose of this analysis Rather numerous technology implementations were researched and considered and only one or a small number were selected for inclusion in the roadmap according to authors' opinions of how well these implementations represent the state of practice In this context specific items included for each technology are as follows o U Technical details Description of the technology in terms of technical characteristics features and theory of operation Consistent with the goals of the roadmap the description may cover the superset of capabilities represented by the combination of a few related implementations or products o U Usage considerations Discussion of potential implementation issues peculiar to the technology and anticipated operating environments advantages of the technologies and risks--in terms of potential threats and attacks--that might be incurred in employing the technology o 652 U Maturity Description of the current state relative to the goal capability of the technology itself This is not to be confused with the GIG IA capability that the technology would support While it is desirable to specify maturity of every technology in terms of Technology Readiness Level2 TRL the roadmap does not attempt to do so because either a TRL could not be found and there is insufficient information on which to base a specific estimate or the analysis is based on multiple products implementations that are each at different stages of development Instead then the overall development stage of each technology is assessed and described by one of three maturity level terms 653 o U Early refers to technologies that are in the research or analysis phase corresponding to TRL range 1-3 o U Emerging refers to those in the initial prototyping and lab demonstration phase TRL range 4-6 o U Mature refers to technologies that are undergoing operational demonstration production and deployed operations TRL range 7-9 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 654 655 656 657 658 659 660 U In addition specific TRLs are provided where they could be determined with a fair degree of certainty 661 o U Standards Discussion of standards that are pertinent to the technology Included are existing standards or those that will need to be developed in order to support the technology o U Costs limitations Discussion of the costs and limitations the technology would pose on the GIG architecture and connected systems when they are significant Examples are 662 663 664 665 2 U There are nine TRLs defined in Appendix 6 of DoD Instruction 5000 2 ranging from basic principals observed and reported level 1 to actual system proven through successful mission operations level 9 UNCLASSIFIED FOR OFFICIAL USE ONLY 2-2 UNCLASSIFIED FOR OFFICIAL USE ONLY where the technology would impose significant operational manpower burden amount caliber and training extraordinary procurement costs undue complexity unusual integration difficulties adverse or significant impact on warfighting operations or significant communications bandwidth or processing overhead 666 667 668 669 670 o U Dependencies List of related items such as other technologies and data upon which the technology must depend in order to provide the described capability o U Alternatives List of possible alternative technologies or techniques that could support the IA Enabler either for early adoption to provide an interim capability or as a substitute if the described technology does not mature o U Complementary techniques List of additional technologies or techniques that improve or enhance the described technology 671 672 673 674 675 676 683 U FOUO To facilitate discussions of the gap analyses one or more matrices are provided for each IA Enabler These are intended to summarize the explanations and show at a glance how adequately the analyzed technologies meet the capabilities defined by the IA Enabler for the 2008 GIG implementation Increment 1 Technologies are combined into categories for simplification The adequacy level determined by how well the sum of the assessed technologies in each category addresses each IA Enabler attribute is described in Table 1 3-1 Capability attributes from the RCD are included in the matrices for reference 684 Table 1 3-1 U Definitions of Technology Adequacy Levels 677 678 679 680 681 682 This Table is U Adequacy Indication Level Not Applicable Unknown Completely uncovered N A White Light gray Some coverage but insufficient Light black white grid Fully adequate Solid black Definition There is no expectation that the technology category could support the IA Enabler attribute Technology investigation not completed e g no result presented No technology is available and no research is underway to develop the needed technology ies to address the IA Enabler attribute R D is underway that should lead eventually to at least partially covering the IA Enabler attribute and anticipate that the resulting technology will be available in time to meet GIG IA milestone dates OR A technology exists in the category that partially meets the needs of the IA Enabler attribute now but additional technology R D is needed to either enhance it or add to it in order to fully satisfy the attribute OR Taken together a combination of existing products or technologies in the group could satisfy the IA Enabler attribute now but additional work is needed to combine the technologies in order to fully satisfy the attribute Technology or a compatible combination of technologies is available now that fully meets all aspects of the IA Enabler attribute OR Technology development is underway and on schedule to fully satisfy the attribute at the time needed This Table is U 685 UNCLASSIFIED FOR OFFICIAL USE ONLY 2-3 UNCLASSIFIED FOR OFFICIAL USE ONLY 686 687 688 689 690 691 692 693 694 695 696 U FOUO Table 1 3-2 shows an example technology adequacy matrix for the Policy Based Access Control Enabler Here Digital Rights technologies are needed only to support the Object Life Cycle and Protection Profile attributes This is indicated in the table by the black grid and gray shading under Digital Rights technologies under the Object Life Cycle and Protection Profile IA attributes and N As under the Digital Rights technologies for all other IA attributes Access Control Policy technologies are needed to support all IA Attributes as shown by the black grid and gray shading The white intersection of Access Control Policy technology and the Protection Profiles attribute indicates technologies are neither available nor research underway to satisfy the Protection Profiles attribute U FOUO A matrix filled with black and n a entries would reflect the ideal situation where all IA attributes are satisfied with technologies Table 1 3-2 U Example of a Technology Adequacy Matrix 697 This Table is U Technology Categories IA Attributes Core Access Digital Control Access Rights Policy Control Required Capability RCD attribute Risk Need Determination N A IAAC4 Math model N A IAAC4 Decision logic N A IAAC1 IAAC4 IAAC7 N A IAAC4 Exception handling N A IAAC5 Conflict resolution N A Ontology N A Object Lifecycle IAAC8 Protection Profile IAAC9 This Table is U UNCLASSIFIED FOR OFFICIAL USE ONLY 2-4 UNCLASSIFIED FOR OFFICIAL USE ONLY 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 2 1 U IDENTIFICATION AND AUTHENTICATION U FOUO I A mechanisms provide critical IA foundations toward achieving the GIG Vision of assured information sharing In the assured sharing model information is exchanged among entities e g individuals devices on the enterprise infrastructure Similarly services are shared among entities on the enterprise infrastructure U FOUO Access to information or services is based upon several factors including entity properties their authentication mechanism properties of the objects to be accessed the IT components the environment in which the entities exist and the access control policy implemented All of this is based on the ability to uniquely identify the entities participating in the exchange and the authentication mechanisms used by the entities participating in the transaction The ultimate goal is to support a SSO process independent of the many roles and privileges of the entities involved U FOUO The Identity and Authentication I A Enabler is the sum of the mechanisms and processes that result in a composite level of trust of an entity that can be used in all access control decisions on the GIG during a given service request or login session Entities that need to be identified and authenticated include human users workstations networks services and other resources 719 U FOUO The level of trust of an entity is referred to as its I A Strength of Mechanism SoM Score Each service request is examined to determine how resistant the authentication of that request is to impersonation or forgery The likelihood that a service request was forged depends on both the difficulty of forging the request as measured by the I A SoM and the motivation and ability of the adversary 720 U FOUO To support I A SoM scoring on the GIG it is necessary to develop the following 715 716 717 718 o 723 U FOUO Standards and technical requirements for assigning assurance levels for each of the following factors that affect I A strength and for deriving the I A SoM score from those factors 724 o U FOUO Strength resistance to compromise of identity proofing during user registration 726 o U FOUO Strength of the user's authentication token 727 o U FOUO Strength of the protocols used to authenticate service requests 728 o U FOUO Strength of the user's operating environment e g clients IT components and network 721 722 725 729 730 o U FOUO Mechanisms for conveying to services the assurance level of a specific service request and of the IT components used to generate and process the request o U FOUO Policies that make use of I A SoM scores and other assurance measures in the decision to grant or deny access to particular resources 731 732 733 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-1 UNCLASSIFIED FOR OFFICIAL USE ONLY 734 735 736 2 1 1 U GIG Benefits due to I A U FOUO The Information Assurance constructs used to support I A provide the following services to the GIG o U FOUO Provides assurance that every entity participating in a GIG transaction is who he she it claims 739 o U FOUO Enables accountability for all GIG actions 740 o U FOUO Accommodates varying trust levels for users and IT components by identifying how much an entity can be trusted o U FOUO Enables capability for single sign-on SSO once the identity is recognized and trusted throughout the GIG 737 738 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 2 1 2 U I A Description U FOUO Unique identity and identity proofing are fundamental to the I A process Unique IDs are created for all entities e g individuals devices services Identity proofing refers to the methods used to prove an individual's or devices identity before issuing a Unique ID Identity proofing mechanisms for individuals could range from providing no proof of identity presented to requiring multiple picture IDs be presented in person by the individual receiving the Unique ID The identity registered for an individual is unique and remains constant despite changes of that individual's name or other attributes More information on Identity Management is provided in Section 2 7 Management of IA Mechanisms and Assets U FOUO The authentication mechanism used in conjunction with this ID is also critical to granting access to shared data and resources The strength of the authentication mechanism measures resistance to attempts to guess sniff extract or otherwise compromise the entity's authentication material Current authentication mechanisms for human individuals include 757 o U User ID and password 758 o U Use of software PKI certificates to provide a verifiable identity 759 o U Use of a Hardware Token that contains an entities PKI certificate and on-board mechanisms to verify an entity's identity o U Biometrics to unlock a token that protects the non-forgeable PKI certificate containing the identity that is shared in a protected manner during authentication exchanges 760 761 762 763 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-2 UNCLASSIFIED FOR OFFICIAL USE ONLY 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 U FOUO The User Profile is a logical collection of information associated with a user but it is not necessarily stored in a single location The identity management system must store a basic user record containing the unique ID and the core identifying information that was verified e g birth certificate information driver's license number or collected biometrics during identity proofing Other information that is logically part of the user profile must be strongly bound to the user's unique ID but may be stored separately For example public key certificates used to authenticate the user may be stored in a hardware token or certificate repository role information may be stored as signed attributes in a privilege server contact information may be stored in a user directory and subscription information may be stored in a discovery server U FOUO After registration a user may log into a GIG asset using the authentication token issued to that user At the conclusion of the login process an authenticated session would exist which has an associated I A SoM session score Authentication information for service requests can either be derived from the user's login session or generated by the user's token for each request When the service provider can directly authenticate the user's original request the request assurance score can be determined directly based on the user and client assurance But in architectures where requests are passed through multiple providers each of which can authenticate only the preceding requestor the originator's assurance score is decreased at each intermediate processing point In either case the final request assurance score is determined based upon the following factors 783 o U FOUO Identity Proofing method used to register the user 784 o U FOUO Token used to authenticate the user's identity e g password software certificate hardware certificate biometrics o U FOUO Authentication mechanism used for the request or session e g unbound identity assertion Secure Session Layer SSL session signed request o U FOUO The properties of the device used to logon based upon their configuration and management of the devices some devices may not be as trusted as others and each device in a trust chain between the originator and the provider o U FOUO The user's location or operating environment e g highly trusted network remote access via a computer on the Internet 785 786 787 788 789 790 791 792 793 794 795 796 797 U FOUO Some participants in the GIG may require the entity and session to be periodically re-authenticated For example if the data being retrieved is critical mission data then the data sharer may want to re-validate that the parameters of the original session login are still valid This may entail a requirement for the data requestor to provide their biometric data periodically to ensure they are still present UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-3 UNCLASSIFIED FOR OFFICIAL USE ONLY 798 799 800 2 1 3 U I A Technologies U FOUO The following technology areas support the Identification and Authentication Enabler 801 o U Authentication Tokens 802 o U Biometrics 803 o U Device Service Authentication 804 o U Authentication Protocols 805 o U Authentication Confidence 806 o U Single Sign-On SSO 807 U The three basic means of user authentication and what they are based upon are 808 o U Authentication by knowledge what a user knows e g a fixed memorized password 809 o U Authentication by characteristic what a user is e g a biometric 810 o U Authentication by ownership what a user has e g a token 811 812 813 814 815 816 U The main disadvantage of fixed passwords is that they are vulnerable to various attacks including social engineering sniffing e g network and or electromagnetic emanations dictionary attacks maliciously planted Trojan-horse software etc Once a user's fixed password is compromised it is impossible to detect subsequent system accesses by malicious parties U Section 2 1 3 1 discusses the token technologies that support authentication by ownership Biometric technologies are discussed in Section 2 1 3 2 817 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-4 UNCLASSIFIED FOR OFFICIAL USE ONLY 818 2 1 3 1 U Authentication Tokens 819 2 1 3 1 1 U Technical Detail U Authentication tokens provide a means for a user to dynamically generate a single-use onetime password OTP every time a remote secure system is accessed This thus avoids fixed password vulnerabilities Tokens may be implemented in either hardware or software 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 U A hardware token is a device which the user in some manner employs to interface either physically or indirectly through user interaction with a local client processor e g a PC requiring secure access to a remote server processor or system This hardware token contains the critical security parameters for the authentication process U A software token is implemented within the local client processor itself and thus depends upon the security and trustworthiness of the client's operating system Examples of standard OTP authentication protocols that are functional equivalents of software tokens include S Key OPIE One-Time Passwords in Everything http inner net opie and SSH Secure Shell U Most implementations of authentication tokens require the user to enter a PIN personal identification number to locally unlock the token functionality and thus are not subject to network sniffing attacks A PIN can be viewed as a primitive fixed and memorized password A biometric also can be used to unlock token functionality This combination of independent authentication factors provides a stronger authentication mechanism and prevents system compromise if a hardware token is lost or stolen U Tokens function by using either Symmetric Key Authentication a single shared secret key known at both the client and server or Public Key Authentication where the client knows only the private key and the server knows the public key All authentication tokens work by producing dynamic single-use OTPs based upon credentials unique to the issued user and upon a cryptographic algorithm or hash function Symmetric Key Authentication and Public Key Authentication are further explained in Section 2 1 3 4 which describes authentication protocols in general U There are several basic token authentication modes under symmetric key grouped within the categories of Asynchronous and Synchronous 2 1 3 1 1 1 U Asynchronous Token Authentication Mode U Challenge-Response In this mode the user sends his username to the server in order to identify the shared secret key The server generates a random challenge and sends it back to the user The user keys the challenge into the token This challenge is then cryptographically processed with the secret key in order to generate a response The response is then entered onto the client and sent back to the server The server independently does the same process and compares results U This mode is 'asynchronous' because there is no time-based requirement that the response arrive at the server within a prescribed and limited amount of time nor is the response a function of any underlying event counter UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-5 UNCLASSIFIED FOR OFFICIAL USE ONLY 856 2 1 3 1 1 2 857 2 1 3 1 1 2 1 U Time-driven U In this mode both user token and server generate an OTP based upon the shared secret key and an internal network-synchronized clock value In order to permit network transmission time variations the clock value resolution may be on the order of 60 seconds or less to allow for clock drift An example of this token type is SecurID by RSA The user reads the varying timebased OTP from the LCD display of the hardware token See Figure 2 1-1--Note the option for a 10-digit numeric keypad for entry of PIN to enable the token The user then inputs this number onto the client processor and it is sent to the server where it is compared with the server's expected value A match yields successful authentication 858 859 860 861 862 863 864 865 U Synchronous Token Authentication Mode This is figure is U 866 867 Figure 2 1-1 U Examples of time-driven hardware tokens 868 2 1 3 1 1 2 2 U Event-driven U In this mode instead of using time to create an OTP an authentication event counter value is used with the shared secret key to generate the one-time password 869 870 871 872 873 874 875 876 877 878 879 880 881 U Time and event driven modes are examples of response-only authentication schemes since the process only requires one-way transmission from user to server A third version of responseonly authentication is accomplished by both the user token and server This creates a response from a hidden random challenge rather than a mere time or counter value which could be viewed as more predictable and certainly as monotonically increasing This challenge is derived from the previous challenge which is ultimately derived from some random seed value created at token initialization and known to both token and server U Authentication modes could be combined e g challenge-response time-driven eventdriven to provide stronger authentication just as stronger authentication is achieved by combinations of independent authentication factors password PIN one or more biometrics token the UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-6 UNCLASSIFIED FOR OFFICIAL USE ONLY 882 2 1 3 1 2 U Usage Considerations 883 2 1 3 1 2 1 U Implementation Issues U Hardware tokens are implemented in a variety of physical form factors Those that require only indirect user-interaction i e user observation of displays on the token followed by manual entry of data onto the local client processor include pocket-style calculators and key fobs Hardware tokens that connect directly to the client processor include smart cards and Universal Serial Bus USB tokens An example of smart card authentication tokens is the DoD Common Access Card CAC which can also be used as a photo ID card and for physical access control 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 2 1 3 1 2 2 U Advantages U In general authentication tokens have the basic advantage that they can be used over public networks and are not subject to compromise by hostile network sniffing since the authentication information is cryptographically based and unpredictable i e not subject to standard replay attacks U Hardware tokens are inherently resistant to social engineering attacks since it is very unlikely that an innocent user would provide an attacker with both the token and its enabling PIN Another obvious distinct advantage of hardware tokens is their portability which enhances the user's mobility and capability to authenticate remotely by home PCs laptops or personal digital assistants PDA U Smart cards and USB tokens since they interface directly with a user client offer the advantages that they can be used as a safe repository for sensitive personal data such as PKI credentials passwords and various account numbers Smart cards have onboard processors which can do critical authentication processing e g generating a cryptographic digital signature without being observed by a potential attacker as opposed to the alternative of doing the processing on a client processor which may have been compromised by Trojan horse software Protection of sensitive information on the smart card when it is not being used is accomplished by tamper-resistant--both physical and electronic--encryption of any stored data and the required use of an enabling PIN 2 1 3 1 2 3 U Risks Threats Attacks U A basic disadvantage or risk of hardware tokens is that they can be lost or stolen However in the case of smart cards such as the DoD CAC the privileges of a lost card can be revoked or canceled by the centralized PKI infrastructure authority In addition unless the enabling PIN is also known by the malicious possessor of a lost stolen token that token can not be used in a compromising manner U In the deployment of any authentication token system especially in the case of an organization like the DoD with large numbers of geographically dispersed users secure token distribution requires a robust proof of delivery POD mechanism e g by manual signature for non-repudiation UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-7 UNCLASSIFIED FOR OFFICIAL USE ONLY 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 U Public key authentication systems also suffer from potential risks if they have weak public key management or certification These systems rely on the clear and verifiable binding between a user identity and the associated public key by the public key certificate Only a trustworthy and reliable certification registration authority can assure that the certificate database is valid and up to date U Another potential risk is that a hardware token can be left enabled at a client workstation which could allow a malicious intruder to masquerade as the valid user A potential solution to this might be to require periodic biometric checking re-authentication U Besides the risk of potential attack where a hardware authentication token is physically taken from the valid user--through loss theft or misplacement--there are further potential attacks on the authentication process at a distance from the actual token itself The classic attack would be the man-in-the-middle attack against the collaborative process between the remote user and the centralized authentication server In this case the attacker would have access to the communications path somewhere on the network between the communicating parties A man-inthe-middle could inject delete or alter data that is sent in either direction However due to the unpredictable cryptographically-based nature of the authentication responses sent by the user to a server it is unlikely that a man-in-the-middle could predict a future authentication value response and thus could not gain access to the system U Another attack that could be mounted at a distance from the hardware token would be planting malicious attacker Trojan horse modifications in the client workstation This could be partially avoided by having the authentication process done primarily within the token itself and not allowing the shared symmetric secret key or private key to ever be transmitted off the token Finally a guaranty that this secret key is safe can be made if some form of physical tamper resistance is built into the token itself Such tamper resistance would also prevent alterations to any software that operates on the token itself U Of course a token and its associated authentication function can be assumed to be secure only if the main system authentication server is non-hostile and has not been compromised in any manner Thus since the server is potentially the worst location for single point failure the most effort should be expended in safeguarding this resource 2 1 3 1 3 U Maturity U Authentication token technology has matured significantly especially when each subtechnology is viewed as an independent component Current and future work needs to be done in integrating the sub-technologies along with the complementary authentication enhancing technologies such as biometrics An example of this is the DoD CAC with added biometric functionality In summary the Technology Readiness Level of tokens can be thought of as Mature TRL 7 -9 2 1 3 1 4 U Standards U There are a variety of standards arenas--both formalized and actual--which play a role in the development and evolution of authentication tokens and their underlying protocols and algorithms UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-8 UNCLASSIFIED FOR OFFICIAL USE ONLY 959 960 961 962 963 2 1 3 1 4 1 U Hardware Token Standards U Organizations and arenas responsible for developing standards related to smart card technology and other tokens include RSA Labs Public-Key Cryptography Standards PKCS Microsoft Crypto API CAPI Personal Computer Smart Card PC SC and the ISO International Organization for Standardization These standards are listed in Table 2 1-1 964 Table 2 1-1 U Hardware Token Standards 965 This Table is U Name Description RSA Labs PKCS Standards PKCS #11 PKCS #12 PKCS #15 Cryptographic Token Interface cryptoki Standard specification of an application programming interface API for cryptographic token devices Personal Information Exchange Syntax specifies transfer syntax for personal identity information such as private keys and certificates etc Cryptographic Token Information Format Standard ensures interoperability of multiple vendor implementations Microsoft API Standards CAPI Cryptographic Application Programming Interface standards PC SC Workgroup Specifications 1 0 PC SC Workgroup Specifications 2 0 Interoperability Specs for Smart Cards and PCs platform and OS independent PC SC Standards Updated enhancements including contactless wireless RF cards ISO Standards ISO IEC 7810 ISO IEC 7811 ISO IEC 7812 ISO IEC 7813 ISO IEC 7816 ISO IEC 10373 ISO IEC 10536 ISO IEC 14443 ISO IEC 15693 Identification Cards - physical characteristics ID Cards - Recording techniques ID Cards - Identification of issuers Financial transaction cards ID Cards with contacts ID Cards - Test Methods Contactless ID Cards - Close Coupled Contactless ID Cards - Proximity Mifare cards - 1-inch range Contactless ID Cards - Vicinity I CODE cards - 5-inch range This Table is U 966 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-9 UNCLASSIFIED FOR OFFICIAL USE ONLY 967 968 969 970 971 972 973 974 975 976 977 978 U The RSA PKCS specifications originated in the early 1990s from RSA Labs and though from a single company versus a collaborative standards body have been subsumed into and adopted by numerous de facto and formalized standards The PC SC specifications are both PC platform and PC operating system independent while also specifying low-level device interfaces The updated version is addressing contactless wireless smart card specifications The ISO smart card standards are derived from the basic ISO identification card standards Similar to the RSA PKCS #11 Microsoft's CAPI for Windows defines application programming interface API for accessing tokens and letting vendors integrate security products into the OS--without token developers having to write separate drivers for each application 2 1 3 1 4 2 U DoD Common Access Card U An emerging standardized authentication token within the Department of Defense is the DoD Common Access Card CAC an example of which is shown in Figure 2 1-2 D O D C o m m o n A c c e ss C a rd This is figure is U 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 Figure 2 1-2 U DoD Common Access Card U The characteristics of the DoD CAC will define a de facto smart card standard merely by virtue of the vast number of CACs that will eventually be issued to reserve and active military DoD civilian employees and DoD contractors on DoD networks such as the emerging GIG U The main directed requirements of the CAC were that it provide for encryption of secure messages digital signature for non-repudiation hardware token capability for storage of cryptographic keys for use on unclassified networks and flexible smart card technology to support the efficient evolution of DoD identity-based business processes Additional requirements were that a CAC work as a photographic identification card provide for facility physical access control provide logical access with strong Identification authentication to unclassified DoD networks and take advantage of the existing card-issuance infrastructure Hardware token smart cards are a solution that satisfies all of these requirements U In order to support legacy applications the CAC includes both bar codes and magnetic stripes Current work is being done to include contactless wireless versions of the CAC for easy facility physical access applications UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-10 UNCLASSIFIED FOR OFFICIAL USE ONLY 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 U The CAC is a credit-card sized smart card that conforms to ISO IEC standards 7810 and 7816 The basic processor CPU on the current version card is an 8-bit microcontroller with newer versions having up to 32-bit RISC reduced instruction set processors the memory is 32K EEPROM plans for 64K and the operating system is a Java API application programming interface to allow for a multiple vendor open architecture Crypto processing is done by an 1100-bit advanced crypto engine and a 112-bit 192-bit DDES-ECC crypto accelerator Double DES DDES is used instead of single DES which was originally used in many commercial token implementations CAC vendors include Gemplus Axalto and Oberthur The DoD implanted 3 Java applets on the card--the PIN security applet the PKI applet and a generic personal information management applet DoD is currently looking at adding an enhanced biometric e g fingerprint thumbprint capability directly onto the CAC U Issuance of a new CAC to a DoD employee requires a user fingerprint template collection and verification and self-selection of an enabling PIN At this time about 82 percent of the over 4 4 million potential CAC recipients have been issued their cards with cards being issued at up to 12 000 a day The CAC issuance infrastructure includes about 1 600 stations at more than 900 sites around the world U The DoD also plans to develop a central issuance facility In order to complement the issuance of CACs the DoD has already purchased more than 2 million stand-alone card readers for use with existing PC computers with new PCs being purchased with embedded card readers U Due to the extremely large number of DoD CACs being distributed and due to their application in sensitive areas and operations much thought is going into the development and evolution of the CAC Thus it can be viewed as a robust de facto implementation standard of a smart card token It and its descendants will be important tokens in the future GIG 2 1 3 1 5 U Cost Limitations U The cost and limitations of authentication tokens is based on both the token functionality itself and upon the required supporting infrastructure--both local as in the case of requiring peripheral card readers for smart card tokens and centralized as in the case of a PKI Public Key Infrastructure with its associated Certificate Authority CA U The concept of a PKI is very straightforward but in order to implement a PKI that adaptively scales to support a large user population large investments must be made and complexities overcome One cost advantage of the DoD CAC smart card is that by serving multiple legacy functions it will enable the DoD to eliminate and phase out many legacy identity cards and thereby provide a larger than might be expected return on investment U Symmetric single-key software tokens implemented on a user client PC are significantly cheaper than the equivalent hardware token implementation since there is no hardware cost beyond the already existing PC An imputed lower mental cost to the user is that much of the authentication process is hidden from the user Another cost of software tokens is the lack of operating system independence UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-11 UNCLASSIFIED FOR OFFICIAL USE ONLY 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 U Depending on how complex and inherently costly one wishes to make either smart cards or USB tokens when doing public key authentication one can tradeoff the processing demands placed upon the token device and the host client In the cheapest and simplest token it can simply act as the repository of the private key that it can export to the client which would then do any required cryptographic processing The low monetary cost of this approach however incurs potentially high security risks and costs since the client PC must now be fully trusted to be impervious to malicious attacks i e Trojan horses U The alternate to this approach is to do cryptographic processing on the token itself as on the DoD CAC This may be done by either first generating the needed private key on a client workstation and then storing it on the token Off-Token Key Generation or by generating the private key only on the token itself On-Token Key Generation U The cost limitation of Off-Token Key Generation is that it may temporarily expose the private key to potential hacking attacks on the client although another advantage is that the user can make a backup copy of the key for disaster recovery purposes The potential cost or limitation of On-Token private key generation is that if the token suffers a hardware failure the private key may be lost forever An example of a vendor product that does on-token key generation is the cryptographic smart card by Datakey Inc U Despite their ease of security and convenience in carrying on one's key-chain the fact that they can do onboard processing and storage and the prevalence of USB ports on client computers there are several inherent limitations and costs to USB authentication key-fob tokens USB ports are often very inconveniently located on PCs i e on the back panel of a PC tower USB ports may not be physically robust enough to avoid being damaged by the repeated daily or more often interface with a USB token And finally a USB token is not large enough to easily incorporate a photo ID U The DoD CAC has several current limitations It was developed originally for use on the NIPRNet and not on systems that require higher assurance For example the CAC is not NIAP evaluated specifically a High Assurance Protection Profile does not currently exist and it contains foreign COTS hardware and software e g one of the vendors is Gemplus a French manufacturer U The GIG will require higher assurance tokens that provide a way to present identity credentials and authentication for access to classified information which is an option not currently supported by the CAC The three primary Java security applets access control PIN security PKI support generic information container management need to undergo full high assurance security evaluation U Plans are also being made to utilize asymmetric public key cryptography for the purpose of transport of keys and integrate this capability into the CAC issuing system by December 2006 The January 2008 goal to deliver a new DoD CAC compliant high assurance token that is manufactured only in the U S with only U S -developed software will provide a CAC that delivers high assurance Identification Management capabilities for the full suite of GIG customers including DoD the Intelligence Community and International Partners This high assurance token will be able to carry classified information and Type I keying material UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-12 UNCLASSIFIED FOR OFFICIAL USE ONLY 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 2 1 3 1 6 U Dependencies U Further evolution of the DoD CAC to include full biometric integration and contactless wireless RF capability will rely on the full developing and maturing of the PC SC Workgroup Specifications 2 0 Biometric integration also depends upon acceptance of a biometric technique e g fingerprint 2 1 3 1 7 U Alternatives U The basic stand-alone alternatives to tokens what you have are biometrics what you are and simple fixed passwords what you know 2 1 3 1 8 U Complementary Techniques U Though biometrics and simple passwords or PINs can be viewed as mere alternatives to authentication tokens they are better viewed as adjuncts or complementary techniques that when combined together have a multiplicative effect on an overall system security Biometric data templates can be stored securely on a smart card token rather than on the client workstation There is even the possibility of integrating an actual biometric fingerprint thumbprint reader onto the surface of a smart card thus eliminating the need for additional peripheral hardware U The concept of an all in-one security device is an example where complementary techniques are combined Security devices can embed many if not all base authentication methods The intent is to create highly flexible and versatile security devices such as for authentication encryption signing secure storage and physical access Comprehensive functionality and personalization e g personal storage are essential to encourage users to embrace security devices such as a token on a key chain or a smart card in a wallet By supporting multiple strong authentication methods the same device becomes capable of interacting with a wide range of networks and applications U The remote access scenario shows the benefit of integrating multiple authentication methods into one single security device Figure 2 1-3 shows a USB token with either a PKI-enabled SIM chip inside or a smart card with a display integrated within the reader to display the OTP With this hybrid device a user roams over a Wi-Fi network using SIM-based authentication Once on the public network the user can initiate a virtual private network VPN connection to a gateway using the RSA private key and certificate which are stored in the token Once the VPN tunnel is established the user can log on to a portal to access the user's account through a Web interface--using the One Time Password generated by the token UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-13 UNCLASSIFIED FOR OFFICIAL USE ONLY This is figure is U 1106 1107 Figure 2 1-3 U Example of a Hybrid Device 1108 U An additional complementary technique would be mere physical access controls to secure facilities Though this serves more as a member of an authorized group identification authentication than as an individual identification authentication it is an important first barrier that must be overcome before a malicious intruder can get anywhere close to sensitive IT equipment Indeed the DoD CAC serves the dual purposes of both facility access with both the photo ID feature and legacy magnetic stripe for card swipe-controlled physical accesses and the follow-on required identification authentication for use of sensitive IT network resources Other physical access control technologies are being researched that use facial scans to enable access to computer resources An advantage to this approach is that it is a continual authentication so each time the user leaves the computer locks the user's screen When the user returns to the computer the facial recognition authentication is repeated to re-authenticate access 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 2 1 3 1 9 U References U One Time Passwords in Everything http inner net opie by Craig Metz 1122 U PKCS Public-Key Cryptography Standards http www rsasecurity com rsalabs node asp id 2124 RSA Labs 1123 U PCSC Workgroup http www pcscworkgroup com 1124 U Multi-Biometric Verification Demonstration Category Secure Access to Physical Systems Devices and Spaces Vijayakumar Bhagavatula Dept of ECE Carnegie Mellon 1121 1125 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-14 UNCLASSIFIED FOR OFFICIAL USE ONLY 1126 2 1 3 2 U Biometrics 1127 2 1 3 2 1 U Technical Detail U A biometric is a measurable physical characteristic or personal behavioral trait that can be used to recognize the identity--or verify the claimed identity--of an enrollee 1128 1129 Acquisition device Sample Sample Processing Processing Reference Reference Template Template Matching Matching Created from multiple samples at enrollment Score Score Not yes no as with a password Trial Trial Template Template Threshold Threshold Decision Decision This is figure is U 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 Figure 2 1-4 U Biometric System Block Diagram U Two processes are necessary for any biometrics system enrollment and verification Enrollment involves recording the user's biometric and storing it in the system as a template Verification is the comparison of a user's biometric against the reference template to verify a user's identity The enrollment process typically happens during system initialization or when a new user is added to the system U Biometric systems all perform the same basic process for verification as illustrated in Figure 2 1-4 First a biometric acquisition device reads the user's biometric and creates a trial template A template is data that represents the biometric measurement of an enrollee used by a biometric system for comparison against previously or subsequently submitted biometric samples The trial template is then compared against a reference template previously stored during the enrollment process U If biometrics is used with other authentication factors the reference template for the user's claimed identity can be retrieved and compared against the trial template to verify the user's identity this is referred to as an authentication mode If a biometric is the only authentication factor the trial template must be compared against all reference templates in the database until a match is found this is referred to as a recognition mode The matching process is based on a scoring system The system must judge whether there is a close enough match between the trial and reference templates UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-15 UNCLASSIFIED FOR OFFICIAL USE ONLY 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 U The accuracy of a system is measured by its False Match Rate FMR and False Non-Match Rate FNMR The FMR is the probability that the biometric system will incorrectly identify an individual or will fail to reject an impostor The FNMR is the probability that the biometric system will fail to identify an enrollee or verify the legitimate claimed identity of an enrollee Generally the lower the FNMR the easier the system is to use while the lower the FMR the better the security of the system These characteristics are typically configurable by an administrator For a biometric system that uses just one template matching attempt to decide acceptance FMR is the same as False Acceptance Rate FAR When multiple attempts are combined in some manner to decide acceptance FAR is more meaningful at the system level than FMR For a biometric system that uses just one attempt to decide acceptance FNMR is the same as False Rejection Rate FRR When multiple attempts are combined in some manner to decide acceptance FRR is more meaningful at the system level than FNMR U During enrollment some biometric systems perform multiple scans of the same biometric to create the reference template This can create a more accurate reference template and help reduce the FMR and FNMR U Accuracy is also driven by the amount of data collected or the number of data points collected in the reference sample This also contributes to storage requirements more data points means more storage capacity is required which translates into more cost U Reliability is affected by aging and environmental conditions Injuries and background noise could affect the accuracy of the devices and increase the FNMR 1175 U There are many biometric factors that can be used They are generally broken down into two categories physiological and behavioral Physiological biometrics is usually derived from a person's anatomy and are difficult to alter Examples include fingerprints iris and hand print Behavioral biometrics are derived from an action performed by an individual Behavioral biometrics are usually easier to alter but can be perceived as less intrusive by the user Examples of behavioral biometrics include signature voice recognition and gait 1176 2 1 3 2 1 1 U Physiological Biometrics 1177 2 1 3 2 1 1 1 U Fingerprint Recognition U The patterns of friction ridges and valleys on an individual's fingertips are unique to that individual For decades law enforcement has been classifying and determining identity by matching key points of ridge endings and bifurcations Fingerprints are unique for each finger of a person including identical twins 1170 1171 1172 1173 1174 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 U Fingerprint recognition is the most widely available biometric technology Fingerprint recognition devices for desktop and laptop access are now widely available at a low cost from many different vendors With these devices users no longer need to type passwords--instead only a touch provides instant access Fingerprint systems can also be used in identification mode Several states check fingerprints for new applicants to social services benefits to ensure recipients do not fraudulently obtain benefits under fake names UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-16 UNCLASSIFIED FOR OFFICIAL USE ONLY 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 2 1 3 2 1 1 2 U Face Recognition U The identification of a person by the facial image can be done in a number of different ways It can be done by capturing an image of the face in the visible spectrum using an inexpensive camera or by using the infrared patterns of facial heat emission Facial recognition in visible light typically models key features from the central portion of a facial image Using a wide assortment of cameras the visible light systems extract features from the captured image s that do not change over time while avoiding superficial features such as facial expressions or hair Several approaches to modeling facial images in the visible spectrum are Principal Component Analysis Local Feature Analysis neural networks elastic graph theory and multi-resolution analysis The major benefits of facial recognition are that it is non-intrusive hands-free continuous and is acceptable to most users U Some of the challenges of facial recognition in the visual spectrum include reducing the impact of variable lighting and detecting a mask or photograph Some facial recognition systems may require a stationary or posed user in order to capture the image although many systems use a real-time process to detect a person's head and locate the face automatically 2 1 3 2 1 1 3 U Iris Recognition U The iris of the eye is the colored area that surrounds the pupil Iris patterns are unique The iris patterns are obtained through a video-based image acquisition system Iris scanning devices have been used in personal authentication applications for several years Systems based on iris recognition have substantially decreased in price and this trend is expected to continue U The technology works well in both verification and identification modes in systems performing one-to-many searches in a database Current systems can be used even in the presence of eyeglasses and contact lenses The technology is not intrusive It does not require physical contact with a scanner Iris recognition has been demonstrated to work with individuals from different ethnic groups and nationalities 2 1 3 2 1 1 4 U Hand and Finger Geometry U These methods of personal authentication are well established Hand recognition has been available for over twenty years To achieve personal authentication a system might measure physical characteristics of either the fingers or the hands These include length width thickness and surface area of the hand One interesting characteristic is that some systems require only a small biometric sample a few bytes 1221 U Hand geometry has gained acceptance in a range of applications It can frequently be found in physical access control in commercial and residential applications in time and attendance systems and in general personal authentication applications 1222 2 1 3 2 1 2 U Behavioral Biometrics 1223 2 1 3 2 1 2 1 U Signature Verification U The technology is based on measuring the speed pressure and angle used by the person when a signature is produced One focus for this technology has been e-business applications and other applications where signature is an accepted method of personal authentication 1219 1220 1224 1225 1226 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-17 UNCLASSIFIED FOR OFFICIAL USE ONLY 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 2 1 3 2 1 2 2 U Speaker Recognition U Speaker recognition has a history dating back some four decades where the output of several analog filters was averaged over time for voice matching Speaker recognition uses the acoustic features of speech that have been found to differ between individuals These acoustic patterns reflect both anatomy e g size and shape of the throat and mouth and learned behavioral patterns e g voice pitch speaking style This incorporation of learned patterns into the voice templates the latter called voiceprints has earned speaker recognition its classification as a behavioral biometric U Ambient noise levels can impede collection of the initial and subsequent voice samples Performance degradation can result from changes in behavioral attributes of the voice and from enrollment using one telephone and verification on another telephone Voice changes due to aging also need to be addressed by recognition systems Many companies market speaker recognition engines often as part of large voice processing control and switching systems Capture of this biometric is seen as non-invasive By using existing microphones and voicetransmission technology to allow recognition over long distances by ordinary telephones wire line or wireless this technology needs little additional hardware 2 1 3 2 2 U Usage Considerations U There are two typical implementations for deploying a biometric system using a centralized database for storing user reference biometric templates recognition mode or storing the biometric value directly on a token the user possesses authentication mode 2 1 3 2 2 1 U Implementation Issues U Recognition mode uses a centralized database containing all enrolled users' reference templates A user presents himself herself at the biometric reader for authentication The reader collects the biometric digitizes it and sends it over the network from the client directly connected to the reader to a Biometric Authentication Database The comparison and acceptance rejection of the fingerprint face etc is made there and the acceptance or rejection notice is sent back to the client If a match is verified the user is allowed to access the various resources on the network U Authentication mode typically stores the biometric value directly on the user's token In this case there is no central database Rather the user feeds a hardware token into the reader and then presents the fingerprint face etc for reading The reader is a trusted device that compares the measured biometric directly with the value stored on the presented token U Biometrics may not be suitable for every environment For example users in tactical environments may have difficulty using a fingerprint reader since their fingers might get dirty or cut or their protective clothing may preclude access to the biometrics reader Carrying a large biometric reader with a handheld device may limit the device's mobility Hence use of a particular biometric must be weighed against its operational environment The authentication confidence associated with biometrics must consider the applicability of the authentication mechanism for the environment in question UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-18 UNCLASSIFIED FOR OFFICIAL USE ONLY 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 2 1 3 2 2 2 U Advantages U The time required to perform a match in authentication mode is much less than in recognition mode because the trial template must only be matched against a single reference template The time necessary to perform the recognition process is driven by the size of the template database and the size of the template The more users enrolled in a system the longer it will take to perform a match in the database Also the larger the template the longer a positive match will take Using biometrics as one of several authentication factors increases the strength of the authentication and because the biometric system can be used in authentication mode versus recognition mode it should not impact system performance U To access some information in the GIG multifactor authentication may be required Biometrics can play an important role in providing a higher authentication score than a simple user name and password They can also be used to unlock a user's privileges or other authentication information Biometrics also assist in providing an audit function as they can uniquely identify a user and enable the system to tie the user to performed actions 2 1 3 2 2 3 U Risks Threats Attacks U With the recognition mode implementation an adversary does not need to attack the reader but rather the network or the biometric database The biometric template must be secure as it crosses the network If the template can be captured an adversary can present it to the biometric database and impersonate an authorized user This can be avoided by securing the connection between client and database by using protocols such as IPsec or TLS which includes replay protection U The database itself also is a target for attack If the database can be compromised all reference templates stored on it are also compromised The database is likely to be riding on an OS that can be exploited through a variety of methods much like attackers on the Internet capture credit card databases today Alternatively an attacker can use the weakness to replace the stored value with his own value thus granting him access while completely eliminating the legitimate user from the system U The difference between this biometric attack and credit card attacks is that biometric templates are very difficult to revoke If an attacker captures a set of credit card numbers those cards can be revoked and new cards issued Or if an attacker captures a set of private encryption keys from a PKI the certificates corresponding to those keys can be revoked and new keys certificates issued While there is some pain and expense in the revocation operation the procedures and methods are known 1304 U Contrast this with an attack that captures the digital fingerprints of the user base The attacker now has the digitized fingerprints and can inject them into the system as needed to impersonate a user It is not practical to have users get new fingerprints the only option is to throw out the existing biometric solution and replace it with a new one e g a new method of digitizing fingerprints that bears no relation to the other one and cannot be derived from it or switch to using face recognition instead of fingerprints 1305 U To defend against these attacks a number of steps must be taken 1299 1300 1301 1302 1303 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-19 UNCLASSIFIED FOR OFFICIAL USE ONLY 1306 o U The digitized image must be some transform of the actual biometric that cannot easily be reversed For example the value sent stored and compared would be a SHA-1 hash of the digitized fingerprint If this were to be captured it would be replaced with a SHA-2 hash of the face etc o U Each use of the biometric should include some unique value e g time stamp hashed in with the actual value to protect against replay attacks This is a trade-off as the goal would be to use a biometric value for an entire session e g only capture the fingerprint once then let the user work for a few hours and replay attacks can potentially be done whenever the time is still within the legal window of use of the biometric o U As indicated above the communication between the computer connected to the biometric reader and the central database must be secured for example using TLS IPsec or equivalent security o U The computer on which the Central Database resides must be secured to the maximum extent possible o U Protected Resources must also be secured They must be able to authenticate all accesses by users--they should be able to tell from where an access arrives in case it is attempted by an attacker who has compromised the system 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 U The authentication mode implementation avoids the network and operating system-based vulnerabilities described above however it presents a number of its own potential vulnerabilities Chiefly these relate to the tamper resistance of the hardware token--if an attacker can acquire the token and replace the stored value with his own value he will be approved by the system U Other vulnerabilities with this approach relate to how the biometric reader communicates successful matching to the system If an attacker can simply forge a successful match message from the reader to the protected resources the attacker is in the system again 2 1 3 2 3 U Maturity U The Gartner Hype Cycle lists two to five years to reach the plateau adoption The plateau is defined as the real-world benefits of the technology are demonstrated and accepted Gartner lists several factors which determine the maturity level User acceptance is one of the primary factors along with ease of use accuracy reliability resistance to attack and cost U User acceptance is a concern with iris and retina scanning because of a general fear people have about instruments close to their eye The accuracy of iris and retina scanning is reasonably good but the cost is high for scanning equipment Voice and signature recognition are neither as intrusive as iris and retina scanning nor as expensive but are not as accurate and require more effort to use Fingerprint face and hand recognition fall in between in terms of intrusiveness accuracy and expense UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-20 UNCLASSIFIED FOR OFFICIAL USE ONLY 1343 1344 1345 1346 U IDC lists three main challenges to adoption of biometrics authentication convenience installation and portability Convenience translates into ease of use in Gartner's terms while installation is really a cost factor which includes time and money Portability is something Gartner does not discuss 1348 U IDC describes portability as how easy is the biometric device to carry around If the biometric device is cumbersome to carry people will refuse to use it 1349 U Gartner lists the following obstacles to biometrics technology 1347 1350 o U Biometric equipment is expensive to buy and install 1351 o U Applications have to be changed 1352 o U None of the biometrics devices are fool proof 1353 o U Accuracy can be affected by aging injury or environmental conditions 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 U There are several initiatives that may accelerate the biometric development market For example a trusted traveler program is being lobbied for to move people through airports quickly and to improve security One of the fundamental pieces to a trusted traveler program is biometrics Travelers must be authenticated as they move through the transportation system While a trusted traveler program is still being debated in Congress a pilot program is underway Developments related to the trusted traveler program could accelerate the biometrics market U When it comes to the core algorithms and mechanisms involved the Technology Readiness Level of biometric technologies in general can be thought of as nearing the Mature level TRL79 2 1 3 2 4 U Standards U Standards applicable to biometrics are listed in Table 2 1-2 Table 2 1-2 U Biometric Standards 1365 This Table is U Standard Common Biometric Exchange Formats Framework CBEFF Description CBEFF originally stood for Common Biometric Exchange File Format and was originally developed by the Biometric Consortium BC It was published by NIST as NISTR 6529 CBEFF defines a standard method for identifying and carrying biometric data It describes a framework for defining data formats that facilitate the communication of biometric data CBEFF does not specify the actual encoding of data e g bits on a wire but provides rules and requirements and the structure for defining those explicit data format specifications This Table is U UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-21 UNCLASSIFIED FOR OFFICIAL USE ONLY This Table is U Standard BioAPI Data Interchange Formats Biometric Profiles Biometric Evaluation Methodology Description The BioAPI standard defines an Application Program Interface API and a Service Provider Interface SPI for standardizing the interaction between biometric-enabled applications and biometric sensor devices The API provides a common method for applications to access biometric authentication technology without requiring application developers to have biometric expertise The SPI allows the production of multiple BSPs Biometric Service Providers that may be used by an application without modification of that application regardless of biometric technology The BioAPI Consortium originally developed the BioAPI specification The BioAPI Consortium is a group of over 50 organizations focused solely on furthering a standard biometric API M1 has taken the resulting specification from the consortium and standardized it nationally as ANSI INCITS 358-2002 M1 has also contributed ANSI INCITS 358-2002 to SC 37 where it is currently a draft international standard A data interchange format specifies the low-level format for storing recording and transmitting biometric information This biometric information may be unique to each biometric characteristic e g fingerprint iris signature and or to each method of capture e g photograph capacitive sensor In some technologies this biometric information is called a template M1 3 is currently working on projects dedicated to standards for the following formats A biometric profile identifies a set of base biometric standards that apply to a single application or scenario The profile then identifies the appropriate configurations parameters and choices for options provided within those specifications The goal is to provide interoperability and consistent functionality and security across a defined environment M1 4 is engaged in the following projects o Interoperability and Data Interchange--Biometric Based Verification and Identification of Transportation Workers o Interoperability Data Interchange and Data Integrity--Biometric Based Personal Identification for Border Management o Point-of-Sale Biometric Verification Identification SC 37 has defined a functional architecture that serves as part one of a multi-part standard SC 37 is also working on the first profile of the standard titled Biometric Profile for Employees The Biometric Evaluation Methodology BEM Version 1 0 was designed to aid security evaluators who were attempting to evaluate biometric products against the Common Criteria CC The Common Evaluation Methodology CEM used in CC evaluations does not address the environmental user population and other issues that have an impact on a biometric implementation The BEM specifically addresses these issues as they apply to biometric technology evaluations under the CC Evaluators certifiers and developers from Canada U K GERMANY U S Italy Sweden and others developed the BEM Version 1 0 of BEM was released in August of 2002 This Table is U UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-22 UNCLASSIFIED FOR OFFICIAL USE ONLY This Table is U Standard Biometrics Protection Profile Biometric API for JavaCard Common Data Security Architecture CDSA Human Recognition Services Module 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 Description The CC is an effort of the US Canada and European countries to establish a common set of security criteria by which to evaluate IT products This effort has resulted in an international standard ISO IEC 15408-1 for evaluating IT security products The document that establishes the implementation-independent security requirements for a given category of product is called a Protection Profile Currently the DoD Biometrics Management Office BMO and the National Security Agency NSA are developing four Protection Profiles for biometrics products o Robustness Biometric PP for Verification Mode o Basic Robustness Biometric PP for Verification Mode o Medium Robustness Biometric PP for Identification Mode o Basic Robustness Biometric PP for Identification Mode The JavaCard Forum was established in 1997 to promote Java as the preferred programming language for multiple-application smart cards A subset of the Java programming language was proposed for these cards and resulted in a standard for a JavaCard API The JavaCard Forum has extended the JavaCard API to enroll and manage biometric data securely and facilitate a match on card capability with the Biometric API for JavaCard The Biometric API manages templates which are stored only in the card During a match process no sensitive information is sent off the card The Human Recognition Services Module HRS is an extension of the Open Group's Common Data Security Architecture CDSA CDSA is a set of layered security services and a cryptographic framework that provides the infrastructure for creating cross-platform interoperable security-enabled applications for client-server environments The biometric component of the CDSA's HRS is used in conjunction with other security modules i e cryptographic digital certificates and data libraries and is compatible with the BioAPI specification and CBEFF This Table is U 2 1 3 2 5 U Cost Limitations U Biometrics can provide an enhanced authentication capability but they have several costs associated with them First biometric readers must be deployed on the system This may be a substantial cost depending on the cost per reader and the number of readers required In the GIG it is envisioned that many systems will require biometric authentication and therefore a large number of readers will be required U There are several processes that require administration in a biometric system and therefore add to the maintenance cost of the system One of these processes is enrollment which incurs a cost both upon the central administrator and upon the user U Another limitation of biometrics is the user's acceptance This is influenced by the perceived intrusiveness of the biometric For example signatures are widely accepted today and a user would be far less likely to mind a signature biometric than an iris or retina scan that requires them to put their eye close to the biometric reader If the users will not accept the use of the particular biometric technology it cannot be expected to be successful UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-23 UNCLASSIFIED FOR OFFICIAL USE ONLY 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 2 1 3 2 6 U Alternatives U Alternatives for biometrics include any information that can be used to verify a user's identity For example Government issued photo identification may be substituted for a biometric for applications such as physical access to a building However it alone is not adequate to authenticate access to an information system U Another alternative to biometrics is to require more information that the user knows For example if a biometric is not available inputting several passwords may be sufficient to authenticate the user 2 1 3 2 7 U Complementary Techniques U Hardware tokens are complementary to biometric implementations using the authentication mode 2 1 3 2 8 U References U Biometric Authentication Perspective Gartner U Hype Cycle for Information Security 2003 Gartner U Reduced Complexity Face Recognition using Advanced Correlation Filters and Fourier Subspace Methods for Biometric Applications by M Savvides PhD Thesis May 2004 Electrical Computer Eng Carnegie Mellon University UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-24 UNCLASSIFIED FOR OFFICIAL USE ONLY 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 2 1 3 3 U Device Service Authentication U FOUO Security and trust in any network is a function of all the elements that make up a network This includes end-point client and server devices that can impersonate users and organizations As network devices proliferate e g mobile phones PDAs portable digital music players set-top boxes and laptops the ability to distinguish between trusted and rogue devices becomes a fundamental security requirement U Since an authenticated device can act as the root of trust it can also provide the security foundation for a new breed of applications such as identity based anti-virus solutions and digital information rights management software From this standpoint device and service authentication is a core requirement of any strong identification management strategy U There are a variety of initiatives and incentives motivations that are driving industry towards robust device authentication including the following o U Transform today's mobile devices e g cell phones PDAs laptops into strong authentication devices o U Propagate device credentials strong authentication algorithms and authentication client software across many network end points e g desktop computers servers switches Wi-Fi access points set-top boxes o U FOUO Enhance device credentialing management schemes for improving SSO in the GIG or at least to help reduce Sign-On problems o U Build around well-established infrastructure components such as directory and RADIUS servers 1418 o U Proliferate low-cost multi-function authentication devices e g tokens smart cards 1419 o U Facilitate native support e g platform connectors for strong device and user authentication in application development and identification management platforms o U Leverage federated identity protocols as a powerful propagation and integration mechanism 1423 o U Enable best-of-breed solutions through interoperable components 1424 o U Credentials and Security Devices 1409 1410 1411 1412 1413 1414 1415 1416 1417 1420 1421 1422 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-25 UNCLASSIFIED FOR OFFICIAL USE ONLY 1425 2 1 3 3 1 U Technical Detail 1426 2 1 3 3 1 1 U Universal Strong Authentication for Devices U The strength--the trustworthiness--of an identity depends on multiple factors The initial authentication process i e identity verification the type of credential being issued i e security token and the depth of the relationship between the authenticator and the authenticated entity all contribute to the strength of an identity Beyond the authentication process the security policies enforced by the authentication authority and its operation best practices have a direct impact as well 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 U Strong identification management must take into account technology policy and operational issues Strong authentication is the first level of trusted networks where identities can be securely shared and trusted across independent partners It is the foundation for a more secure network one in which all people and all devices are strongly authenticated in an open interoperable and federated environment U Three methods specify the core types of authentication credentials--SIM secret and X 509 certificate Each of these methods has a specific use in an interoperable environment o U SIM-based authentication - SIM Subscriber Identity Module This authentication method predominates in telecommunications It also is emerging as an important authentication method in public Wi-Fi networks authentication and roaming across Global System for Mobile Communications General Packet Radio Service and 802 11 networks o U PKI-based authentication - PKI is a fundamental security component of all major Internet protocols for authentication and communication e g Transport Layer Security TLS WS-Security IPsec IKE 802 1x Session Initiation Protocol SIP The choice of X 509v3 certificates as strong credentials is also consistent with deployment trends in enterprise and government markets Furthermore certificates offer additional security functionality beyond authentication for example for electronic form and e-mail signing and file encryption It should also be noted that there are ongoing developments within PKI KMI to specify not just devices in the Directory Information Tree but also services servers and roles 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 2 1 3 3 2 U Usage Considerations U When describing authenticating a device it is important to consider to what the device is authenticating In the case of 802 1x the device is being authenticated at the link layer In the case of a call setup on a mobile phone network the authentication occurs at an application level Sometimes authentication will need to be done on a per connection basis such as on a point-topoint link Other times authentication will need to be done at an enterprise level for auditability and scalability purposes U Each of these different scenarios implies a different mechanism to perform device authentication This can lead to many overlapping and potentially conflicting protocols and processes UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-26 UNCLASSIFIED FOR OFFICIAL USE ONLY 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 2 1 3 3 2 1 U Advantages U Secure device authentication enables many other security goals of GIG-related technologies By also authenticating a device that a user is interacting with the entire system has a higher degree of confidence in the authenticated session By authenticating a device in a data center communicating with another unmanned device services such as web services can use the identity of a device as a foundation for trust in the end-to-end system Device authentication permits secure access to networks applications and any other GIG-connected resources 2 1 3 3 2 2 U Risks Threats Attacks U Device authentication mechanisms have many potential points of vulnerability The protocol used to relay authentication across the network may be a point of attack Dr Arbaugh from the University of Maryland has already found several weaknesses in the 802 1x protocol These vulnerabilities allow 802 1x to be attacked over the network These attacks may allow an attacker to either hijack a session from an authenticated device or prevent a legitimate device from using the network U Furthermore device authentication may be relying on the physical security of the device itself This security may come in the form of guards guns and dogs standard physical security or may be the result of the use of tamperproof tamper evident devices such as a smart card The guards guns and dogs model of physical security can be overcome by physical force Tamperproof tamper evident protections might be overcome by sophisticated technical attacks Ross Anderson has published many papers on the topics of subverting tamper resistant proof devices U However the device authentication mechanism is subverted the end result is generally the same lack of trust in the actual identity of the end device When designing or deploying device authentication systems great care must be exercised to determine the real security limitations of the protocols and products involved 2 1 3 3 3 U Maturity U Device authentication is an emerging technology Until recently there has been little perceived value in authenticating a device Enterprises have been more worried about the identity of the user and have not focused their attention on the device itself However as devices become more mobile and disposable device authentication is rapidly gaining visibility U Unfortunately few standards exist and even fewer products This area of device authentication still requires a great deal of research and standards development before widespread market adoption will occur U In summary the Technology Readiness Level of device authentication can be viewed as Emerging TRL 4 - 6 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-27 UNCLASSIFIED FOR OFFICIAL USE ONLY 1499 2 1 3 3 4 U Standards 1500 2 1 3 3 4 1 U 802 1x U The Institute of Electrical and Electronics Engineers IEEE approved the standard 802 1x on June 14 2001 This standard is based on the physical characteristics and identification of the device port or wireless station that is requesting the connection The standard provides a mechanism for restricting access to a local area network LAN or a virtual local area network VLAN Generally it is described as providing port-based access control 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 U The 802 1x authentication architecture consists of a supplicant--a user or entity representing the endpoint requesting a network connection an authenticator--a network device or entity that is facilitating the authentication of the supplicant and an authentication server or service-- responsible for validating the supplicant's credentials and determining whether to authorize the authenticator to grant access to the requested services U 802 1x specifies how to carry link-level authentication information using Extensible Authentication Protocol EAP See the next section While 802 1x does not require the use of a separate authentication service it is often deployed in combination with a RADIUS server 1518 2 1 3 3 4 2 U EAP U EAP or Internet Engineering Task Force IETF RFC 2284 is an authentication framework that defines a way to encapsulate different authentication methods EAP can be used in combination with point-to-point protocol PPP IETF RFC 1661 or IEEE 802 1x A recent Internet draft updates the original EAP specification 1519 U A range of methods have emerged that build on EAP including 1514 1515 1516 1517 o U EAP-Transport Layer Security TLS for encrypted communication between endpoints identified by public key infrastructure PKI certificates o U EAP-message digest 5 MD5 for password authentication using a challengeresponse approach 1524 o U EAP-Generic Token Card GTC for use with one-time password tokens 1525 o U EAP-Microsoft Challenge Handshake Authentication Protocol MS-CHAPv2 1520 1521 1522 1523 1526 1527 1528 1529 1530 1531 1532 U Cisco Microsoft and RSA collaborated in proposing Protected EAP PEAP to the IETF PEAP has security improvements that extend Cisco's Lightweight EAP LEAP LEAP uses a stronger password-hashing authentication approach than EAP-MD5 but is also susceptible to offline dictionary attacks against the password PEAP is supported by Microsoft Cisco Funk Software and Meetinghouse Communications but is not recognized as an industry-wide standard Typically PEAP is used in combination with TLS for secure communication between endpoints that are authenticated using a method other than PKI UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-28 UNCLASSIFIED FOR OFFICIAL USE ONLY 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 1571 2 1 3 3 4 3 U RADIUS U RADIUS most recently specified by IETF RFC 2865 was originally designed as a protocol mechanism for authenticating remote users It is still typically used today to authenticate remote users connecting to a dial-in modem pool or an Internet-accessible virtual private network VPN gateway device U The typical architecture for RADIUS involves the VPN gateway or access server acting as the client requesting authentication of a user connection and a RADIUS server performing the authentication and passing back appropriate configuration information to the requesting service In addition RADIUS servers can act as proxies for other RADIUS servers or authentication services This is often required when users are roaming between service providers or interfacing between a service provider and an internal network's identification management infrastructure U While RADIUS is independent of 802 1x many network access devices are expected to implement both the 802 1x authenticator role and the RADIUS client role However 802 1x is unable to support the challenge-response mechanisms of RADIUS Where a port ID is not available such as in wireless situations an association ID will be used U The IETF informational RFC 3580 defines specific mappings and special considerations when using both 802 1x and RADIUS In particular it defines how to authorize access to a VLAN by leveraging the tunnel attributes of RADIUS It also discusses specific known vulnerabilities with RADIUS and EAP and provides approaches to mitigate them U IETF informational RFC 3579 specifies how a RADIUS client or a network access server encapsulates EAP packets to forward to the RADIUS server where method-specific code can interpret and process the requests This characteristic enables the network access server to be neutral as to which authentication method is being used and to be unaffected by the introduction of new authentication methods 2 1 3 3 4 4 U PANA U A more recent standards initiative is underway in the IETF work on a Protocol for carrying Authentication for Network Access PANA This work is still in a draft status with additional deliverables planned for 2004 to define the interactions between PANA and 802 1x and to specify a Management Information Base MIB for the protocol U Goals for the PANA effort include support for roaming devices dynamic choice of service providers and multiple authentication methods--all based on IP protocols PANA is designed to work with EAP as a network-layer transport carrying EAP payloads independently from the choice of link-layer protocol and avoiding potential roundtrip delays during connection establishment Note however that the primary focus of this effort is to authenticate devices at Layer 3 or above before granting use of network services A typical usage scenario involves a client system authenticating to a server to gain network access U While mechanisms such as 802 1x and PPP already support specific link-layer support for EAP other application-layer authentication approaches are considered to be ad hoc and vulnerable UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-29 UNCLASSIFIED FOR OFFICIAL USE ONLY 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608 1609 1610 U The work on PANA is still at an early stage and is being driven mostly by vendors providing wireless network services and mobile clients 2 1 3 3 4 5 U Platform-Based Key Storage U Hardware key storage is becoming built directly into personal computing devices The Trusted Computing Group TCG and Next Generation Secure Computing Base NGSCB allow PKI keys and certificates to be stored on chips which are manufactured into PC and PDA motherboards In essence the personal computing device contains a built-in smart card U Although only a small number of vendors e g IBM and HP offer such products today TCG and NGSCB will play important roles in digital rights management and platform security in the next few years 2 1 3 3 4 6 U XML and PKI XKMS U As mentioned previously the appeal of XML has reached PKI in the form of XKMS a lighter-weight approach for clients and servers to deal with some of the complexities of traditional PKI processing such as certificate path-checking and validation While XKMS capability is being introduced into newer versions of PKI products it has not yet had a major impact on the industry U The World Wide Web Consortium W3C has published requirements for Version 2 of XKMS which intends to improve the XKMS interactions with Simple Object Access Protocol SOAP XML Schema and Web Services Description Language WSDL U XML Signature and XML Encryption standards have been formalized by the W3C and promise to be a prevalent part of future application development The ability to encrypt and sign individual components of XML documents will require robust key management capabilities a role potentially filled by PKI U The Organization for the Advancement of Structured Information Standards OASIS has initiated a standards process for the XML-based Digital Signature Services DSS To date a draft exists only for requirements and use cases but DSS intends to provide an overarching set of XML techniques for the processing of digital signatures including verification time stamping and signature creation U Although ITU X 509 and the IETF PKIX group use ASN 1 as the basis of encoding for PKI certificates there is interest in creating a general-purpose standard for XML certificate encoding Discussions in the IETF and W3C have resulted in some initial drafts but nothing has emerged as a clear standards candidate at this point Due to the concerns about ASN 1 development and processing complexity however it is likely that continued effort in this area will result in the creation of a standards-based XML digital certificate format 2 1 3 3 4 7 U IPsec VPNs U Two headers form the basis of IPsec the Authentication Header AH protocol and the Encapsulating Security Payload ESP protocol AH as the name implies is used for authenticating packets from a host or network device The ESP header can be used for both authentication and encryption UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-30 UNCLASSIFIED FOR OFFICIAL USE ONLY 1611 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625 1626 1627 1628 1629 1630 1631 1632 1633 1634 1635 1636 1637 1638 1639 1640 1641 1642 1643 1644 1645 1646 1647 1648 1649 U Each of these protocols can operate in one of two modes the transport mode or the tunnel mode In transport mode the protocol operates primarily on the payload of the original datagram In tunnel mode the protocol encapsulates the original datagram in a new datagram creating a new IP header and treating the original datagram as the data payload U The design of the AH and ESP headers is modular which allows different cryptographic algorithms to be used as needed As new algorithms are developed such as elliptic curve algorithms and the Advanced Encryption Standard AES the parameters for their use can be standardized within IPsec's architecture and then used in conjunction with AH or ESP U Although the AH and ESP protocols do not specify a particular automated encryption keymanagement system IPsec implementations are designed to support both preshared keys and the automated key management system called Internet Key Exchange IKE which is defined in IEEE RFC 2401 2 1 3 3 4 8 U SSL VPNs U Using SSL version 3 0 to implement secure network connections is different than using IPsec because connections focus on individual users and sessions rather than on multiplexed communications between sites Thus SSL-secured networks are similar to remote access VPNs although most implementations of SSL-secured networks connect a user to a server or server farm and not to all the resources at a site U One of the most appealing features of using SSL for a secure network is the deployment simplicity The minimum requirements for an SSL-secured network are a Web server with an appropriate digital certificate and a Web browser on each user's computer Note that this setup is mostly used for Web-based access File Transfer Protocol FTP Simple Mail Transfer Protocol SMTP and Network News Transport Protocol NNTP can use SSL if the appropriate SSLenabled versions of those products are used U As commonly deployed only the servers require digital certificates to initiate SSL sessions This considerably reduces the number of certificates to be managed and distributed That may suit some enterprises However organizations looking to authenticate external users such as for an extranet must employ some form of client authentication This adds the requirement for a PKI system if authentication is to be performed within the SSL protocol 2 1 3 3 5 U Costs Limitations U Device authentication technologies and protocols while existing in some form today are still considered emerging technologies This can be seen in the Standards section while noting the number of Working Groups IETF and others that are still working towards enhancing the authentication and security of these standards U From a pragmatic GIG enterprise services viewpoint the type technology selected depends on the particular situation and its mission needs of the authentication strength For example for situations that do not require the strictest authentication and secure levels combinations of Wi-Fi Protected Access WPA on a wireless local area network WLAN using RADIUS and LDAP servers should meet most needs UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-31 UNCLASSIFIED FOR OFFICIAL USE ONLY 1650 1651 1652 1653 1654 1655 1656 1657 1658 1659 1660 1661 1662 1663 1664 1665 1666 1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1682 1683 2 1 3 3 6 U Dependencies U Microsoft provides built-in support for 802 1x in Windows XP Windows 2000 users running Service Pack 3 can download the Microsoft 802 1x Authentication Client for Windows 2000 Microsoft also supplies versions of this client software to Windows 98 and NT users with a Premier support agreement U Apple has built-in support for 802 1x in Mac OS X v10 3 which can be configured to access either an AirPort wireless connection or a secure Ethernet port Mac OS X v10 3 also supports WPA for WLANs without the need for 802 1x or a RADIUS server which is ideal for home users without a RADIUS server U Linux systems require client software that performs the 802 1x supplicant function This software is available from the Open Source Implementation of 802 1x site used in combination with OpenSSL Secure Sockets Layer and FreeRADIUS U In addition developer kits and 802 1x drivers for various operating environments are available from software vendors such as Meetinghouse Data Communications with its AEGIS product line The AEGIS client is available for Windows 98 ME NT 2000 and XP Pocket PC and Palm products Mac OS X and Linux Funk Software offers its Odyssey client for Windows 98 ME NT 200 and XP Pocket PC and Windows Mobile U A growing class of products that assess the status of client systems for conformance to security policies are embracing 802 1x authentication to integrate with network switching systems Access to the network is only granted once policy conformance has been established Both Zone Labs' Integrity 5 0 and Sygate's Secure Enterprise support this feature Zone Labs acquired by Checkpoint Software certifies its 802 1x feature to work with products from Aruba Cisco Enterasys Funk Software and Microsoft Sygate announced support for interoperability with products from Cisco Enterasys Extreme HP and Nortel One of the features of Sygate's solution is to quarantine any client systems which are not running policychecking agent software to a guest VLAN U Other third-party software products inherit support for 802 1x simply by working with existing 802 1x-aware client software such as the support built in to Windows XP For example RSA provides support for SecurID authentication to WLANs through its Advanced Computing Environment ACE Agent for Windows and the Windows XP wireless LAN client U Fiberlink GRIC and iPass are implementing similar capabilities for their VPN clients These companies provide remote access management and VPN capabilities Their clients check the mobile device infrastructure to make sure--before allowing connection--that the firewall is running the virus scanner is running and up to date and the VPN is active UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-32 UNCLASSIFIED FOR OFFICIAL USE ONLY 1684 2 1 3 3 7 U Alternatives 1685 2 1 3 3 7 1 U MAC IP address U An alternative is to use the older simpler methods of device identification such as the media access control MAC address or IP address of the device the user is using at the time Enterasys' User Personalized Network UPN is such an example Once identity is established the switch can determine whether to grant access to devices associated with a restricted VLAN One of the main strengths of the UPN is its ability to provision network services and applications based on user identity The Enterasys solution relies on existing enterprise investments in directories-- such as Microsoft's Active Directory or Novell's eDirectory--to authenticate user identity and establish an association with the user's location 1686 1687 1688 1689 1690 1691 1692 1693 1694 1695 1696 1697 U Within the scope of device authentication there exist a number of alternatives and combinations Most of these are related to specific vendors and platforms These are described below o U Alcatel implements an approach to Layer 2 authentication within its OmniSwitch product line Alcatel's authenticated VLAN AVLAN feature does not rely on operating system support for EAP and 802 1x but requires an Alcatel-supplied client application AV-Client for Windows 9x NT 2000 and XP This client combines the Windows login with a network login so a user enters an identity and credential only once A successful authentication connects the user to the VLAN and its resources o U Cisco has a framework for identity-based networking services that is supported across several product lines including Catalyst switches 6500 4500 3550 and 2950 Aironet wireless access points and Cisco's Secure Access Control Server v3 2 ACS The various network switch products implement 802 1x They perform the role of an authenticator or intermediary between the supplicant at the client and the RADIUS authentication service Cisco's RADIUS server product is ACS o U Cisco extends 802 1x to enable dynamic assignment of VLANs to ports based on identity guest VLAN support mapping of access control lists ACLs to a port based on the user's 802 1x identity and synchronization of port security status in case of failover Also Cisco IP phones can be automatically mapped to a voice VLAN when detected Computers connected to IP phones will need to authenticate to get access to the network o U Cisco also announced its Network Admission Control NAC program a collaboration with industry partners focused on limiting damage from security threats originating at client systems that have been compromised by a virus or worm In its initial phase NAC enables Cisco routers to enforce access privileges when an endpoint device attempts to connect to a network This decision can be based on information about the endpoint device such as its current antivirus state and operating system patch level NAC allows noncompliant devices to be denied access placed in a quarantined area or given restricted access to computing resources o U Nortel has supported 802 1x in its BayStack switches since 2001 Recent extensions to its BayStack operating system Switching Software BoSS v3 0 for BayStack 420 and 1698 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-33 UNCLASSIFIED FOR OFFICIAL USE ONLY 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 425 switches improve its support for EAP and 802 1x Access to network services requires a login to a RADIUS authentication server Also its Wireless LAN 2200 series includes support for Virtual Port-based Authentication VPA based on EAP and 802 1x back to a RADIUS server both in its WLAN Access Points and in the optional WLAN Security Switch 2250 unit Other products such as Passport 8600 support VLANs for a variety of network separation requirements Nortel partners with Sygate to leverage 802 1x to quarantine systems that are out of compliance with local security configuration policies 2 1 3 3 7 2 U VPN-based Authentication U IPsec-based VPN Due to its original development for site-to-site VPNs IPsec focuses on machine authentication rather than user authentication and this has caused problems in creating interoperable dial-in clients To improve the usability and interoperability of IPsec-based VPN dial-in clients the IETF's IPsec Remote Access IPSRA working group has been trying to settle on a single protocol that it will propose as a standard to the IETF After almost two years' work on four or more different proposals the working group has settled on the Pre-IKE Credential Provisioning Protocol or PIC which is slowly making its way into commercial products U SSL-based VPN Though the SSL standard does not support client authentication methods other than digital certificates it is possible to use other authentication methods in conjunction with SSL The simplest approach is username and password but it is also possible to use stronger authentication methods such as security tokens or smart cards 1746 2 1 3 3 8 U References U An Initial Security Analysis of the IEEE 802 1x Protocol U http www cs umd edu waa 1x pdf 1747 U Ross Anderson's Home Page - http www cl cam ac uk users rja14 #Reliability 1744 1745 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-34 UNCLASSIFIED FOR OFFICIAL USE ONLY 1748 2 1 3 4 U Authentication Protocols 1749 1751 2 1 3 4 1 U Technical Detail U There are two major traditional authentication protocol techniques - Symmetric Key Authentication and Public Key Authentication 1752 U Symmetric Key Authentication 1753 U In symmetric key authentication the shared secret key is used at the client to create an OTP that is then transmitted to the server The same process is done at the server and if a match exists the user is authenticated 1750 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 1764 1765 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 U Many commercial schemes use public-domain hash functions based upon ANSI X9 9 which relies on Data Encryption Standard Message Authentication Code DES MAC which is a cipher-block chained checksum Some vendors use proprietary algorithms such as RSA Security It should be noted that X9 9 based on 56-bit single DES was withdrawn by ANSI in 1999 in favor of the stronger Triple DES algorithm U Another often used public domain hash function is the SHA-1 or Secure Hash Algorithm which comes from NIST in the federal government For greater security some tokens actually recalculate a new-shared secret key after each authentication process which requires that the server do likewise in order to keep in step U A common symmetric key authentication scheme is the Kerberos protocol Kerberos is a network authentication protocol Kerberos is designed to provide strong authentication for client server applications by using secret-key cryptography This is accomplished without relying on authentication by the host operating system without basing trust on host addresses without requiring physical security of all the hosts on the network and under the assumption that packets traveling along the network can be read modified and inserted at will Kerberos performs authentication under these conditions as a trusted third-party authentication service by using conventional cryptography i e shared secret key The authentication process proceeds as follows 1 U A client sends a request to the authentication server AS requesting credentials for a given server 2 U The AS responds with these credentials encrypted in the client's key The credentials consist of 1 a ticket for the server and 2 a temporary encryption key often called a session key 3 U The client transmits the ticket which contains the client's identity and a copy of the session key all encrypted in the server's key to the server 4 U The session key now shared by the client and server is used to authenticate the client and may optionally be used to authenticate the server It may also be used to encrypt further communication between the two parties or to exchange a separate subsession key to be used to encrypt further communication UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-35 UNCLASSIFIED FOR OFFICIAL USE ONLY 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794 U Another symmetric key authentication protocol is CHAP or the Challenge Handshake Authentication Protocol defined in RFC 1994 verifies the identity of the peer using a three-way handshake The following general steps are performed in CHAP 1 U After the link esStablishment phase is complete the authenticator sends a challenge message to the peer 2 U The peer responds with a value calculated using a one-way hash function Message Digest 5 MD5 3 U The authenticator checks the response against its own calculation of the expected hash value If the values match the authentication is successful Otherwise the connection is terminated 1795 U Public Key Authentication 1796 U Unlike symmetric key authentication which relies on a single shared secret key public key authentication employs a related pair of keys one public known to the server and one private known only to the client token and computationally unlikely to be derived from its public key counterpart In the authentication process the token employs its private key in a cryptographic function related to that which is executed by the server with the public key The token function is typically implemented as a software token on the local client host usually in a challengeresponse mode 1797 1798 1799 1800 1801 1802 1803 1804 1805 1806 1807 1808 1809 1810 1811 1812 1813 1814 1815 1816 1817 U Effective management of public and private key pairs across a large population of users requires a PKI A public key certificate or digital certificate binds a user identity with its associated public key and a trusted central agent or certification authority CA serves to verify the validity of issued certificates U In a challenge-response authentication process the server would send a random challenge to the client The client then uses its private key to digitally sign the challenge which is then returned as a response to the server along with its public key certificate which could alternatively be retrieved by the server from the CA If the certificate is shown to be valid the server verifies the digital signature through application of the client's public key U Currently deployed examples of public key certificate-based software token authentication include Microsoft's Windows 2000 server operating system using PKINIT or Public Key Initialization Authentication and commercial versions of Secure Shell SSH U Authentication mechanisms often depend upon the environments in which they are to operate along with other considerations The following sections describe various aspects of emerging authentication technology UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-36 UNCLASSIFIED FOR OFFICIAL USE ONLY 1818 1819 1820 1821 1822 1823 1824 1825 2 1 3 4 1 1 U 802 1x for network applications U For network access applications 802 1x can serve as the authentication protocol framework This is true both for wired and wireless networks The authenticator is the access point for wireless networks it is the layer-two switch for wired networks Figure 2 1-5 shows a network authentication framework A natural candidate is 802 1x because it already defines EAP methods for each of the proposed base authentication methods e g EAP-SIM for SIM-based authentication EAP-TLS for PKI-based authentication and EAP-PEAP for OTP-based authentication This is figure is U 1826 1827 1828 1829 1830 1831 1832 1833 Figure 2 1-5 U Network Authentication Framework 2 1 3 4 1 2 U 802 1x for device authentication U The 802 1x framework is crucial to promote a consistent deployment profile for device authentication across manufacturers and OS vendors Embedded 802 1x clients can be deployed to enable these devices e g VoIP phones access points switches servers to transparently authenticate to the network before being handed an IP address and being granted access to the network Figure 2 1-6 shows this This is figure is U 1834 1835 Figure 2 1-6 U Device Authentication Framework UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-37 UNCLASSIFIED FOR OFFICIAL USE ONLY 1836 1837 1838 1839 1840 1841 1842 1843 1844 1845 1846 1847 1848 1849 1850 1851 1852 1853 1854 1855 1856 1857 1858 1859 1860 1861 1862 1863 1864 1865 1866 1867 1868 1869 1870 1871 2 1 3 4 1 3 U Manufacturing-time device credentials U Device certificates can be combined with emerging secure computing technologies such as the Trusted Platform Module TPM and the 802 1x authentication protocol framework This convergence will foster a common technology stack and deployment profile to allow device manufacturers to enable turnkey-strong device authentication solutions In fact using the established profile manufacturers and OEMs will be able to rapidly collaborate to embed the necessary hardware credentials and client software at manufacturing time 2 1 3 4 1 4 U Web service protocol for business-application integration U Universal strong authentication must address the protocol dichotomy between network access applications e g dial-up VPN Wi-Fi and business applications such as Web or enterprise portals Web applications ERP systems and Web services The 802 1x framework is particularly well suited to the former but not to the latter A Web service interface is better adapted to today's business applications U Because the authentication protocols constitute the primary mechanism for integration into applications open authentication requires a palette of protocols that can support both types of applications This requirement leads to the definition of a Web service API alongside the 802 1x EAP methods already covered The Simple Object Access Protocol SOAP API can leverage the WS-Security specification as the primary mechanism for encoding the base security tokens OTP X509 certificate It can also define a challenge-response mechanism for SIM-based authentication 2 1 3 4 1 5 U Application connectors and authentication clients U The main motivation for standardizing an authentication protocol and promoting the development of authentication clients is to foster the creation of application connectors Application connectors or agents are the client libraries of strong authentication They must be portable across major operating systems and offer APIs across popular languages Such flexibility would make it easier for application developers to integrate strong authentication within custom applications e g link compile and run This is mainly true for the EAP protocols--EAP-SIM EAP-TLS EAP-PEAP--because the Web service can immediately leverage the Web services stack that exists in all major development platforms 2 1 3 4 1 6 U Credential Provisioning and Validation U Since universal strong authentication is a key objective the blueprint needs a method to harmonize credential issuance and other life cycle management functions across all types of secrets symmetric keys or RSA key pairs The SIM and OTP secrets become subordinate to an RSA key pair a device certificate key pair The shared secrets are encrypted and embedded as attributes within the certificate The certificate acts as a private store for the shared secrets and the security device acts as a secure hardware vault for the root credential UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-38 UNCLASSIFIED FOR OFFICIAL USE ONLY 1872 1873 1874 1875 1876 1877 1878 1879 1880 1881 1882 1883 1884 1885 1886 1887 1888 1889 1890 1891 1892 1893 1894 1895 1896 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906 1907 1908 1909 1910 U This approach allows manufacturers and customers to leverage the breadth of secret management capabilities and security practices e g key escrow secure roaming and directory services from existing PKI platforms The method applies both to secure device personalization shared secret and device certificates embedded at manufacturing time and secure provisioning of user credentials This unified credential life cycle management framework will leverage existing public key cryptography standards and modern protocols such as XML Key Management Specification XKMS U Validation profiles will be defined by the choice of authentication protocols as described earlier In addition validation services will be able to validate X 509 certificates using certificate revocation lists CRLs and industry standards such as Online Certificate Status Protocol OCSP or XKMS U Validation servers in a strong authentication environment have the same characteristics as RADIUS servers This is a conscious choice as RADIUS servers are already a key component of an ISP or enterprise network infrastructure Furthermore high-quality RADIUS servers are widely available from vendors and open-source projects The complexity and cost overhead for deploying strong authentication can be reduced by leveraging the large existing installed base of RADIUS servers U For applications that require a Web service interface the validation server will be required to implement the SOAP validation protocol discussed earlier In the network world the strong authentication validation server is congruent to a RADIUS server while in a service-oriented architecture the validation server is an instance of a Web service Because credential validation is highly complementary to credential mapping and exchange it makes sense to consolidate Web services with the architectural concept of Security Token Service STS as defined by Web Services Trust Language WS-Trust U An important architecture goal for universal authentication is to enforce the separation between validation and identity stores All identities user or device identities as well as deviceto-user bindings should be maintained outside the validation server This separation is important from an integration and cost-control standpoint It promotes a distributed architecture that favors the reuse of an enterprise's existing infrastructure e g corporate directories In such an architecture the validation server is a minimal front end 2 1 3 4 2 U Usage Considerations U In many cases the specific application dictates the authentication protocol For example in a Web application TLS will often be the primary protocol In the VPN case IPsec IKE is the standard and for wireless Wi-Fi 802 1x Extensible Authentication Protocol EAP methods such as EAP-TLS or EAP-PEAP are the norm U FOUO A major disadvantage of symmetric key authentication is that it does not scale well to large and global user populations due to the logistical difficulties of distributing the shared secret keys This disadvantage affects the use of the following protocols o U Kerberos UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-39 UNCLASSIFIED FOR OFFICIAL USE ONLY 1911 o U CHAP 1912 o U 802 11 wireless 1913 o U EAP-PEAP for OTP one-time-password authentication 1914 1915 1916 1917 1918 1919 1920 1921 1922 1923 1924 1925 1926 1927 1928 1929 1930 1931 1932 1933 1934 1935 1936 1937 2 1 3 4 2 1 U Advantages U FOUO A distinct advantage of public-key authentication is that it easily scales to very large networks such as the GIG whereas symmetric key or shared-secret authentication is generally limited to specific communities of interest in which the key management process will not be unduly burdensome 2 1 3 4 2 2 U Risks Threats Attacks U FOUO A common risk threat attack that has to be anticipated and dealt with appropriately by any proposed authentication scheme is the classic man in the middle MITM attack in which a malicious adversary will intercept the communications between a client and its authentication server and then modify the message protocol contents so as to defeat hijack or otherwise maliciously alter the proper authentication protocol It is essential that all critical authentication messaging be suitably encrypted so as to prevent this 2 1 3 4 3 U Maturity U Due to the strong desire across both the government and industry particularly the financial industry for secure authentication of parties conducting electronic communications and transactions authentication protocols have developed over the years into a fairly mature state Thus the Technology Readiness Level of authentication protocols would be grouped into the Mature category TRL 7 - 9 2 1 3 4 4 U Standards U There are a variety of formalized international and American standards covering the technology of authentication protocols 2 1 3 4 4 1 U International Standards U The international standards bodies that are responsible for developing authentication protocols include 1938 o U IETF Internet Engineering Task Force http www ietf org 1939 o U ISO International Organization for Standardization http www iso ch 1940 o U ITU-T International Telecommunication Union Telecommunication Standardization Sector http www itu int ITU-T o U IEEE Institute of Electrical and Electronics Engineers http grouper ieee org groups 1363 o U Industrial consortiums such as OASIS Organization for the Advancement of Structured Information Standards http www oasis-open org committees wss which develops 1941 1942 1943 1944 1945 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-40 UNCLASSIFIED FOR OFFICIAL USE ONLY 1946 1947 1948 1949 1950 1951 1952 security standards for web services U IETF standards that are relevant to authentication tokens include Internet Drafts from the Secure Shell working group and RFCs 2289 and 1760 that describe the S Key One-TimePassword System U Relevant ISO standards include ISO 8731 algorithms for banking message authentication ISO IEC 9797 MACs via block cipher and hash function ISO IEC 9798 entity authentication by symmetric digital signature and cryptographic check and ISO IEC 19092 1955 U Relevant ITU-T standards include those describing directory certificates for authentication such as X 509 issued 08 97 authentication framework and X 509 issued 03 00 public key and attribute certificate frameworks 1956 U IEEE standards include P1363 specifications for public key cryptography 1957 U OASIS standards include WSS Web Services Security Version 1 0 April 2004 WSS handles confidentiality integrity for SOAP Simple Object Access Protocol messages providing a mechanism for associating security tokens with message content WSS is extensible and supports multiple security token formats It builds upon existing security technologies such as Extensible Markup Language XML Digital Signature XML Encryption and X 509 Certificates to deliver a standard for securing Web Services message exchanges Providing a framework where authentication and authorization take place WSS lets users apply existing security technology in a Web Services environment 1953 1954 1958 1959 1960 1961 1962 1963 1964 1965 1966 1967 1968 1969 1970 1971 1972 1973 1974 1975 1976 1977 1978 1979 1980 U Founded in 1993 OASIS has members in 100 countries and 600 organizations including Entrust HP Hitachi IBM Microsoft Nokia RSA Security Sun Microsystems and Verisign 2 1 3 4 4 2 U American Standards U Organizations in the United States that are responsible for developing and promulgating authentication protocol standards include ANSI American National Standards Institute http www ansi org and NIST National Institute of Standards and Technology http www itl nist gov fipspubs repository of the Federal Information Processing Standards or FIPS U Relevant ANSI standards include X9 9 message authentication codes for symmetric token authentication withdrawn in 1999 due to attacks demonstrated against single DES 56-bit key in favor of double or triple DES X9 30 public key cryptography digital signature algorithm DSA secure hash algorithm SHA-1 DSA certificate management X9 31 reversible public key cryptography for digital signatures rDSA X9 45 management controls using digital signatures and attribute certificates X9 52 triple DES modes of operations X9 63 key agreement and transport using elliptic curve cryptography ECC X9 71 keyed hash for message authentication and X9 72 peer entity authentication using public keys UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-41 UNCLASSIFIED FOR OFFICIAL USE ONLY 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 U Relevant NIST FIPS PUB standards include FIPS 180 secure hash algorithm SHA-1 FIPS 186-2 digital signature standard DSS same as ANSI X9 30 FIPS 190 guideline for use of advanced authentication technology alternatives FIPS 196 entity authentication using public key cryptography same as ANSI X9 72 and FIPS 197 advanced encryption standard AES An informative new NIST draft document on authentication mechanisms is Special Publication 80063 Recommendation for Electronic Authentication January 2004 which can be found at http csrc nist gov publications drafts draft-sp800-63 pdf U The purpose of this section is not to explain all of the various algorithms used by authentication tokens but to note that tokens--hardware or software--can use a variety of cryptographic algorithms to produce the desired OTP algorithms such as DES Triple-DES DSA SHA ECC and the new AES Advanced Encryption Standard However as algorithms are improved and attacks discovered against the weaker algorithms some standards are superceded or withdrawn 2 1 3 4 5 U Cost Limitations U An authentication protocol that is based upon symmetric or secret key cryptography has in it a very costly and limiting characteristic in that the associated secret keys must be delivered a priori to all parties This is a severe limitation in the context of the GIG U Whereas both symmetric and public key authentication can be done at the application layer only public key authentication can be done automatically at the transport layer 2 1 3 4 6 U Dependencies U One dependency of public key encryption-based authentication protocols is the existence of a well-developed and robust PKI 2 1 3 4 7 U Alternatives U The alternatives to use of an authentication protocol are few and undesirable One alternative is simply to forgo authentication but this is not thinkable in the context of the GIG Another alternative would be within the context of a closed system where all communicating participating parties are talking securely to each other over link-encrypted lines and are thus inherently trusted to each other 2 1 3 4 8 U Complementary Techniques U Certainly tokens both hardware and software are a complementary technology to that of authentication protocols It is within the client-retained token that much of the authentication algorithm is either stored and or executed in the field during a given authentication attempt 2 1 3 4 9 U References U RFC 1994 PPP Challenge Handshake Authentication Protocol CHAP http www ietf org rfc rfc1994 txt by W Simpson 1996 U NIST Special Publication 800-63 Recommendation for Electronic Authentication http csrc nist gov publications drafts draft-sp800-63 pdf January 2004 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-42 UNCLASSIFIED FOR OFFICIAL USE ONLY 2018 2019 2020 2021 2 1 3 5 U Authentication Confidence U Authentication confidence refers to developing a system that determines the probability that a user or other device is who he she it claims to be It takes into account such factors as o U The authentication mechanism e g static password public-key cryptography software token hardware token biometrics o U The authentication protocol used e g a protocol that is known to be secure against man-in-the-middle attacks or one that is based on strong cryptographic operations o U The location of the entity being authenticated e g a secure office CONUS or OCONUS a public kiosk or Internet cafe a tactical battlefield o U Characteristics of the device used to authenticate e g a COTS computer owned and controlled by the US Government a publicly-accessible COTS computer a dedicated tamper-resistant device o U The communications path between the entity being authenticated and the server providing authentication and or access decisions e g a secure U S Government-owned or leased network a wireless network on a battlefield commercially-provided telecommunications lines a coalition partner's network 2022 2023 2024 2025 2026 2027 2028 2029 2030 2031 2032 2033 2034 2035 2036 2037 2038 2039 2040 2041 2042 2043 2044 2045 2046 2047 2048 2049 2050 2051 U FOUO The goal of authentication confidence is to quantify the risk that a user or entity attempting to access the system is not the purported user or entity This risk can then be provided to an access control service to grant or restrict access to system resources U FOUO The simplest example of authentication confidence is a user logging into the system over an insecure network from a public kiosk using a static password based authentication system For example someone purporting to be Joe logs into the system and provides the correct password However from tracing IP addresses and using known information the authentication server determines that Joe is coming in over a public Internet Service Provider's network from a public kiosk in a coffee shop and is not using a strong authentication protocol How confident is the authentication server that this is really Joe when there are numerous opportunities for the password to have been compromised It could have been acquired previously through a dictionary attack or by someone finding a slip of paper with Joe's password It could have been captured on this use via a keystroke logging function on the public terminal or at some point over the network Thus even though some entity has provided a valid user identifier and the correct password the system may still want to limit or even prevent access to resources for fear that the entity at the other end of the connection is not really Joe This may be the case for future login sessions as well as Joe's password now is very likely to have been compromised upon this use UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-43 UNCLASSIFIED FOR OFFICIAL USE ONLY 2052 2053 2054 2055 2056 2057 2058 2059 2060 2061 2062 2063 2064 2065 2066 U FOUO Note that authentication confidence is related to but distinct from policy-based access control decisions In the scenario described in the previous paragraph the result of a weak level of confidence in Joe's authentication was that Joe was restricted from or prevented from accessing certain resources This is because authentication confidence is one of a number of inputs to the access control mechanism However other inputs to that mechanism could have also resulted in access being restricted For example even if there was perfect confidence that Joe was really the user accessing the system and that there was no chance that Joe's authentication data was compromised for future uses Joe's access might still be restricted because of his location or communications path e g sensitive or classified information would not be sent to a location with insufficient physical security 2 1 3 5 1 U Technical Detail U Authentication confidence at this time is a research area While some work has been done and the general requirement is understood there are significant details to be worked out and major questions to be resolved Among the issues to be addressed are o U Authentication metrics It is generally accepted that static passwords are weaker than one-time passwords and that a hardware token with a PIN is generally better than a software token However there is no quantitative metric that compares different types of biometric authentication with each other or that compares biometric authentication with hardware token-based authentication or public-key cryptography-based authentication In order for authentication confidence to have any meaning there must be a way to measure and determine the relative if not absolute strength of each given authentication method o U Reliable communication of user location One of the factors normally considered to be part of authentication confidence is the location of the user e g within a secure area or in public In order for authentication confidence to be used there must be a way for the authentication server to reliably know this information The information must be conveyed to the server and it must not be possible for an attacker to spoof this For example it must not be possible for a public terminal in a kiosk to convince the authentication server that it is in a secure location and it must not be possible for a device that is on a battlefield in Southwest Asia to convince an authentication server that it is in a headquarters building in CONUS o U Reliable communication of device characteristics Another factor of authentication confidence is the characteristics of the device being used by the user e g a public COTS computer system a COTS computer system controlled by the Government organization or a special-purpose device with strong tamper resistance and strong cryptography The device must be capable of communicating this information to the authentication server and it must not be capable of being spoofed One of the initial research areas is determining precisely which set of characteristics is important in which situations o U Corrections modifications for error cases For every type of authentication system used there are two possible types of errors false positives in which the wrong entity is authenticated as being the correct one and false negatives in which the correct entity is rejected Each authentication technique has different false positives and false negatives For a password-based system a false positive occurs when an attacker knows the correct 2067 2068 2069 2070 2071 2072 2073 2074 2075 2076 2077 2078 2079 2080 2081 2082 2083 2084 2085 2086 2087 2088 2089 2090 2091 2092 2093 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-44 UNCLASSIFIED FOR OFFICIAL USE ONLY password a false negative occurs when the legitimate user fails to enter the correct password because he has forgotten it or mistyped it For a biometric-based system false positives occur when an attacker's measurement is close enough to the legitimate value to allow authentication For a false negative to occur the legitimate user's value is rejected as not matching the stored value In traditional authentication systems these differences can be taken into account by policy but the bottom line is that a user is authenticated or not as a binary state A user who is deemed to match gets access one who is deemed not to match is rejected There is no partial authentication or reflection of potential errors One of the potential benefits of an authentication confidence system is that it allows for partial access based on a partial match That is the authentication server could decide that a fingerprint is close enough to the correct value to allow some access but there is enough doubt i e through possibly smudged lenses scraped-off fingerprints that access to the most sensitive information and resources will be withheld This results in allowing legitimate users some use of the system so that they are not completely shut out while restricting the amount of damage that an attacker can cause 2094 2095 2096 2097 2098 2099 2100 2101 2102 2103 2104 2105 2106 2107 2108 2109 2110 2111 2112 2113 2114 2115 2116 2117 2118 2119 2120 2 1 3 5 2 U Maturity U As this is a research area at the present time there are no significant usage considerations to document As the area matures usage will be a major factor in the development and deployment of authentication confidence mechanisms and solutions U At this point authentication confidence is in its infancy and thus is assigned to the lowest Technology Readiness Group Early TRL 1 - 3 2 1 3 5 3 U Standards U A major step necessary for acceptance of authentication confidence metrics will be standards for those metrics Without standards users and organizations will not be able to assign meaningful values and make appropriate decisions about allowing access In particular standards will need to address o U Authentication metrics In addition to standards for the individual authentication mechanisms e g passwords biometrics and authentication tokens standards will be needed to map the metrics to one another o U Error indications Standards will be required for assessing how close a presented authenticator is to the correct one e g a biometric value was deemed to be incorrect but it was off by some small value or a password presented was not the correct one but it differed from the correct one by some characteristic which could easily be explained by a typing error or line noise 2121 2122 2123 2124 2125 2126 2127 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-45 UNCLASSIFIED FOR OFFICIAL USE ONLY 2128 2129 2130 2131 2132 2133 2134 2135 2136 2137 2138 2139 2140 2141 2142 2143 2144 2145 2146 2147 2148 2149 2150 2151 2152 2153 2154 2155 2156 2157 2158 2159 2160 2161 2162 2163 2164 2165 2166 2167 2 1 3 6 U Single Sign-On U Single Sign-On SSO has traditionally been limited to cases covering the one-time sign-on process for access to all services of a single organization whereas Global Sign-On has applied to multiple participating organizations that had reached an a priori collaborative agreement to avail users with a common sign-on process In the GIG Vision SSO is expanded to enable a user to login or sign-on only once to a global authentication server thus allowing an entity to simultaneously access the GIG information and resources without any requirement for additional identification and authentication With this definition SSO and Global Sign-On become one and the same Some communities view Global Sign-on as including the issues related to mobile users while SSO does not In this document fixed versus mobile issues are both treated under SSO U The goal of an ideal SSO system is to enable a user to login or sign-on only once to a global authentication server This approach eliminates the need to enter different passwords to login to a workstation to each service database etc and replaces this with an automatic sign-on or reauthentication of an entity making sign-on transparent SSO must not sign an entity on with all of their privileges or escalate an entity's privileges without the entity's consent This would be equivalent to signing on as a system administrator super user to read personal email SSO should also include a way to lower or release privileges once the activity that required increased privileges is complete U FOUO The initial sign-on process must be very robust and secure and based upon the ancillary enabling technologies of biometrics multi-factor authentication tokens one-time passwords and or strong session establishment protocols Once the server is certain as to the entity's identity that entity's global credentials and or roles would be provided back to the entity e g as a ticket certificate or SAML assertion thus enabling follow-on transparent login to all network resources and applications that are allowed U Since the credentials roles are critical if and when they are sent to the local user client end they should be managed and processed only by trusted hardware e g a hardware token or smart card that would be immune to malicious sniffing viruses or Trojan horses Transmission of credential information should be done encrypted so as to protect it while it is in transit U FOUO All of the above merely emphasize that SSO technology has the unavoidable effect of concentrating much potential aggregated risk in a small number of processes and information repositories Nevertheless the convenience and utility of SSO to the average user is such that the GIG is certain to feature SSO capabilities As such a successful SSO architecture fruition within the context of the GIG will demand very strong and mature identification and authentication technologies at the front end along with a robust privilege management infrastructure at the back end 2 1 3 6 1 U Technical Detail U SSO capabilities have been evolving over a number of years in commercial applications SSO has been enabled by a number of technical advances including strong authentication techniques biometrics and tokens which allow one-time passwords UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-46 UNCLASSIFIED FOR OFFICIAL USE ONLY 2168 2169 2170 2171 2172 2173 2174 2175 2176 2177 2178 2179 2180 2181 2182 2183 2184 2185 2186 2187 2188 2189 2190 2191 2192 2193 2194 2195 2196 2197 2198 2199 2200 2201 2202 2203 2204 2205 2206 2207 2 1 3 6 1 1 U Early SSO Techniques U A number of methods have been used over the years by organizations in order to implement techniques that in limited ways approximate the functionality of SSO These include login scripting password synchronization and Lightweight Directory Access Protocol LDAP directories as described below 2 1 3 6 1 1 1 U Scripting U Initial commercial techniques developed for SSO included scripting whose primary goal is the simple automation of the login procedure rather than the security enhancement of application access In scripting a user conducts a primary authentication to a SSO authentication server In subsequent accesses to various target systems the client intercepts the standard login dialogue and then retrieves the appropriate login script from a repository The client software then merely forwards the credentials which may merely be an instance of a user ID and password to the target system via the login dialogue achieving a transparent automation of the login procedure on behalf of the user The login script repository may reside within the SSO server or may be downloaded to the client and cached locally 2 1 3 6 1 1 2 U Password Synchronization U As can be seen from the above description scripting is merely a forced automation of the login procedure across various target systems--each of which may have unique User IDs and or passwords associated with a specific user An evolution of this technique is the concept of Password Synchronization in which a password is shared across various systems and can be updated in a synchronous fashion across all the target systems U Automatic password synchronization ensures that when a user modifies the password that new password is routed network-wide to other target systems Applying password synchronization and self-service password reset technologies reduces the number of unique passwords that a user needs to remember However while password policies could be strengthened for passwords that would be reused to access multiple applications and resources with resulting risk aggregation there is often still a need for the user to respond to each application's unique login prompt 2 1 3 6 1 1 3 U LDAP directories U Other technologies have also contributed to reducing the number of unique sign-ons that are needed Fewer application-specific login prompts are required as applications are upgraded to new software that offers integrated support for authentication to a shared Lightweight Directory Access Protocol LDAP directory LDAP directory-based authentication generally involves storing only the cryptographic hash of the user's password and it may not provide the contextual credential information about password policies and expiration dates U Each application would require its own logic to support authentication based on the LDAP and the credentials maintained in the directory Through the enabling of LDAP authentication for target systems user password information could be made retrievable from any LDAP-supporting network directory Each user then has only one password--the LDAP password-- to gain access to all LDAP-enabled target systems UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-47 UNCLASSIFIED FOR OFFICIAL USE ONLY 2208 2209 2210 2211 2212 2213 2214 2215 2216 2217 U LDAP authentication employs the Simple Authentication and Security Layer SASL protocol implemented between client systems and the directory server IETF RFCs which discuss SASL include RFC 2222 Simple Authentication and Security Layer http www ietf org rfc rfc2222 txt by J Myers 1997 and RFC 2244 The One-Time Password SASL Mechanism by C Newman 1998 In reality LDAP authentication only provides for consolidated sign-on rather than true SSO The user must authenticate separately on each target system Functionality and benefits similar to password synchronization are provided by LDAP authentication A potential limitation is that each possible target system must support the LDAP protocol Nevertheless LDAP can still effectively reduce the complexity of password management within an enterprise 2223 U The advent of strong multi-factor authentication techniques leveraged upon the enabling technologies of biometrics tokens and one-time passwords has made it possible to evolve more fully integrated SSO systems that rely upon the initial very robust authentication to an authentication server Then the as-needed propagation of encrypted authorizing credentials and one-time passwords is sent to each target system as it is encountered This can follow either a centralized or a federated architecture model 2224 2 1 3 6 1 2 U SSO Architectures 2225 2 1 3 6 1 2 1 U Centralized Model U A totally centralized architecture for SSO implementation as exemplified by the original Microsoft Passport system is shown in Figure 2 1-7 below 2218 2219 2220 2221 2222 2226 2227 Target 1 USER Authentication Server Target 2 Credentials This is figure is U 2228 2229 2230 2231 2232 Figure 2 1-7 U Centralized Architecture for Single Sign-On U In the centralized model the user signs on to the centralized gate-keeping authentication server and if successful is then automatically signed on to further participating services and or applications to which the user is entitled--based on the user's credentials UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-48 UNCLASSIFIED FOR OFFICIAL USE ONLY 2233 2234 2235 2236 2237 2238 2239 2240 2241 2242 2243 2244 2245 2246 2247 2248 2249 2250 2251 2252 2253 2254 2255 2256 U There are several problems with this model The user must fully trust the authentication server which may be problematic if the authentication server is managed by a second party such as Microsoft There also is the potential problem of basic security in that the authentication server is a single point of failure or central point of attack Finally there may be a privacy problem in that personal information could be collected as part of the authentication information U Note also that if the centralized authentication server were to be temporarily unavailable a user would be precluded from accessing any additional target system during this period 2 1 3 6 1 2 2 U Federated Model U In general as target systems become more numerous and as networks of systems become more complex a centralized architecture becomes too complicated to manage efficiently In this case a federated architecture becomes more desirable With federated authorization credentials are propagated in a less centrally-controlled method than the original Microsoft Passport model In addition as the number of target systems and even operating systems proliferates it is desirable that the SSO methodology be standards-based There are currently three standardsbased SSO techniques Kerberos via Tickets PKI via Certificates and Security Assertion Markup Language SAML via Assertions U Since the GIG will have a broad geographic sweep in addition to a large number of interrelated participating organizations partners it is logical for the GIG to adopt a federated model for Single Sign-On implementation The three candidates are described as follows 2 1 3 6 1 2 2 1 U KERBEROS Tickets U Kerberos is a password-based authentication protocol mechanism that is based upon symmetric cryptography A user's password does not pass unprotected through a network subject to potential sniffing attacks by adversaries Single sign-on can be implemented using Kerberos in the following manner as shown in Figure 2 1-8 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-49 UNCLASSIFIED FOR OFFICIAL USE ONLY Authenticate TGT User KDC TGT Target Ticket Target This is figure is U 2257 2258 Figure 2 1-8 U Federated KEBEROS Based Single Sign-On 2259 U Initially a user would authenticate to a Key Distribution Center KDC which would in turn issue the user an encrypted Ticket Granting Ticket TGT For the lifetime of the TGT typically several hours the user is authorized to access a given target system by presenting the TGT back to the KDC The KDC in turn then issues an enabling ticket that the user can present to the desired target system without need for further authentication Kerberos can be used across Kerberized platforms and or applications It is the standard inter-domain authentication protocol in Microsoft Windows NET Server OSs and Windows 2000 Microsoft is updating its original basic Passport system using this model Federated Microsoft Passport One improvement is that a user can acquire a collection of target tickets and subsequently access a variety of target systems within the ticket lifetimes even if the KDC was to become unavailable due to an intervening system failure or KDC communication problems 2260 2261 2262 2263 2264 2265 2266 2267 2268 2269 2270 2271 2272 2 1 3 6 1 2 2 2 U PKI Certificates U A SSO system based upon credential attributes following the syntax defined by PKI X 509 certificates is shown in Figure 2 1-9 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-50 UNCLASSIFIED FOR OFFICIAL USE ONLY Authentication Server USER Credentials Certificate Target This is figure is U 2273 2274 2275 2276 2277 2278 2279 2280 2281 2282 2283 2284 2285 2286 2287 2288 2289 2290 2291 2292 2293 2294 2295 2296 Figure 2 1-9 U Federated PKI-based Single Sign-on U This model is federated in the sense that all the potential target systems are treated as equals in that they would each have assigned credential attributes defined within the SSO-enabling certificate and the user may request access at any time to a pre-defined included target system When the user attempts to login to a candidate target system it would forward its authorizing credentials held within an encrypted version of its attribute certificate This certificate would have been signed by the original authorizing trust authority using the private key of that authority and it could be thus verified by the target system as authentic through use of the originating trust authority's public key This application of digital signature technology thus enables the user to subsequently and transparently login to as many candidate target systems as are defined and allowed by the user's credential certificate U In addition to the certificate being digitally signed by the originating trust authority it would be forwarded to candidate target systems in an encrypted format by using the public key of the target system Any target system could then easily decrypt the password attributes through application of its own private key As far as the user is concerned all of the processing and transference of the attribute certificates would be done transparently in the background with the user simply accessing the target system and requesting use of available resources U Use of PKI-based asymmetric key technology could mesh nicely with the maturing DoD PKI and its supporting CAC smart card technology which would retain the private key of each respective user 2 1 3 6 1 2 2 3 U SAML Assertions U Finally an alternative SSO implementation may be based upon SAML as shown in Figure 2 1-10 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-51 UNCLASSIFIED FOR OFFICIAL USE ONLY FEDERATED SAML-Based SSO User Authentication Server Credentials Request Signed SAML Assertion Target This is figure is U 2297 2298 2299 2300 2301 2302 2303 2304 2305 2306 2307 2308 2309 2310 2311 2312 2313 2314 2315 2316 2317 2318 2319 2320 2321 2322 Figure 2 1-10 U Federated SAML-Based Single Sign-On U Within a SAML-based SSO the authentication server and all relevant target systems form a Circle of Trust to which a user may exercise SSO privileges It is federated in the sense that the circle of trust is a predefined collection of target systems to which the user may potentially wish to apply the SSO mechanism Each of the federated target systems is aware of the existence of the authentication server and knows how to request the signed SAML assertion when needed U FOUO There are several examples of SAML being applied in projects in the DoD One of these is the U S Navy's Space and Naval Warfare Systems Command SPAWAR Navy Enterprise Portal program in which SSO capabilities based upon SAML are being introduced in order to tie together an estimated 200 000 applications on the Navy-Marine Corps Intranet reached by 720 000 users distributed among active service members civilian Navy employees and contractors In an initial demonstration SAML-enabled SSO was provided to 5 500 users aboard the aircraft carrier USS Teddy Roosevelt U FOUO Another example of SAML being used in DoD programs is the DISA DIA Defense Intelligence Agency Virtual Knowledge Base VKB program As is normally done with SAML implementations of SSO this program uses the XML signature of the SAML assertions to provide for the non-repudiation of authentication authorization credentials In a prototype demonstration the computation and processing burden of applying digital XML signatures was quite manageable and shown to be able to scale well to large user populations This program also looked into the option of employing XML encryption of the SAML assertions in order to provide for confidentiality during transport Unlike the XML signature experience the XML encryption took much more computation time and was shown to not be amenable to scaling well to large populations An alternative to using XML encryption would be to use the SAML implementation within established SSL TLS Secure Sockets Layer Transport Layer Security encrypted connections since SSL is a proven and efficient protocol UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-52 UNCLASSIFIED FOR OFFICIAL USE ONLY 2323 2 1 3 6 2 U Usage Considerations 2324 2 1 3 6 2 1 U Advantages U There are many clear advantages to SSO For the individual user the benefits are highlighted by the convenience of not having to authenticate into each service that is accessed over the web and having to remember a large number of passwords 2325 2326 2327 2328 2329 2330 2331 2332 2333 2334 2335 2336 2337 2338 2339 2340 2341 2342 2343 2344 2345 2346 2347 2348 2349 2350 2351 2352 2353 2354 2355 2356 2357 2358 U In turn SSO serves as a driver to the required supporting technologies of robust multifactorsecure authentication with biometrics smart cards etc by serving as the gatekeeper at the front end It also provides a robustly implemented privilege management infrastructure which keeps straight those net resources that a user can access through SSO 2 1 3 6 2 2 U Risks Threats Attacks U There were some disadvantages associated with the early versions of SSO technologies For example concerning password synchronization while having a password synchronized across many applications may be more convenient for the user it also results in a point of vulnerability If a single password can be compromised this compromises all applications linked to that password This risk aggregation problem clearly unacceptable in the GIG is one of the key reasons why an earlier generation of so-called enterprise SSO products was not broadly adopted Other factors that limited early adoption were the complexity and cost of deployment U FOUO As the various SSO standards have been developed and deployed a number of additional weaknesses were uncovered These have led to revising and strengthening the underlying standard protocols In 2000 D Kormann and A Rubin of AT T Labs described weaknesses of the Microsoft Passport SSO protocol in their paper Risks of the Passport Single Sign-On Protocol See http avirubin com passport html They identified three attacks on Passport 1 Bogus Merchant Attack where a user accesses a web site controlled by a malicious attacker who then proceeds to steal the user's valuable authentication information 2 Active Rewrite Attack and 3 DNS Domain Name System Attacks Requiring SSL security for all Passport exchanges would protect against the active rewrite attack Similarly adoption of DNSSEC enhancements See http www dnssec net would help to protect against DNS attacks U In 2003 SAML attacks were uncovered by T Gross of IBM in Security Analysis of the SAML Single Sign-On Browser Artifact Profile See http www acsac org 2003 papers 73 pdf The attacks that were uncovered included Connection Hijacking Replay Attack Man-in-the-Middle Attack by DNS spoofing and HTTP Referrer Attack Recommended solutions include use of secure channels such as SSL 3 0 or TLS 1 0 with unilateral authentication for all SAML-related message transfers Clearly as the various competing SSO protocols Kerberos-based PKI-based or SAML-based are implemented and studied additional weaknesses and vulnerabilities may be discovered This should only lead to strengthening the protocols as they are revised UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-53 UNCLASSIFIED FOR OFFICIAL USE ONLY 2359 2360 2361 2362 2363 2364 2365 2366 2367 2368 2369 2370 2371 2372 2373 2374 2375 2376 2377 2378 2379 2380 2381 2382 2383 2384 2385 2386 2387 2388 2389 2390 2391 2 1 3 6 3 U Maturity U Due to the increasing demands for enterprise-wide SSO capabilities SSO technology has been maturing at a rapid pace over the past decade--pushed by the competitive pressures of the commercial marketplace This has led to a variety of incompatible proprietary implementations which has in turn led towards the desirable evolution of standards-based SSO architectures and protocols Unfortunately several distinct and incompatible islands of SSO standards have emerged e g Kerberos PKI SAML but there also has been a movement towards the interoperable merger of these standards so that truly universal and cross-platform SSO capabilities can emerge In general these individual technologies can be described as Mature TRL 7 - 9 2 1 3 6 4 U Standards U The development of the various SSO architectures has been conducted in a number of formalized standards organizations and industrial vendor alliances These are discussed below U There has been some movement towards the interoperability-enabling convergence of the various SSO standards protocols and their associated camps of supporting vendors This is potentially advantageous to the evolution of the GIG which should not be hindered by the adoption of security mechanisms that may eventually lose in the standards arena One example of this convergence is work on defining SAML assertions in X 509-syntax attribute certificates See the privilege and role management infrastructure standards site at http www permis org and the NSF Middleware Initiative site at http www nsf-middleware org NMIR5 Another example of similarities between the PKI and Kerberos standards is that X 509 sign-on privilege attributes can be pre-defined with a validity period of hours or days just like the Federated Kerberos-Based SSO architecture with its fixed lifetime tickets This eliminates the need for the formalized revocation of X 509 attributes as compared against the usually infrequent occurrence of revoking crypto keys in PKI X 509 public key certificates U It is also interesting to note that the Kerberos V5 version implements extensions to the original Kerberos protocol to permit initial SSO server authentication using public keys on smart cards The original Kerberos protocol relied on symmetric secret key algorithms U Due to the continued success of each of the standards in its respective application domains a mutual convergence of interoperability is preferable to conflict For example Kerberos is well known for certain applications and is supported by modern operating systems whereas PKI certificate systems are widely spread e g DoD PKI and can provide portability across platforms UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-54 UNCLASSIFIED FOR OFFICIAL USE ONLY 2392 2393 2394 2395 2396 2397 2398 2399 2400 2401 2402 2403 2404 2405 2406 2407 2408 2409 2410 2411 2412 2413 2414 2415 2416 2417 2418 2419 2420 2421 2422 2423 2424 2425 2426 2427 2428 2429 2430 2431 2432 U Large and influential vendors such as Microsoft which has a history of supporting the WSFederation Kerberos-based SSO methodology have introduced the concept of protocol transition This is supposed to be a feature of Microsoft's Windows NET Server and should allow a user to gain access to NET Server-based resources by any one of a number of authentication mechanisms Kerberos PKI X 509 digital attribute certificate SAML etc The target Windows NET Server would then transition the sign-on token into a Kerberos ticket for use in the backend This is an example of how if provided with enough appropriate Inter Working Functions a conglomeration of SSO standards can be made to interoperate successfully and securely 2 1 3 6 4 1 U WS-Federation Microsoft IBM U The Kerberos-based SSO architecture has been championed primarily by Microsoft and its WS-Federation standard promulgated jointly with IBM See http www106 ibm com developerworks webservices library ws-fed It is based upon the original IETF RFC 1510 The Kerberos Network Authentication Service by J Kohl and C Neuman September 1993 found at http www ietf org rfc rfc1510 txt U Kerberos developed at the Massachusetts Institute of Technology is a system that depends on passwords and Data Encryption Standard DES symmetric cryptography in order to implement ticket-based peer entity authentication service and SSO access control service distributed in a client server network environment Kerberos came out of Project Athena and is named for the mythical three-headed dog guarding Hades U The overall Web Services Security Specification roadmap entitled Security in a Web Services World A Proposed Architecture and Roadmap was promulgated by Microsoft and IBM in April 2002 The base layer is called WS-Security on top of which lie the layers of WSPolicy WS-Trust WS-Privacy WS-SecureConversation WS-Authorization and WS-Federation enabling SSO single sign-on After development of these specifications they were turned over to the non-profit OASIS standards body See below 2 1 3 6 4 2 U ITU U The United Nations ITU-T standards organization http www itu int home based in Geneva Switzerland has been evolving its PKI-enabling X 509 standard into a standard that will support SSO-enabling attribute certificates 2 1 3 6 4 3 U SAML OASIS U The SAML v1 1 standard was approved and promulgated in September 2003 by the Organization for the Advancement of Structured Information Standards OASIS at http www oasis-open org Webopedia defines SAML as an XML Extensible Markup Language -based framework for ensuring that transmitted communications are secure SAML defines mechanisms to exchange authentication authorization and non-repudiation information allowing SSO capabilities for web services This allows organizations to create contractual federations and enables browsing end-users to reach services using a SSO with appropriate authentication authorization information SAML technology does not define any new authentication techniques itself but rather merely enables the existing technology in XML SAML is also targeted as a security services implementation to support Internet2 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-55 UNCLASSIFIED FOR OFFICIAL USE ONLY 2433 2434 2435 2436 2437 2438 2439 2440 2441 2442 2443 2444 2445 2446 2447 2448 2449 2450 2451 2452 2453 2454 2455 2456 2457 2458 2459 2460 U In order to foster the use of SAML as open source software OpenSAML http www opensaml org has been developed It is a set of open source Java and C libraries that are fully consistent with the formal SAML standard specifications The OpenSAML toolkit may be licensed royalty-free from RSA 2 1 3 6 4 4 U Liberty Alliance U The Liberty Alliance Project Liberty http www projectliberty org was organized and introduced in 2001 It is a joint effort by 38 different companies with Sun Microsystems as the motivating force Also involved are staunch supporters of open source software such as the Apache Software Foundation and O'Reilly Associates Other involved technology companies include Verisign RealNetworks and Cisco U Liberty Alliance is adopting the SAML SSO architecture and protocols Due to Sun Microsystems support of SAML it is being applied in the Java sphere The related Java technology API Application Programming Interface standard for SAML is covered by Java Specification Request JSR-155 See http www jcp org 2 1 3 6 5 U Cost Limitations U While there are initial costs to implementing a robust and wide-reaching SSO capability the eventual return on investment can be huge and the realization of this is one of the prime drivers in persuading organizations to adopt SSO technology When an automated and secure standardsbased SSO system replaces a myriad of existing and disjoint independent traditional sign-on mechanisms a tremendous administrative burden is lifted from the shoulders of both the individual user and the system administrator e g help desks A broadly adopted standardsbased approach also allows for clearly defined evolution paths for SSO implementation 2 1 3 6 6 U Dependencies U Certainly one of the most important dependencies of a robustly secure SSO system is that a SSO architecture relies greatly on a very strong and secure multifactor initial user authentication since if a malicious attacker were to successfully accomplish an invalid initial SSO login they would effectively be given the keys to the kingdom of the violated authentic user or one-stop shopping for hackers 2465 U The GIG thus is sure to benefit from a robustly developed and standards-based methodology of SSO Fortunately the evolution of SSO technologies is being driven by a number of strong commercial market forces Specifically there are three legislative processes that are requiring effective SSO capabilities in future commercial IT systems particularly those dealing with sensitive--either personal or corporate proprietary--information 2466 o U Within the domain of corporate governance the Sarbanes-Oxley Rule 404 requires public companies to centralize the reporting of who has access to what and who uses what Moreover business governance and privacy laws in many countries impose similar requirements o U Similarly in the financial services market the Gramm-Leach-Bliley Act specifies the need for stronger audit and separation of duties in order to control who how and when users 2461 2462 2463 2464 2467 2468 2469 2470 2471 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-56 UNCLASSIFIED FOR OFFICIAL USE ONLY access information and systems 2472 2473 2474 2475 2476 2477 2478 2479 2480 2481 2482 2483 2484 2485 2486 2487 2488 2489 2490 2491 2492 2493 o U Finally the healthcare market is a primary revenue-driving segment for many SSO vendors The Health Insurance Portability and Accountability Act HIPAA requirement for an audit trail that associates information access to individual identities becomes mandatory in April 2005 Healthcare typically involves the deployment of workstations that need to be accessed by many healthcare workers who must frequently and quickly log in and out of these systems A robust and secure SSO technique will be very beneficial to this requirement 2 1 3 6 7 U Alternatives U The alternative to implementation of an integrated SSO infrastructure within the GIG is to continue the operation of disparate and independently maintained and administered SSO mechanisms for each application or resource that GIG users will want to use A partial solution which could be application sensitivity-based in that SSO capability could be developed for most of the GIG-spanning resources However certain very sensitive e g command and controloriented applications may require independent and rigorously assured authorization and authentication every time they are accessed As the GIG-wide SSO solution and supporting privilege delegation infrastructure matures the scope of its applicability may indeed expand 2 1 3 6 8 U References U Simple Authentication and Security Layer http asg web cmu edu sasl U Single Sign-On and the System Administrator by M Grubb and R Carter Duke University LISA'98 conference http www usenix org publications library proceedings lisa98 full_papers grubb grubb pdf 6-11 December 1998 2495 U Single Sign-On Architectures presentation by Jan De Clercq HP http www esat kuleuven ac be cosic seminars slides SSO pdf 2002 2496 U Identity Management A Technical Perspective presentation by Richard Cissee 2497 http www calt insead edu fidis workshop workshop-wp2december2003 presentation%5CTUB%5CTUB_fidis_wp2_workshop_dec2003 ppt December 2003 2494 2498 2499 2500 2501 2502 2503 2504 2505 2506 U Single Sign-On Across Web Services presentation by Ernest Artiaga CERN OpenLab Security Workshop http openlab-mu-internal web cern ch openlab-muinternal Documents Presentations Slides 2004 04-09_EA_Security_Wokshop-SingleSignOn ppt April 2004 U Navy Deploying Its Battle Plan SAML by Anne Chen http www eweek com article2 0 1759 1502403 00 asp 20 October 2003 U Lessons Learned in a Department of Defense Program The Virtual Knowledge Base VKB presentation by Kevin Smith http www omg org news meetings workshops Web%20Services%20USA%20Manual 02-3_K_Smith pdf UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-57 UNCLASSIFIED FOR OFFICIAL USE ONLY 2508 U Web Services Security presentation by Sang Shin Sun Microsystems http www javapassion com webservices WebServicesSecurity4 pdf January 2004 2509 U SAML Basics presentation by Eve Maler http www2002 org presentations maler pdf 2002 2510 U Survey of the Status of Security and Emerging Security Innovations for Key Technological Protocols Recommendations Specifications and Standards Used in E-commerce by Angela Mozart http www giac org practical GSEC Angela_Mozart_GSEC pdf November 2003 2507 2511 2512 2513 2514 U Gartner report Password Management Single Sign-On and Authentication Management Infrastructure Products Perspective by Ant Allan 7 January 2003 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-58 UNCLASSIFIED FOR OFFICIAL USE ONLY 2515 2516 2517 2518 2 1 4 U I A Gap Analysis U FOUO Gap analysis for the Identification and Authentication Enabler indicates that the main areas of required future development are as follows o U FOUO Complete the development of Protection Profiles for Medium and High Assurance authentication technologies e g biometrics o U FOUO Develop an authentication framework standard that includes SoM levels authentication session scoring and a SoM forwarding structure o U FOUO Develop a standard for the methods protocol of remote access point retrieval of authentication privileges o U FOUO Develop a token with onboard biometric and liveness test to assure that automated logon is not taking place or offboard biometrics communicated to token Candidate offboard biometrics are iris scan retinal scan face recognition hand geometry voice recognition etc Based on current technology only a thumbprint fingerprint reader could be integrated directly onto a smart card token o U FOUO Develop a high assurance DoD PKI Class 5 token w Type I cryptography where definition of Class 5 token is for use with classified information hardware token using Type I cryptography having assurance trust in security critical functionality throughout its lifecycle including design development production fielding and maintenance o U FOUO Develop a scalable re-authentication scheduling algorithm adjustable per sensitivity of application access location and user profile o U FOUO Develop a scalable authentication server that is able to interpret and use I A session scores and comply with the GIG authentication standards The server function will need to be secure efficient accurate and transparent in terms of performance impact In addition it should operate in multiple architectural constructs e g in-line embedded co-processor remote o U FOUO Develop an Identification Registration Management Infrastructure that can support all GIG customers DoD IC and all temporary permanent partners o U FOUO Develop a common GIG-wide Single Sign On mechanism protocol and architecture o U FOUO Develop a GIG standard for authentication confidence metrics 2519 2520 2521 2522 2523 2524 2525 2526 2527 2528 2529 2530 2531 2532 2533 2534 2535 2536 2537 2538 2539 2540 2541 2542 2543 2544 2545 2546 2547 2548 2549 2550 U FOUO In addition the following gaps must be satisfied under other IA System Enablers that directly support this IA System Enabler o U FOUO Develop converged standards for Partner Identity Proofing enabling identity interoperability with future GIG partners e g allies coalition partners civil government DHS See Section 2 7 Management of IA Mechanisms and Assets UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-59 UNCLASSIFIED FOR OFFICIAL USE ONLY 2551 o U FOUO Develop a common identification management and ID proofing standard for all future GIG entities human users devices processes See Section 2 7 Management of IA Mechanisms and Assets o U FOUO Ensure metadata standard includes the capability for binding authenticated sources to GIG information See Section 2 2 Policy-Based Access Control 2552 2553 2554 2555 2556 2557 2558 U FOUO Technology adequacy is a means of evaluating the technologies as they currently stand This data can be used as a gap assessment between a technology's current maturity and the maturity needed for successful inclusion in the GIG in 2008 2562 U FOUO The following two tables list the adequacy of the Identification and Authentication technologies with respect to the enabler attributes discussed in the RCD Not shown in the tables below are entries for Authentication Protocols which are in general quite adequate in so far as their strength and flexibility is concerned 2563 Table 2 1-3 U Technology Adequacy for Tokens and Biometrics 2560 2561 This Table is U Technology Category Tokens Enabler Attribute 2559 Biometrics Required Capability attribute from RCD Standard IAAU3 IAIR2 IAIR4 Secure Solution IAAU1 IAAU3 IAAU8 IAAU9 IAAU18 IAAU19 IAAU20 IAIR1 IAIR6 IAAU10 IAAU23 IAIR2 IAIR5 IAIR6 N A Scalable Solution Protection Profile IAAU1 High Assurance IAAU2 IAAU24 N A Distributed Global Reach IAAU1 IAAU6 IAAU17 IAAU21 IAIR2 IAAU1 IAAU12-IAAU15 IAIR1 IAIR3 IAIR4 IAIR5 Verifiable Solution This Table is U UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-60 UNCLASSIFIED FOR OFFICIAL USE ONLY Table 2 1-4 U Technology Adequacy for Single Sign-On and Authentication 2564 This Table is U Technology Category Single Sign On Authentication Device Confidence Authentication Secure Solution N A IAAU4 IAAU5 IAIR1 IAIR7 IAAU8 IAAU22 IAIR6 Scalable Solution N A IAAU23 IAIR6 IAIR7 Standard Enabler Attribute Required Capability attribute from RCD Protection Profile High Assurance N A N A N A IAAU22 IAAU6 IAAU25 IAAU23 IAAU21 IAAU17 IAIR7 Distributed Global Reach Verifiable Solution N A IAIR1 This Table is U 2565 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-61 UNCLASSIFIED FOR OFFICIAL USE ONLY 2566 2567 2568 2 1 5 U Identification and Authentication Recommendations and Timelines U The following is a list of preliminary recommendations for advancing the technologies required for the successful implementation of this GIG enabler o U FOUO Define a converged Partner Identity Proofing standard that has been vetted and accepted by partner communities o U FOUO Develop a common GIG-wide device service authentication techniques and standards due to the relative immaturity of this technology area o U FOUO Rapidly advance research into the relatively new area of authentication confidence metrics 2575 o U FOUO Develop a scalable robust and distributed authentication server capability 2576 o U FOUO Develop an accepted high assurance biometric authentication technique 2577 o U FOUO Assure ongoing and future developments of the DoD CAC Common Access Card will support all future GIG requirements including Class 5 token o U FOUO Advance the selection of a GIG-wide architecture for Single Sign-On from the candidates described in this document such as SAML-based or PKI-based Include in this process the complete analysis of the proposed NCES single sign-on architecture 2569 2570 2571 2572 2573 2574 2578 2579 2580 2581 2582 2583 2584 2585 U FOUO Figure 2 1-11 contains preliminary technology timelines for this IA System Enabler These are the result of research completed to date on these technologies As the Reference Capability Document and the research of technologies related to these capabilities continue these timelines are expected to evolve Technology 2004 2006 2008 Authentication Tokens Hardware Tokens 2010 2012 2014 2016 2018 2020 IA Enhanced CAC Biometrics Device Service ID Mechanisms Device Service Authentication Medium High assurance Medium High assurance Biometric PP Biometric products available Device service standard Authentication Standard implemented accepted device service Single Sign-on NCES IOC single sign-on Authentication Session Score Standard Ratified Single Sign-On Architecture for the GIG Strength of Mechanism Session Scoring Authentication Confidence Authentication confidence standard This Figure is U FOUO 2586 2587 Authentication confidence standard implemented Figure 2 1-11 U Technology Timeline for Identification Authentication UNCLASSIFIED FOR OFFICIAL USE ONLY 2 1-62 UNCLASSIFIED FOR OFFICIAL USE ONLY 2588 2589 2590 2591 2592 2593 2594 2595 2596 2597 2598 2599 2600 2 2 U POLICY-BASED ACCESS CONTROL U FOUO Policy-Based Access Control is the use of flexible hierarchical rules to determine whether to grant or deny access to GIG assets at points throughout the GIG This policy-based access control capability is also distributed It provides common GIG access control services across the enterprise supports an enterprise wide digital access policy and provides decision processing location transparency to the user to improve availability and load sharing capability GIG assets include all resources within the enterprise such as hardware e g routers servers workstations security components software e g services applications processes firmware bandwidth information and connectivity U FOUO From a context prospective today's information sharing capabilities are not sufficient to support the net-centric operations vision Current information sharing is far too constrained through 2601 o U FOUO A culture that fosters not sharing 2602 o U FOUO Physically separate system-high environments 2603 o U FOUO Limitations of information assurance IA technology to safely support assured information sharing 2604 2605 2606 2607 2608 2609 2610 2611 2612 2613 2614 2615 2616 2617 2618 2619 2620 2621 U FOUO Our no-risk culture allows access to classified information only to recipients who have the proper clearance and a need-to-know But this accessibility culture must change to support the vision of information sharing functionality that empowers users through easy access to information anytime anyplace and anywhere in support of operational requirements with attendant security U FOUO The GIG information sharing philosophy is fundamentally different as it is a sharing centric security philosophy The user is presented with information consistent with such factors as his security clearance operational situation privilege and policy then decides what information is needed and pulls that information This differs from the need-to-show paradigm in which the data originator decides to whom to provide the data i e no one else knows the data exists U FOUO Policy-Based Access Control supports this need to share paradigm and represents a transformation of historical mandatory and discretionary access control It considers security risk and operational need as part of each access control decision It thus recognizes that situational conditions e g peacetime war terror threat levels location of people will drive the relative weight of operational need and security risk in determining access UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-1 UNCLASSIFIED FOR OFFICIAL USE ONLY 2622 2623 2624 2625 2626 2627 2628 2629 2630 2631 2632 U FOUO The access control decisions can adapt to varying situational conditions in accordance with an access control policy Each policy prescribes the criteria for determining operational need the acceptable security risk and the weighting between the two under various conditions Thus the model can support extremely restrictive policies and also those that provide the widest sharing under specific conditions with added risk This new access control model has been named Risk Adaptable Access Control RAdAC 2 2 1 U GIG Benefits due to Policy-Based Access Control U FOUO The Information Assurance constructs used to support Policy-Based Access Control provide the following services to the GIG o U FOUO Provides standardized access control behavior for information communications and services throughout the GIG o U Provides fine-grained access control based on the labeled value and life cycle constraints of the information o U Provides fine-grained access control based on the privileges and priority of the user user is defined as a human user entity or service o U FOUO Provides ability to segregate multiple communities sharing the GIG to increase availability while providing dynamic connectivity as needed o U FOUO Supports Single Sign-on SSO because an authorization granted is then recognized throughout the GIG o U Allows flexibility to tailor aspects of enterprise policies by region COIs C2 Node etc o U Supports data owner information life cycle policy to track and control object creation dissemination use and destruction 2633 2634 2635 2636 2637 2638 2639 2640 2641 2642 2643 2644 2645 2646 2 2 2 2647 2 2 2 1 U Core RAdAC Functions U FOUO Policy-Based Access Control is a critical enabler for sharing information and services within the GIG Access Control checks will no longer follow the traditional check for an exact match of mandatory e g credentials and discretionary e g privileges checks Instead the RAdAC Model will be employed RAdAC is a rule-based access control policy based on real-time assessment of the operational need for access and the security risk associated with granting access Figure 2 2-1 depicts the RAdAC model There are two core functions within RAdAC Security Risk Determination and Operational Need Determination 2648 2649 2650 2651 2652 2653 2654 2655 U Policy-Based Access Control Description UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-2 UNCLASSIFIED FOR OFFICIAL USE ONLY Characteristics of People Characteristics of IT Components Characteristics of Soft Objects Environmental Factors Situational Factors Heuristics Security Risk Determination Function Security Risk Level Access Decision Function Digital Access Control Policies Operational Need Determination Function Decision and Supporting Rationale Operational Need Access Authority Interaction Access Request This figure is U 2656 Figure 2 2-1 U RAdAC Functional Model 2657 2661 U FOUO Security Risk Determination provides a real-time situational and probabilistic determination of the security risk associated with granting the requested access The challenge here is to come up with ways to quantitatively express risk The security risk for granting the access will be determined for at least three different areas 2662 o U FOUO The person receiving the information 2663 o U FOUO The IT components the person is using 2664 o U FOUO Those that will otherwise be involved in sharing the information 2658 2659 2660 2665 2666 2667 2668 2669 2670 2671 2672 2673 2674 2675 U FOUO Operational Need Determination assesses the operational need of a requestor to access some information A person's membership in some COI or organization their rank or role in an organization their location or a supervisor's approval might all be contributing factors to establishing their need to know information but ultimately access control policy will specify how to use these factors to determine operational need U FOUO An important attribute of Operational Need Determination is the capability of allowing an exception to an access control decision The access control policy would specify who is entitled to approve an exception For example a commander may determine particular data is critical to his mission and grant access to data to which his forces would normally not have access However the policy must grant the commander this right UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-3 UNCLASSIFIED FOR OFFICIAL USE ONLY 2676 2677 2678 2679 2680 2681 2682 2 2 2 2 U Assured Metadata and Data Describing Enterprise Elements U FOUO Assured metadata and data describing enterprise elements such as users IT components environment and situation serve as inputs to the RAdAC functional model Not all inputs may be required to make a specific access decision Digital access control policy will dictate the minimum decision criteria and how limited input affects the access control decision o U FOUO Characteristics of people who create and consume information will be used to measure their risk and to determine their operational need These characteristics might include identifier citizenship security clearance level and source of clearance organization COI membership military rank length of service current operational assignment job title GIG system privileges--and any other characteristics that might be usable in determining their security risk and operational need Characteristics of the authentication process that granted a person access to the system would also be included here since multiple proofs of identity increase how certain the system is concerning the true identity of a requester o U FOUO Characteristics of IT components that create information and enable users to create share and use information will be used to determine security risk Determining the robustness of the components is the primary consideration Therefore such things as identifier operating system hardware platform features current configuration conformance to certified configuration third-party robustness evaluation owning organization system administrator characteristics connectivity to unprotected networks and software distribution protection might be characteristics considered when determining the risk associated with IT components Furthermore the operation of these components as a system must be considered o U FOUO Characteristics of Soft Objects contribute to the access decision affecting both the security risk measurement and the determination of operational need Soft objects include data applications and services o U FOUO The important characteristics of an object being accessed might include its identifier source originator or controlling entity including COIs a description of the type of data and its value a description of the data source and its pedigree intended roles and expected uses of this object object life cycle properties and traditional labeling information Object life cycle properties include object-level attributes that constrain use dissemination and disposition after use o U FOUO Traditional labeling information would include such data as classification level releasability and caveat handling The metadata will be cryptographically bound to the data to which it applies so the requestor can validate the authenticity of the data o U FOUO Environmental factors apply to people IT components and objects UNCLASSIFIED FOR OFFICIAL USE ONLY 2683 2684 2685 2686 2687 2688 2689 2690 2691 2692 2693 2694 2695 2696 2697 2698 2699 2700 2701 2702 2703 2704 2705 2706 2707 2708 2709 2710 2711 2712 2713 2714 2715 2716 2 2-4 UNCLASSIFIED FOR OFFICIAL USE ONLY and can be used in determining both security risk and operational need Environmental factors include such things as a physical location and any adversarial threat associated with that location The adversarial threat should be tied to the GIG operational threat model and risk assessment It might indicate for a particular location--or class of locations--the probability that a specific threat or attack could happen Location might also be a factor in determining operational need All GIG users in a particular location such as Iraq might have a need to access some specific class of information 2717 2718 2719 2720 2721 2722 2723 2724 2725 o U FOUO Situational factors are national enterprise-wide or local indicators of some situational condition that might affect access control decisions The terrorist threat level for example might be used to change criteria for determining operational need For example an indication that the enterprise is under cyber attack or nuclear attack might be other such situational indicators that could affect access o U FOUO Heuristics are intended to represent the knowledge of the information sharing system that it has acquired from past information sharing and access control decisions User-based heuristics might capture previously granted object access and can be used to help assess current risk and weigh operational need for future similar access requests System-based heuristics may capture knowledge of compromises that have resulted under various access conditions in order to refine policy to avoid similar future compromises A policy must specify the degree to which heuristics should be considered in each access decision 2726 2727 2728 2729 2730 2731 2732 2733 2734 2735 2736 2737 2738 2739 2740 2741 2742 2743 2744 2745 2746 2747 2748 2749 2750 2751 2752 2753 2754 2 2 2 3 U Digital Access Control Policy U FOUO Digital access control policies will be the key to making the RAdAC model successful They must be capable of specifying the policy for each step of the access control process They must also be capable of expressing rules for various types of access such as discovery retrieval modification and execution rights In other words the requestor may be able to discover the object service but may not have rights to access the data without verification of need to know U FOUO A policy would also be conditional in nature It could stipulate different rules of access depending on the current operational condition or mission need An example condition might be the current DEFCON level Under one condition access might be limited to those within a COI while under another condition those with special operational needs might be given access Policy flexibility is crucial U FOUO Another aspect of digital access control policies is that multiple policies will exist in the GIG There will be enterprise level policies and local policies e g COI policies The composite set of policies that apply to the object service will be enforced during access control checks UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-5 UNCLASSIFIED FOR OFFICIAL USE ONLY 2755 2756 2757 2758 2759 2760 2761 2762 2763 2764 2765 2766 2767 2768 2769 2770 2771 2772 2773 2774 2775 2776 2777 2778 2779 2780 2781 2782 2783 2784 2785 2786 2787 2788 U FOUO For access control to meet the information sharing needs of the GIG digital access control policy must extend beyond the initial RAdAC decision through the inclusion of object life cycle attributes that accompany the soft object For example these attributes will specify whether the entity can save or print or forward the object whether it is provided as read only when the object's lifetime will expire and what methods are acceptable for secure disposal of an object 2 2 2 4 U IA Enabler Dependencies U FOUO Identification Authentication The authenticity of requester can be measured through the robustness and number of authenticators used to validate the requester's identity Periodic re-authentication may be necessary for a I A Strength of Mechanism SoM score to be considered viable by the RAdAC model U FOUO Protection of User Information This environment will be a significant factor in calculating security risk since it is a major portion of the Characteristics of IT Components input U FOUO Dynamic Policy Management Digital access control policy will be a subset of the policies managed dynamically in the GIG The distributed RAdAC function will require the distribution synchronization and revocation capabilities offered by the Dynamic Policy Management environment U FOUO Network Defense and Situational Awareness RAdAC policy depends upon the enterprise's Information Condition INFOCON and threat levels on suspected or actual Information Warfare attack as a subset of its Situational Factors input U FOUO Management of IA Mechanisms and Assets RAdAC will depend upon this enabler to assure use of specific routes that guarantee Quality of Protection management enforcement of IT Components with their approved uses and configurations and certification accreditation of enterprise domains as a risk input 2 2 3 U Policy-Based Access Control Technologies U FOUO For simplicity the discussion of technologies for Policy-Based Access Control is divided into three sections 1 U FOUO Core RAdAC that addresses the internal computation of risk and operational need 2 U FOUO Assured Metadata that supports RAdAC decision-making and enforcement 3 U FOUO Dynamic Policy that influences RAdAC decision-making and enforcement UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-6 UNCLASSIFIED FOR OFFICIAL USE ONLY 2789 2790 2791 2792 2793 2794 2795 2796 2797 2798 2799 2800 2801 2802 2803 2804 2805 2806 2807 2808 2809 2810 2811 2812 2813 2814 2 2 3 1 U Core RAdAC U FOUO The core RAdAC functions of security risk and operational need determination are very new ideas in the access control sphere both in industry and Government Traditionally both these functions have been handled as administrative procedures that are then implemented and enforced through a combination of physical access controls e g locked or guarded facilities and static but modifiable logical access control business rules e g traditional discretionary access controls in mainstream operating systems and mandatory access controls in multilevel environments These static business rules can be correctly referred to as access control policy but the underlying technology essentially assesses a request against a list of authorized actions and provides a binary allow disallow decision to an enforcement mechanism 2 2 3 1 1 1 U Technical details U FOUO IT security risk has historically been a calculation either qualitative or quantitative of the loss expected due to an attack being carried out against a valuable asset with a specific vulnerability The exposure of the asset through the vulnerability and the probability the attack will occur are significant inputs for the final calculation While technologies exist to guide a security professional in performing this type of risk assessment for a business or system applying this technique to the access control domain is a very new idea U FOUO In the access control domain soft objects are the information assets that can be exposed to threats in the environment within a specific situation including users through vulnerabilities in the IT Components themselves This relationship indicates that most of the RAdAC inputs affect security risk determination in one way or another--as described below A high-level analysis of these RAdAC inputs shows that most will be textual in nature o U FOUO Availability and integrity risk - Characteristics of IT components influence whether these tenets of IA would be placed at risk if access is authorized For example authorizing the release of a 40GB imagery file through a 28kbps tactical circuit would effectively cause a sustained denial of service for all users of that tactical circuit o U FOUO Aggregation - Situational Factors should include details of what information is already available at a user's IT platform to assess the risk of aggregation multiple Unclassified documents being combined to learn Classified information As multiple services are subscribed to by a single user the risk of aggregation multiple unclassified inputs classified information increases o U FOUO User information and platform context - Consideration of the classification of current information on the user's IT platform should be considered alongside the capabilities and assurances of the user's platform For example if a cleared user is subscribed to all FOUO services and requests a classified document the risk of disclosure increases greatly if the platform cannot support MLS or MILS processing 2815 2816 2817 2818 2819 2820 2821 2822 2823 2824 2825 2826 2827 2828 2829 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-7 UNCLASSIFIED FOR OFFICIAL USE ONLY 2830 o U FOUO Identity factors - Clearance and formal access approvals of the user assurance of the user's identity and assurance of bindings to roles and COIs are critical factors to determining risk o U FOUO Classification lifetime - Classified lifetime of a Soft Object is an important consideration for risk If declassification is expected within hours versus years and the specific operation that the information pertains to is already underway the risk of disclosure to an uncleared soldier is much lower than it ordinarily would be o U FOUO Violation of traditional access models - All things considered equal any access that violates the Bell-LaPadula properties3 should sharply raise the risk value o U FOUO Probability of overrun - Risk of disclosure should increase due to the proximity of enemy forces and probability of overrun This should be captured in the Environment Factor o U FOUO Unavailable input parameters - Lack of input parameters e g no value for IT environment or low reliability of input parameters e g nonauthoritative source provides input for an IT environment segment should increase the resulting risk due to unknowns o U FOUO Heuristics - Heuristics from previously authorized similar requests proximity with respect to time or content should result in a reduced security risk o U FOUO Transitivity - There are transitive security risks to consider in a highly-connected environment when authorization exceptions are permitted Authorizing a classified document to one member of a COI operating at an unclassified level has implications that reach beyond that individual User making the access request o U FOUO External connections - Since policy negotiations between security domains is a desirable dynamic policy feature there is a potentially higher risk that all information released to an external domain should carry Domain interconnection only begins to scratch the surface of risks associated with interconnections within the GIG o U FOUO Enterprise C A - GIG risks associated with IT Components within the enterprise must be considered in RAdAC risk determination With the direction DIACAP is heading near real-time knowledge of GIG system's risks countermeasures applied to them and residual risk that is accepted by a cognizant approval authority will be available through the eMASS system The RAdAC model should interface to the eMASS services to understand residual risk in systems involved in the access path This data should be presented to RAdAC via 2831 2832 2833 2834 2835 2836 2837 2838 2839 2840 2841 2842 2843 2844 2845 2846 2847 2848 2849 2850 2851 2852 2853 2854 2855 2856 2857 2858 2859 2860 2861 2862 2863 2864 2865 2866 3 U The Bell-Lapadula Model of protection systems deals with the control of information flow It is a linear non-discretionary model UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-8 UNCLASSIFIED FOR OFFICIAL USE ONLY the Characteristics of IT Components and Environment Factors inputs 2867 2868 o U FOUO Identity Strength of Mechanism - A higher authentication robustness e g a 3-factor authentication versus 2-factor should yield a lower risk score o U FOUO Soft Object Life Cycle Characteristics - Soft Object characteristics that limit or preclude widespread dissemination should raise the risk score and imposed life cycle characteristics on a specific instance of information such as do not copy do not print do not further disseminate may reduce the risk of disclosure 2869 2870 2871 2872 2873 2874 2875 2876 2877 2878 2879 2880 2881 2882 2883 2884 2885 2886 2887 2888 2889 2890 2891 2892 2893 2894 2895 2896 2897 2898 2899 2900 2901 2902 2903 2904 2905 2906 U FOUO The other major function of the core RAdAC model is operational need determination a function somewhat understood in the administrative domain and much less understood technologically Outside of workflow technology that retrieves a manager's approval for need-to-know no technology exists to perform this function Characteristics of IT Components will have little to no impact to this function and Situational Factors and Heuristics will probably have the most impact 2 2 3 1 1 2 U Usage considerations U FOUO The successful usage of core RAdAC as the GIG access control model will require substantial proof of correctness a highly robust distributed design low-latency performance life cycle information management and significant buy-in from the various GIG user communities The shift to a need-to-share philosophy is essential but largely depends on the assurances that the technology can mitigate risks associated with doing so U FOUO For RAdAC to be successfully deployed and used throughout the GIG the existence of any alternate access control mechanisms is problematic Part of the RAdAC environment description must address how RAdAC is always invoked and nonbypassable within the enterprise This description contributes to the proof of correctness needed to gain customer acceptance of the technology 2 2 3 1 1 2 1 U Implementation Issues U FOUO Since most of these inputs are textual RAdAC risk determination should be performed using technology that can parse understand meaning and reason about relationships under an imposed policy Otherwise the performance impact of translation between text and numeric scores will prove very costly and RAdAC risks being inflexible in accommodating more than one ontology U FOUO The ontology problem for textual inputs is very significant In a trivial case consider the existing U S Air Force and U S Navy ontologies used daily A user identified with the rank of Captain in the Air Force is an O-3 who is a junior officer compared to a Navy Captain who is a senior O-6 typically assigned to commander roles Operational Need determination should weigh an Air Force Captain's verification of an E-5's need to know as less than a Navy Captain's verification of an E-5's need to know A technology that doesn't understand more than one ontology cannot understand these distinctions that can be critical in determining access control risk and operational need UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-9 UNCLASSIFIED FOR OFFICIAL USE ONLY 2907 2908 2909 2910 2911 2912 2913 2914 2915 2916 2917 2918 2919 2920 2921 2922 2923 2924 2925 2926 2927 2928 2929 2930 2931 2932 2933 2934 2935 2936 2937 2938 2939 2940 2941 2942 2943 2944 U FOUO To comply with national laws that strictly prohibit disclosure of classified information to users without appropriate clearances any immediate implementations of RAdAC must implement a mathematic model to prove correctness for handling classified information To comply with the national law in the near term this model should map to traditional Discretionary and Mandatory Access Control DAC and MAC models and it must never violate the properties established by the Bell-LaPadula confidentiality model U FOUO Commercial access control technology is not heading in the direction of risk calculation Rather industry understands the traditional access control models of DAC and MAC Role-based Access Control RBAC has recently reached maturity and Attribute-based Access Control ABAC is just beginning to mature Because of this the scope of RAdAC may be more suited to the service-oriented architecture domain rather than the operating system domain so that both sets of access control models can coexist U FOUO RAdAC must be able to offer performance guarantees despite the complexity of its calculations and the varied inputs required to make a decision RAdAC must also be deterministic and produce an access control decision for every request U FOUO RAdAC must provide decision rationale to support appeals for operational need-to-know audit and heuristics-based learning U FOUO Heuristics implementation can take the form of either user-based or systembased knowledge of past actions and most likely both are needed In either form the heuristics data must be verifiably system-recorded not spoofed or modified and rapidly available to the RAdAC decision service Heuristics is a desirable RAdAC feature that is not as crucial as other features and can be delayed until later increments U FOUO RAdAC's distributed model must be able to support the dismounted soldier with intermittent connectivity in addition to the CONUS-based desk user and the enterprise service tier This distribution model should be able to synchronize updates to access control policy and information needed to make decisions to support operations in an offline mode U FOUO RAdAC requires assured metadata about Soft Objects and assured data for its other inputs to make an informed decision and protect itself against well-known security threats This assured metadata must be tightly bound to the information it describes and must itself have verifiable integrity U FOUO RAdAC must provide state management to detect and consider repeated failed access attempts This state management needs to be extremely lightweight to scale well in order to support thousands of users 2 2 3 1 1 2 2 U Advantages U FOUO The RAdAC concept offers the following significant advantages relative to traditional access control schemes o U FOUO Supports GIG need-to-share vision through dynamic access control UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-10 UNCLASSIFIED FOR OFFICIAL USE ONLY decision-making that weighs security risk and operational need versus traditional hard-coded access control 2945 2946 2947 o U FOUO Allows broader scope of inputs that contribute to access control decision-making including operational need and situational urgency o U FOUO Provides fine-grained access decisions not just allow or disallow that specify required transport path or object life cycle attributes to secure the risk of granting access 2948 2949 2950 2951 2952 2953 2 2 3 1 1 2 3 U Risks Threats Attacks U The primary risks to RAdAC are o U FOUO Spoofed or altered RAdAC inputs which can allow unauthorized access o U FOUO Access DoS attacks counter detailed in CND RCD section which prevent authorized access by legitimate users 2958 o U FOUO RAdAC bypass direct object access 2959 o U FOUO Distributed environment synchronization attacks 2954 2955 2956 2957 2960 2961 2962 2963 2964 2965 2966 2 2 3 1 1 3 U Maturity U FOUO Both security risk and operational need determination technologies are in the conceptual stage Basic principles have been observed and reported in the Assured Information Sharing Model white paper and practical applications are being explored through a separate study Technology maturity is rated as Early TRL 1-3 2 2 3 1 1 4 U Standards U FOUO Potential standards that loosely apply include Table 2 2-1 U Access Control Standards 2967 This Table is U Standard Description Role-Based Access Control ANSI INCITS 359-2004 Validated Common Criteria protection profiles Multinational Information Sharing Environment Protection Profile v 1 0 Describes Role Based Access Control RBAC features that have achieved acceptance in the commercial marketplace It includes a reference model and functional specifications for the RBAC features defined in the reference model For access control including Controlled Access Protection Profile Labeled Security Protection Profile Role-Based Access Control Protection Profile Contains functional and security requirements for sharing information up to Secret among multinational partners 2968 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-11 UNCLASSIFIED FOR OFFICIAL USE ONLY 2969 2970 U FOUO Potential supporting commercial technologies include Table 2 2-2 U Technologies Supporting Access Control This Table is U Standard Description Security Assertion Markup Language SAML v2 0 eXtensible Access Control Markup Language XACML v1 0 DARPA Agent Markup Language DAML Web Ontology Language OWL v2 0 Web DAV Access Control Protocol RFC3744 Content Based Information Security 2971 2972 2973 2974 2975 2976 2977 2978 2979 2980 2981 2982 2983 2984 2985 The Security Assertion Markup Language SAML is an XML-based framework for exchanging security information This security information is expressed in the form of assertions about subjects where a subject is an entity either human or computer that has an identity in some security domain W3C standards organization OASIS Extensible Access Control Markup Language XACML defines a core schema and corresponding namespace for the expression of authorization policies in XML against objects that are themselves identified in XML OASIS standard 6 Feb 2003 a working draft of v2 0 is available Provides constructs to create ontologies and metadata markup information for machine readability Provides a language that can be used to describe the classes and relations between them that are inherent in Web documents and applications WebDAV stands for Web-based Distributed Authoring and Versioning It is a set of extensions to the HTTP protocol which allows users to collaboratively edit and manage files on remote web servers IETF standards organization Joint Forces Command-sponsored advanced technology concept demonstration that supports the notion of abstracting the complexity of label development from the operator through the use of roles It also supports the notion of a hierarchy of policies to control sharing This Table is U 2 2 3 1 1 5 U Costs limitations U FOUO A large monetary cost will be incurred to design develop test and field RAdAC into the GIG enterprise since there is no similar commercial technology U FOUO A significant performance cost will be associated with access control decision-making due to the quantity of RAdAC model inputs and the amount of detail required for these inputs Current access control technologies compare a request against a user's identity--and an associated list of authorizations--and then produce a binary access decision The complexity of RAdAC will most likely increase the computation needs for each decision by an order of magnitude U FOUO There will also be significant network bandwidth cost due to the transfer of RAdAC inputs and outputs and the distribution of RAdAC heuristics although the distributed design can be optimized to reduce the bandwidth cost 2 2 3 1 1 6 U Dependencies U FOUO Implementation of the RAdAC concept relies on several technologies covered by other IA System Enablers UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-12 UNCLASSIFIED FOR OFFICIAL USE ONLY 2986 o U FOUO Access Control Policy language and associated standards 2987 o U FOUO Assured Metadata with integrity verification and reliable binding to source object o U FOUO Availability of enterprise situation environment and IT Component data with integrity verification features o U FOUO Enterprise Management information regarding domain Certification Accreditation and its associated configuration risks and threat levels o U FOUO Dynamic Policy Management to push access control policy updates to distributed RAdAC decision points 2995 o U FOUO Requester identity and associated Strength of Mechanism data 2996 o U FOUO Assured user profiles for storing user-based access control heuristics 2997 o U FOUO Discovery process interface for RAdAC to decide about service subscriptions authorization to use a service and service disclosure authorization to know about a service's existence 2988 2989 2990 2991 2992 2993 2994 2998 2999 3000 3001 3002 3003 3004 3005 3006 3007 3008 3009 3010 3011 3012 3013 3014 3015 3016 3017 2 2 3 1 1 7 U Alternatives U FOUO Attribute-based Access Control ABAC offers a more dynamic access control environment than traditional hard-coded access control models since it is based on attribute-value pairs Because of its similarity to RAdAC with respect to attributebased inputs this approach offers a significant advantage in the near term while the harder technical problems of risk determination can be matured through research and development ABAC can leverage advances in object metadata and enterprise data both in the form of attribute-value pairs and can be used as a prototype to address some aspects of operational need determination without requiring the implementation of security risk determination U FOUO In ABAC the digital access control policy would be simpler than in RAdAC since it is essentially rules about required attribute-value pairs for access to a Soft Object but it does offer dynamic update capabilities through its typical directory-based structure This approach can also be paired with the complementary Digital Rights Management technology potentially implemented as additional lists of attribute-value pairs to address object life-cycle needs In the long run this approach will not meet the GIG capabilities required to fully implement the need-to-share enterprise but it can be used as an alternative technology during early increments UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-13 UNCLASSIFIED FOR OFFICIAL USE ONLY 3018 3019 3020 3021 3022 3023 3024 3025 3026 3027 3028 3029 3030 U FOUO Content-Based Information Security uses encryption and key management techniques to control access to information objects This approach addresses security risk during the decision to present an access key to a given user based on his or her clearance formal access approvals and need-to-know The technological burden in this approach is in the key management rather than on security risk determination or dynamic policy 2 2 3 1 1 8 U Complementary techniques U FOUO Digital Rights Management an access control and usage control technology that uses a combination of metadata-based capabilities cryptographic techniques and key management The xRML proposed standard offers significant capability to express digital rights for objects as a set of well-defined attributes 2 2 3 1 1 9 U References U FOUO Role-Based Access Control ANSI INCITS 359-2004 3033 U FOUO Validated Common Criteria protection profiles for access control including Controlled Access Protection Profile Labeled Security Protection Profile Role-Based Access Control Protection Profile 3034 U FOUO Multinational Information Sharing Environment Protection Profile v 1 0 3035 U FOUO Security Assertion Markup Language SAML v2 0 W3C standards organization 3031 3032 3036 3038 U FOUO eXtensible Access Control Markup Language XACML v1 0 OASIS standard 6 Feb 2003 a working draft of v2 0 is available 3039 U FOUO DARPA Agent Mark-up Language DAML 3040 U FOUO Web Ontology Language OWL v2 0 3041 U FOUO Web DAV Access Control Protocol IETF standards organization 3042 U FOUO Content Based Information Security 3043 U FOUO XML Rights Markup Language v2 0 3044 U FOUO Attribute Based Access Control research 3037 3045 o 3047 U FOUO SPAWAR http www networkassociates com us _tier0 nailabs _media documents atn pdf 3046 o U FOUO Mitre http portal acm org citation cfm id 510781#CIT UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-14 UNCLASSIFIED FOR OFFICIAL USE ONLY 3048 3049 3050 3051 3052 3053 3054 3055 3056 3057 3058 3059 3060 3061 3062 3063 3064 3065 3066 3067 3068 3069 3070 3071 3072 3073 3074 3075 3076 3077 3078 3079 3080 3081 3082 3083 3084 3085 2 2 3 2 U Assured Metadata U FOUO GIG Policy-Based Access Control as implemented via RAdAC capabilities relies on certain information conveyed as inputs to its control decision in a consistent and known format A portion of this control decision input is based on the attributes of the information objects or services that are being requested These object attributes including IA related information are relayed by Metadata To ensure integrity of objects and metadata linkage this metadata is cryptographically bound to the source information or service object Metadata also serves a related function by providing filterable information supporting discovery and advertisement of data or service object availability for access by qualified GIG users U FOUO Specific metadata content and labeling for GIG information and service object is dependant on the object's type For example a server-stored information file object may have a far different set of metadata attributes than a real-time session object GIG metadata standards will specify and define these required IA attributes per object type relationships by U FOUO The IA related technologies and capability investments that will be required to enable the GIG vision of Policy-Based Access Control in the metadata area include GIG wide language standardization for IA attributes trusted metadata creation tools cryptographic binding of metadata to its source object as well as the ability to reflect and convey metadata for GIG services 2 2 3 2 1 U Metadata Language and Standards U FOUO Supporting the transition from a GIG need-to-know to a need-to-share information exchange paradigm will require reliable and trusted mechanisms to characterize the IA aspects of information or service objects requested by GIG entities To provide a reliable supporting mechanism to the GIG Access Control Decision Point process metadata language usage must be standardized regarding syntax semantics and ontology of IA related information This standardization provides both the owner creating organization and access policy authors with the ability to unambiguously and consistently communicate attributes regarding data about the information or service object as well as define the attributes of the entities that will support access control decisions for the object instance This metadata also supports the user information discovery process by providing filterable information content about GIG publicly available objects to authorized users--via GIG search applications 2 2 3 2 1 1 U Technical details U FOUO GIG Data owners must have the ability to provide granular expression of the value of their information through new fields in the metadata tags These fields will point to information access policies that define the users roles or COIs authorized to access a specific data asset UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-15 UNCLASSIFIED FOR OFFICIAL USE ONLY 3086 3087 3088 3089 3090 3091 3092 3093 3094 3095 3096 3097 3098 3099 3100 3101 3102 3103 3104 3105 3106 3107 3108 3109 3110 3111 3112 3113 3114 3115 3116 3117 3118 3119 U FOUO The IA Component of the GIG will also implement a notion of Quality of Protection QoP for data assets As part of tagging a data asset a set of security-related properties necessary for protecting the asset would be associated with the asset Properties can include how to protect the object as it travels across the network how the data object can be routed or how the data object must be protected while at rest U FOUO The purpose of QoP metadata elements differs from the metadata elements used to describe the contents of an asset Content-description metadata elements are designed to enable data discovery and sharing QoP metadata tags define how the data object is to be protected while at rest and in transit This concept for instance will allow the GIG to require routing of highly classified or sensitive information through a more trusted i e better protected portion of the GIG or require that a user's client support encryption of the information in storage before granting access to the information Clearly one of the technical issues surrounding these metadata QoP designations are the mechanisms of transformation--especially for transport from metadata to routing request selection information U FOUO Another important aspect when considering metadata usage within the GIG is to consider the types classes of objects being requested for access and the potential action context of these object classes Objects in this context are any information service session application streaming media metadata or other resource to which access will be controlled in the GIG Objects are described as being active or passive with respect to the access control decision process An object is considered active if it is the cause of the access control decision i e an active object is one that is requesting access to some other object entity An object is considered passive if it is the entity that will be shared as a result of the access control decision i e a passive object is the one that is being requested by some other object entity There are many classes of objects that will exist in the GIG and be involved in access control decisions Some possible classes include o U FOUO Information objects include any data file report document photograph database element or similar types of data object It might also include metadata that describes other objects Information objects are arguably the core objects as they typically are what is being shared They represent all the information that will be resident in the GIG or made available to the GIG from information originators creators e g Intelligence Community They are usually passive that which is being acted upon and thus their IA attributes often define the minimal requirements for access to the object UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-16 UNCLASSIFIED FOR OFFICIAL USE ONLY 3120 o U FOUO Service objects are executable applications that provide some function for the GIG They are the services in a service-oriented architecture Service objects can be both active and passive objects of an access control decision Services will provide portals to useful information and computational resources on the GIG People will need to be granted access to services to use them and thus services can also be the passive object of an access control decision In addition services can be expected to make independent requests of other services and information objects or may make requests on behalf of people When making requests on behalf of a person services might be expected to provide their own IA attributes to the access control decision process along with those of the person When independently accessing other services e g service to service interactions service objects are active objects in the access control decision process o U FOUO Session objects are objects that are created as a result of a real-time collaboration between two or more people A telephone call a video teleconference or an online virtual meeting are examples of collaborative sessions that produce session objects Session objects are in essence a representation of the collaborative session They have attributes that describe key characteristics of the session Session objects will generally be passive objects in an access control decision and thus the IA attributes of the session will be used to grant or deny access to the session There may be cases where a session object is also an active object as it might request content be added to the session such as a data file e g PowerPoint presentation o U FOUO Real-time objects are a special class of information objects Examples of real-time objects are live streaming video and voice as well as real-time network management control traffic exchanges What makes real-time objects special is the temporal aspect of the objects saving samples to disk turns realtime objects into normal information objects i e these real-time objects are not retained to persistent storage media Attributes that describe real-time objects must be assigned a priori and thus must be generalized to what the real-time object is expected to be For IA attributes this means that the security relevant features of the streaming information must be anticipated Once IA attributes are established they will live through the duration of the real-time object 3121 3122 3123 3124 3125 3126 3127 3128 3129 3130 3131 3132 3133 3134 3135 3136 3137 3138 3139 3140 3141 3142 3143 3144 3145 3146 3147 3148 3149 3150 3151 3152 3153 3154 3155 3156 3157 3158 3159 U FOUO Metadata IA attributes are the foundation of making access control decisions in the GIG There needs to be a universal agreed-upon set of IA attributes across the GIG These attributes in effect provide a vocabulary for describing security actions Without a common vocabulary it is quite difficult if not impossible to make meaningful decisions about sharing information Table 2 2-3 shows the minimum set of IA attributes needed to support policy based access control decision-making via the RAdAC information-sharing model based on the class of the object UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-17 UNCLASSIFIED FOR OFFICIAL USE ONLY 3160 Table 2 2-3 U Minimum Set of IA Attributes for Access Control Decisions This Table is U Category Passive object Passive object Passive object Passive object Passive object Passive object Passive object Passive object Passive object Passive object Passive object Passive object Passive object Passive object Passive object Passive object Session object Session object Session object IA Attribute Description Requirement Identifier Provide the GIG unique designation for the object Sensitivity Level Provide a standards-based designation of object classification and perishability timeframe include Operational Need Modifier structure Data Owner Community of Interest GIG standards-based COI designator for the organization activity responsible for creation of the object Access Control Information List Policy Direct Data or Pointer GIG Standards-based Pairing of entities that are allowed access to an object COI individual individual w Role Privilege or groups and the operations the entity is allowed to perform read write execute etc on the requested object include Operational Need Modifier structure Time to Live Length of time an object can be used before it is destroyed automatically by the system as part of an automated life cycle management capability Originator GIG unique and authenticated identifier linked to the person organization or entity that created the object Releaseability Standards-based designator of countries or GIG external organizations with whom the object may be shared include Operational Need Modifier structure Sanitization Supported Identifies if real-time sanitization of the object is supported Security Policy Index GIG standards-based policy language specifies the various procedures for the object with flexibility structure to include access protection policy entity authentication platform environment and operational factor scoring and QoP include Operational Need Modifier structure QoP object life cycle attributes view only printable no-forward destroy after view digital rights etc include Operational Need Modifier structure Location GIG Standards-based designation of virtual path to the object's storage location Timestamp Time date information when the object was created or copied Integrity mechanism Insure that unauthorized changes to the information object and its IA attributes can be detected Cryptobinding Cryptographic binding and metadata supporting access control decision making to the source object Supports prevention of direct access to object w o metadata based access control decision processing Split or IA capable filtering of Metadata Support for both discovery and access control processes Classification releasability of descriptive metadata itself not the source object Member IA Attributes GIG Standards-based listing pointers of mandatory privilege identity IA attribute and value pairings Access Control List List of GIG unique identifier for people allowed to join session paired with GIG unique identifier for approval authority Security Level GIG standards-based parameter indicating how the security level of the session is to be controlled fixed float UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-18 UNCLASSIFIED FOR OFFICIAL USE ONLY This Table is U Category Session object Session object Session object Session object Service object IA Attribute Description Requirement Session Archive Control GIG standards-based parameters indicating archive recording and classification marking required Owner Moderator ID GIG unique identifier of session owner moderator Session Members GIG unique identifier of current past session members Session Identifier Standards-based unique identifier for the session For Access Requests coming from a service object acting as proxy for the source entity this structure must address GIG unique ID of service object as well as GIG unique ID of requesting source EDITOR'S NOTE REMAINING SPECIFIC IA ATTRIBUTES FOR SERVICE OBJECT TYPES ARE CURRENTLY UNDER INVESTIGATION Real-time object EDITOR'S NOTE SPECIFIC IA ATTRIBUTES FOR REAL-TIME OBJECT TYPES ARE CURRENTLY UNDER INVESTIGATION This Table is U 3161 3162 3163 3164 3165 3166 3167 3168 3169 3170 3171 3172 3173 3174 3175 3176 3177 3178 3179 3180 U FOUO The RAdAC model describes an approach to access control whereby operational necessity can override security risk In this context IA attributes might have 'modifiers' in addition to values Specifically each designated IA Attribute might have a modifier that describes which if any exceptions overrides to normal policy might be permitted relative to that attribute Thus when an access control process is making a decision whether to permit or deny access and encounters a mismatch on a particular IA Attribute it may use the modifiers in an effort to reach a decision that supports sharing 2 2 3 2 1 2 U Usage considerations U FOUO The successful usage of a standardized metadata language supporting access control decisions will require a clearly defined and consistently implemented set of IA Attributes and supporting infrastructure tools capabilities This set of IA related attributes labels their syntax semantics and taxonomy form a critical link in the GIG automated access control and discovery processes The usage and meaning of these IA Attributes must be understood and or supported via user assisting infrastructure especially for the roles of information owner access control policy author and access privilege operation override authority Incorrect usage of these IA Attributes labels could result inability to discover or access information by GIG users with the correct operation need and clearance On the other side of the scale incorrect IA Attribute usage could result in unintended or unauthorized disclosure of information to a compromised GIG user or service entity UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-19 UNCLASSIFIED FOR OFFICIAL USE ONLY 3181 3182 3183 3184 3185 3186 3187 3188 3189 3190 3191 U FOUO Currently there are two known standards bodies working within the GIG to define metadata language principles for use by their communities The primary purpose of each group's products are different and neither standard provides the entire IA Attribute suite needed to support the Policy-Based Access Control Enabler as envisioned in the RAdAC model See Table 2 2-3 for detailed analysis However the Core Enterprise Services CES Metadata Working Group now led by DISA is attempting to ensure commonality between itself and the IC Metadata Working Group see attribute comparison Table 2 2-4 Further discussions have been initiated with both standards groups to investigate and integrate the required IA Attribute and supporting language semantics syntax into these implementation documents and infrastructures Table 2 2-4 U IC and CES Metadata Working Groups Attribute Comparison This Table is U Core Layer Category Set DDMS Attributes IC MSP Attributes The Security elements enable the description of security classification and related fields Resource elements enable the descriptors of maintenance and administration information Security Classification Dissemination Controls Releasable To Title Identifier Creator Publisher Contributor Date Rights Language Type Source Subject Geospatial Coverage Temporal Coverage Virtual Coverage Description Format Security Classification Dissemination Controls Releasable To Title Identifier List AuthorInfo Publisher Co-authorInfo Date Rights Language IntelType Source Subject Geospatial Temporal Virtual Description Media Format The Summary Content elements enable the description of concepts and topics The Format elements enable the description of physical attributes to the asset This Table is U UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-20 UNCLASSIFIED FOR OFFICIAL USE ONLY 3192 3193 3194 3195 3196 3197 3198 3199 3200 3201 3202 3203 3204 3205 3206 3207 3208 3209 3210 3211 3212 3213 3214 3215 3216 3217 U FOUO The IC Metadata Working Group has developed an XML-based standard and schema that supports containers for security marking as prescribed by the CAPCO standard IC MSP is an implementation of the World Wide Web Consortium's W3C specification of the Extensible Markup Language XML It consists of a set of XML attributes that may be used to associate security-related metadata with XML elements in documents web service transactions or data streams It is distributed as both an XML entity set and a W3C XML Schema WXS so that the XML attributes defined in the standard can be incorporated into any XML document type definition DTD or schema The IC ISM entity set and WXS are controlled vocabularies of terms that are used as the sources for the values of the IC ISM attributes The IC MSP schemas incorporate the classification and controls attributes defined by the IC Metadata Standard for Information Security Markings IC ISM The IC ISM provides the IC with a standard method for tagging CAPCO authorized markings and abbreviations on XML-based information The standard provides flexibility for each agency to implement their security policy and granularity with respect to security marking U FOUO The DoD's Discovery Metadata Specification DDMS and supporting XML schema produced by the Core Enterprise Services CES Metadata Working Group defines discovery metadata elements for resources posted to community and organizational shared spaces Discovery is the ability to locate data assets through a consistent and flexible search The DDMS specifies a set of information fields that are to be used to describe any data or service asset that is made known to the enterprise This CES document serves as a reference guide by laying a foundation for Discovery Services The document describes the DDMS elements and their logical groupings It does not provide an interchange specification or substantive implementation guidance However there is a roadmap for the development of implementation guides in line with this and higher-level GIG directive documents see Figure 2 2-2 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-21 UNCLASSIFIED FOR OFFICIAL USE ONLY Codifying the Net-Centric Data Strategy Guidance Memos Directives Plans and Standards XML Registration 9 Outlined data approach9 for moving to Net-Centric Data Management Congressional Report Environment 15 Mar '03 Single Clearinghouse 22 Apr '02 MID 905 Clarification Implementation Guidance 9 9 MID 905 requirement to register XML metadata by 9 30 03 3 Apr '03 DoD Net-Centric Data Directive DoD Net-Centric Data Implementation Guides July '04 Details on how to 2004 GES CES Implementation Memo 9 Plan for transitioning to CES Nov '03 Net-Centric Data Strategy 9 Net-Centric vision goals and approaches for data 9 May '03 Visibility--Advertising Data Assets with Discovery Metadata Oct '03 9 Dates in italics represent release for formal coordination How to Advertise Data DoD Discovery Metadata Specification DDMS Version 1 0 Sept '03 How to Make Data Accessible 9 How to Register Metadata GIG Enterprise Services Transition Plans from Components for 9denotes completed FY 06 Program Reviews UNCLASSIFIED This figure is U 16 3218 3219 3220 3221 3222 3223 3224 3225 3226 3227 3228 3229 3230 3231 3232 3233 3234 Figure 2 2-2 U Codifying the Net-Centric Data Strategy 2 2 3 2 1 2 1 U Implementation Issues U FOUO Some IA metadata attributes sets for information objects may change over time and due to the impact scale The IA metadata standards language and supporting infrastructure must support the ability to point index to a trusted secondary source for current version attribute information For instance if a departmental access policy were hard coded into metadata for all of that department's products potentially large numbers of information objects must be modified to new hard-coded values if a change policy change occurs over time in this area U FOUO The metadata language standard must include fields IA Attributes within the metadata tag that allow access control decisions to be made on the metadata itself For example in some instances security code words or compartment names are classified themselves U FOUO It is also paramount given the critical nature of the metadata tags that appropriate integrity data origination and in some cases traffic flow security measures are applied and that the metadata label be securely bound to the object UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-22 UNCLASSIFIED FOR OFFICIAL USE ONLY 3235 3236 3237 3238 3239 3240 3241 3242 3243 3244 3245 3246 3247 3248 3249 U FOUO The use of IA attribute modifiers as described above will add significant complexity to the IA metadata standards definition U FOUO IA metadata attributes will be needed to support both GIG Access Control and Discovery processes If implementation decisions drive segregation of IA Attributes to differing location virtual or physical synchronization of new or changed IA attributes must be addressed U FOUO Ontology of metadata referring to input factors for RAdAC computation is extremely important so that computation logic correctly assesses the risk and the operational need e g is this a Navy Captain endorsing operational need or an Air Force Captain U FOUO It is unclear what implementation method can support the transport-related Quality of Protection QoP IA metadata attributes into the transport infrastructure to support routing decisions For the data at rest portion of IA QoP attributes commercialbased Digital Right Management capability may provide acceptable and compatible methods give further investigation 3253 2 2 3 2 1 2 2 U Advantages U FOUO Supports GIG need-to-share vision though discovery process and movement away from determine at the time of creation access control lists Creator of information may not know who has need of information produced 3254 U FOUO Supports finer granularity in access control decision making logic 3255 U FOUO Support policy based vs hard coded access control decision making that enables rapid changes in GIG situational and environmental factors as well as operational need 3250 3251 3252 3256 3257 3260 2 2 3 2 1 2 3 U Risks Threats Attacks U FOUO Attempts to access information object directly on server location by passing metadata RAdAC Access Control processes 3261 U FOUO Confidentiality of some portions of metadata itself 3262 U FOUO Discovery DOS attacks 3263 U FOUO Access DOS attacks 3264 U FOUO Metadata tags that include compromised identity of the original source of the information and of any entities e g processes that have modified it prior to posting in its current form 3258 3259 3265 3266 3267 3268 U FOUO Compromised metadata is presented to discovery users e g metadata is maliciously hidden out of date metadata is maliciously presented UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-23 UNCLASSIFIED FOR OFFICIAL USE ONLY 3277 2 2 3 2 1 3 U Maturity U FOUO As described above the two GIG standards organizations CES Metadata Working Group and IC Metadata Working Group are in the process of defining metadata standards and implementation schemas These standards are being designed for implementation using mature and tested commercial standards for internet communication including XML and OWL Further GIG usage of XML to support metadata is being configuration managed and standardized via the DOD Metadata Registry and Clearing house http diides ncr disa mil mdregHomePage mdregHome portal Therefore technical readiness level has been assessed in the Early range 2-3 3278 2 2 3 2 1 4 U Standards 3269 3270 3271 3272 3273 3274 3275 3276 Table 2 2-5 U Metadata Standards 3279 This Table is U Standard Department of Defense Discovery Metadata Specification DDMS Version 1 1 Intelligence Community Metadata Standards for Information Assurance Information Security Markings Implementation Guide Release 2 0 Intelligence Community Metadata Standard for Publications Implementation Guide Release 2 0 Federal Information Processing Standard FIPS PUB 10-4 April 1995 Countries Dependencies Areas of Special Sovereignty and Their Principal Administrative Divisions Extensible Markup Language XML 1 0 Second Edition W3C Recommendation 6 October 2000 Web Ontology Language OWL Guide Version 1 0 W3C Working Draft 4 November 2002 Description Defines discovery metadata elements for resources posted to community and organizational shared spaces Discovery is the ability to locate data assets through a consistent and flexible search An implementation of the World Wide Web Consortium's specification of the Extensible Markup Language XML It consists of a set of XML attributes that may be used to associate securityrelated metadata with XML elements in documents webservice transactions or data streams A set of XML document models that may be used to apply metadata to analytical data to produce publications IC MSP prescribes element models and associated attributes for use in marking up document-style products for posting on Intelink and other domain servers Provides a list of the basic geopolitical entities in the world together with the principal administrative divisions that comprise each entity Describes a class of data objects called XML documents and partially describes the behavior of computer programs which process them Provides a language that can be used to describe the classes and relations between them that are inherent in Web documents and applications This Table is U UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-24 UNCLASSIFIED FOR OFFICIAL USE ONLY 3280 3281 3282 3283 3284 3285 3286 3287 3288 3289 3290 3291 3292 3293 3294 2 2 3 2 1 5 U Costs limitations U FOUO More resources and time will be required to develop produce and maintain these IA related metadata attributes than today's basic security markings and MAC DAC characteristics This cost can be off set to some degree by the use of automated metadata creation tools U FOUO Legacy DoD information and service objects that currently exist or will be produced before metadata standards and infrastructure are available may need to be retrofitted with standard IA Attributes to support RAdAC access control and Discovery process U FOUO The use of trusted metadata type information tagging for real-time and session object types will increase the GIG's transport and network traffic overhead Performance impacts should also be investigated early in the design process U FOUO To avoid the need to retrofit metadata for very large quantities of information objects IA metadata attributes syntax and semantics must remain stable or remain backwards compatible 3296 2 2 3 2 1 6 U Dependencies U FOUO Access Control Policy Language Standards 3297 U FOUO Metadata Creation Tools 3298 U FOUO Identity and Privilege Management Capacities 3299 2 2 3 2 1 7 U Alternatives U FOUO Depending on the final fidelity functionality and transition sequence of RAdAC functionality-less IA Attribute could be included in the metadata language and standards However later additions could result in metadata large-scale retrofit impacts 3295 3300 3301 3302 3303 3304 3305 3306 3307 3308 3309 3310 3311 2 2 3 2 1 8 U Complementary techniques U FOUO Digital Rights Management 2 2 3 2 1 9 U References U FOUO Department of Defense Discovery Metadata Specification DDMS Version 1 1 U FOUO Intelligence Community Metadata Standards for Information Assurance Information Security Markings Implementation Guide Release 2 0 U FOUO Intelligence Community Metadata Standard for Publications Implementation Guide Release 2 0 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-25 UNCLASSIFIED FOR OFFICIAL USE ONLY 3312 3313 3314 U FOUO Federal Information Processing Standard FIPS PUB 10-4 April 1995 Countries Dependencies Areas of Special Sovereignty and Their Principal Administrative Divisions UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-26 UNCLASSIFIED FOR OFFICIAL USE ONLY 3315 2 2 3 2 1 10 U Technology Standards Analysis Table 2 2-6 U Metadata Gap Analysis 3316 This Table is U Category Passive object MD Creator Entry Passive object MD Creator Entry IA Attribute Description Requirement Identifier Provide GIG unique designation for the object Sensitivity Level Provide a standards based designation of object classification and perishability timeframe include Operational Need Modifier structure Req Source Tiger Team Report 5 26 2004 Tiger Team Report 5 26 2004 Existing Standards Coverage Y N Identifier Y IC MSP Gap Description Recommendation Y DDMS Y IC MSP Recommend DDMS implement by reference the IC ISM markings Y IC ISM Y DDMS Recommendations and or Remarks IC MSP requires a Universal Unique ID Identifier List and a Public Document No IC ISM allows all CAPCO classification markings and dissemination constraints including declassification instructions IC MSP employs IC ISM markings on all block object element types and in the descriptive metadata for the source data DDMS only implements DoD 5200 1-R and does not currently express foreign SCI or nonstandard classification or declassification UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-27 UNCLASSIFIED FOR OFFICIAL USE ONLY This Table is U Category Passive object MD Creator Entry Passive object MD Creator Entry Passive object MD Creator Entry IA Attribute Description Requirement Data Owner Community of Interest GIG standards based COI designator for the organization activity responsible for creation of the object Access Control Information List Policy Direct Data or Pointer GIG Standards-based Pairing of entities that are allowed access to an object COI individual individual w Role Privilege or groups and the operations the entity is allowed to perform read write execute etc on the requested object include Operational Need Modifier structure Time to Live Length of time an object can be used before it is destroyed automatically by the system as part of an automated life cycle management capability Req Source Tiger Team Report 5 26 2004 Existing Standards Coverage Y N Identifier N IC MSP N DDMS Gap Description Recommendation Recommendations and or Remarks IC MSP Make Affiliation a required field and ensure it aligns to GIG COI designator IC MSP allows specification of 1 POC's information in PersonalProfileGroup but Affiliation is optional and COI is missing IC MSP and DDMS Make UserID a required field and ensure it maps to globally unique GIG UserID Tiger Team Report 5 26 2004 N Tiger Team Report 5 26 2004 Y IC MSP DDMS Make Organization a required field See comments questions Y DDMS UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-28 For Access Requests coming from a service object acting as proxy for the source entity this structure must address GIG unique ID of service object as well as GIG unique ID of requesting source Supports information cutoff and information death dates in the DateList element IC MSP and Date element DDMS UNCLASSIFIED FOR OFFICIAL USE ONLY This Table is U Category Passive object MD Creator Entry IA Attribute Description Requirement Req Source Originator GIG unique and authenticated identifier linked to the person organization or entity that created the object Tiger Team Report 5 26 2004 Existing Standards Coverage Y N Identifier N IC MSP N DDMS Gap Description Recommendation Recommendations and or Remarks IC MSP Make Affiliation a required field and ensure it aligns to GIG COI designator IC MSP allows specification of 1 POC's information in PersonalProfileGroup but Affiliation is optional and COI is missing IC MSP and DDMS Make UserID a required field and ensure it maps to globally unique GIG UserID DDMS Make Organization a required field Passive object MD Creator Entry Passive object MD Creator Entry Releaseability Standards-based designator of countries or GIG external organizations with whom the object may be shared include Operational Need Modifier structure Tiger Team Report 5 26 2004 Sanitization Supported Identifies if real-time sanitization of the object is supported Tiger Team Report 5 26 2004 Y IC MSP Support CAPCO and DoD 5200 1-R compliant releasability markings Y IC ISM Y DDMS N IC MSP N DDMS Add optional element containing URI to metadata for alternate source or acceptable sanitization service The URI to alternate metadata should contain a security classification UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-29 UNCLASSIFIED FOR OFFICIAL USE ONLY This Table is U Category Passive object MD Creator Entry View Passive object MD Creator Entry View Passive object MD Creator Entry View Passive object MD Creator View IA Attribute Description Requirement Req Source Existing Standards Coverage Y N Identifier N IC MSP Security Policy Index GIG standards based policy language specifies the various procedures for the object w flexibility structure to include access protection policy entity authentication platform environment and operational factor scoring include Operational Need Modifier structure Object lifecycle attributes view only printable no-forward destroy after view etc include Operational Need Modifier structure Tiger Team Report 5 26 2004 Tiger Team Report 5 26 2004 N IC MSP Location GIG Standards-based designation of virtual path to the object's storage location Tiger Team Report 5 26 2004 Tiger Team Report 5 26 2004 N IC MSP Timestamp Time date information when the object was created or copied N DDMS N DDMS Gap Description Recommendation Recommendations and or Remarks Add mandatory element that indexes the organization security policy that governs access to the information Index can take the form of a URI or a UUID Intent is that though the policy may change over time this reference to it won't need to Need to add Digital Rights Management or equivalent attribute fidelity capability to specify read modify forward copy destroy print types of constraints There's a primitive structure in place for rights management in the Rights element but it only supports copyright and Privacy Act flags Add SourceURI field to AdministrativeMetadata element N DDMS Y IC MSP Y DDMS IC MSP DateList element contains DatePosted DatePublished DateReviewed DateRevised fields DDMS Date element contains DateCreated UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-30 UNCLASSIFIED FOR OFFICIAL USE ONLY This Table is U Category IA Attribute Description Requirement Req Source Passive object MD Creator No Entry View Integrity mechanism Insure that unauthorized changes to the information object and its IA attributes can be detected Tiger Team Report 5 26 2004 Passive object Infrastructure Cryptobinding Cryptographic binding and metadata supporting access control decision making to the source object Supports prevention of direct access to object w o metadata based access control decision processing Split or IA capable filtering of Metadata Support for both discovery and access control processes GIG IA Arch Docs N IC MSP GIG IA Arch Docs Y IC MSP Passive object Infrastructure Existing Standards Coverage Y N Identifier N IC MSP N DDMS N DDMS Gap Description Recommendation Recommendations and or Remarks Append an Integrity element with MetadataIntegrity field and SourceIntegrity field that include name type URI of integrity mechanism used Add a Security element with crypto algorithm designator URI and a portion of the key needed to access the source IC MSP splits Administrative Metadata from Descriptive Metadata Y DDMS DDMS is designed to enable discovery and access control filtering on a single metacard Passive object Infrastructure Session object Owner Entry View Classification releasability of descriptive metadata itself not the source object GIG IA Arch Docs Member IA Attributes GIG Standards based listing pointers of mandatory privilege identity IA attribute and value pairings Tiger Team Report 5 26 2004 N IC MSP N DDMS N IC MSP N DDMS Descriptive Metadata only describes the security classification of the source object Need to add Element structure that specifies the common qualities of People who can participate in the session UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-31 UNCLASSIFIED FOR OFFICIAL USE ONLY This Table is U Category IA Attribute Description Requirement Req Source Access Control List List of GIG unique identifier for people allowed to join session paired with GIG unique identifier for approval authority Security Level GIG standards based parameter indicating how the security level of the session is to be controlled fixed float Session Archive Control GIG standards-based parameters indicating archive recording and classification marking required Owner Moderator ID GIG unique identifier of owner moderator of the session Tiger Team Report 5 26 2004 Session object Owner View Session Members GIG unique identifier of current past session members Session object Owner View Session Identifier Standards based unique identifier for the session Tiger Y IC MSP Team Y DDMS Report 5 26 2004 Tiger Y IC MSP Team Y DDMS Report 5 26 2004 This Table is U Session object Owner Entry View Session object Owner Entry View Session object Owner Entry View Session object Owner Entry View Tiger Team Report 5 26 2004 Tiger Team Report 5 26 2004 Tiger Team Report 5 26 2004 Existing Standards Coverage Y N Identifier N IC MSP Gap Description Recommendation Recommendations and or Remarks N DDMS N IC MSP N DDMS N IC MSP Add an binary Fixed field in the Security element of session DescriptiveMetadata Need to add archive recording fields Y N and URI for archive recording Covers classification markings only Can be adapted using Elements from the PersonalProfileGroup Assumption This person is responsible for granting access to the session and is responsible for allowing information objects to be shared in the session UUID should suffice for this purpose N DDMS N IC MSP N DDMS UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-32 UUID should suffice for this purpose UNCLASSIFIED FOR OFFICIAL USE ONLY 3317 3318 3319 3320 3321 3322 3323 3324 3325 3326 3327 3328 3329 3330 3331 3332 3333 3334 3335 3336 3337 3338 2 2 3 2 2 U Trusted Metadata Creation Tools U FOUO The IA metadata attributes are a key element of access control decisions that are at the heart of assured information sharing Given the pivotal role of these attributes the policies and supporting creation tools infrastructure used to generate them can be leveraged to help encourage--or even enforce--the appropriate level of data sharing across the enterprise U FOUO It is envisioned that automated process tools can be developed to support the business processes of the GIG community and can translate these business processes into sharing policies that assist in the application of IA metadata attributes for both sharing and required information security While such a robust translation capability is beyond the ability of current technologies the general notion of turning business processes and natural language statements about organization's processes into a machine-readable metadata supporting policy tools and infrastructure is supported by current technology--the issue is one of robustness and sophistication If such a robust capability can be created it will allow automated processes to facilitate appropriate levels of sharing and security by assisting in the creation of the object metadata IA Attributes U FOUO It should be noted that IA Attributes will form only a portion of the overall metadata for GIG information objects However due to the critical nature of these elements a significant amount of complexity and added processing interfaces will be needed to support this metadata subset 2 2 3 2 2 1 U Technical details U FOUO The following listing provides a brief inventory of capabilities and interfaces that will be required of trusted metadata creation tools and IA attributes for the GIG o U FOUO Identity and Privilege management interface Ensure that the entity user process is authenticated and has the correct privilege to create validate this metadata for the data owning organization 3342 o U FOUO Object Identifier CM interface Assign GIG unique object identifier 3343 o U FOUO Access Control Policy Interface Allow user to link the correct access control policy or access control list based on information owner organization's business rules as well as directive pointers to related transport QoP and life cycle QoP policy o U FOUO Operational Need Entry supporting structure IA attributes 'modifiers' in addition to values IA attributes might have a modifier that describes which if any exceptions to normal policy might be permitted relative to that attribute o U FOUO Metadata Integrity Mechanism Interface Ensure unauthorized changes to metadata are detected o U FOUO Discovery metadata filtering structure policy allows portions of metadata to be filtered from search results unless the user possess required clearance level 3339 3340 3341 3344 3345 3346 3347 3348 3349 3350 3351 3352 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-33 UNCLASSIFIED FOR OFFICIAL USE ONLY 3353 o U FOUO Cryptographic Binding Interface Supports trusted binding of the metadata to the source information object when metadata has been successfully created syntax check complete o U FOUO Trusted transport interface required for assure pull and push of information related to metadata creation process 3354 3355 3356 3357 3358 3359 U FOUO The following listing provides an inventory of capabilities may be common to the overall metadata creation process non IA attribute unique 3360 o U FOUO Context Sensitive User Help Capabilities 3361 o U FOUO Syntax Checker Capability Note This may be present for standard metadata requirements the unique IA attribute will likely add significant code size and interface complexity 3362 3363 3364 3365 3366 3367 3368 3369 3370 3371 3372 3373 3374 3375 3376 3377 3378 3379 3380 3381 3382 3383 3384 3385 3386 2 2 3 2 2 2 U Usage considerations U FOUO With the advent of XML-based metadata that supports web document publishing and search application creation tools and templates have been developed to assist users and document owners with the generation maintenance of supporting metadata From the prospective of commercial standards most of these supporting tools are based on the Dublin Core Initiative U FOUO The Dublin Core Metadata Initiative is an open forum engaged in the development of interoperable online metadata standards to support a broad range of purposes and business models The Dublin Core supports standard schemas in both XML and RDFS Customized metadata creation and maintenance tools--based on the Dublin Core schema--are then developed that reflect the required metadata purpose and business model policies These metadata creation maintenance tools are designed and implemented either by the information owning organization or through customization of commercially available products U FOUO However the IA metadata attributes will require additional capability to ensure trust security and unique GIG environment requirement are met for both discovery and access control processes These IA-related characteristics of metadata support generation tools were defined in section 2 2 3 2 2 1 2 2 3 2 2 2 1 U Implementation Issues U FOUO Metadata creation tools may have to support GIG minimum standards related to both discovery and access control as well as providing the user with information related to specific organizational policy As discussed above the criticality of the IA Attributes form an access control prospective and will probably make these tools complex Finally these tools must be widely distributed available to a user in a timely manner be intuitive to a human in their use and support greater levels of automation during final program timeframes UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-34 UNCLASSIFIED FOR OFFICIAL USE ONLY 3387 3388 3389 3390 3391 3392 3393 2 2 3 2 2 2 2 U Advantages U FOUO Metadata creation tools and supporting infrastructure provide the user or organization entity responsible for creation of data improvements with accuracy and aid with population of the correct metadata information especially IA Attribute vs manual template only methods 2 2 3 2 2 2 3 U Risks Threats Attacks U FOUO Unauthorized user checks in malicious file metadata to info storage 3395 U FOUO Unauthorized user attempt to change IA attribute of metadata to gain information object access 3396 U FOUO Authorized user changes metadata 3397 U FOUO Metadata creation tool DOS Attack 3398 U FOUO Compromised metadata creation tool source software 3399 3407 2 2 3 2 2 3 U Maturity U FOUO Clearly there have been successful implementations and commercial products that provide metadata creation tools based on the Dublin Core metadata standard As such the overall technology would receive a TRL score of 7-8 However the IA related capabilities and interfaces as defined in section 2 2 3 2 2 1 are new complex and unique to this GIG implementation Further one of the key required predecessors needed is a stable metadata standard for IA Attributes As discussed in the Metadata Language and Standards section this activity is in the early stages of technology development Therefore we assess the overall TRL score for this technology in the Early range 1-2 3408 2 2 3 2 2 4 U Standards 3394 3400 3401 3402 3403 3404 3405 3406 Table 2 2-7 U Metadata Tool Standards 3409 This Table is U Standard Description Department of Defense Discovery Metadata Specification DDMS Version 1 1 Intelligence Community Metadata Standards for Information Assurance Information Security Markings Implementation Guide Release 2 0 Intelligence Community Metadata Standard for Publications Implementation Guide Release 2 0 Dublin Core Metadata For Resource Discovery RFC 2413 IETF Defines discovery metadata elements for resources posted to community and organizational shared spaces Discovery is the ability to locate data assets through a consistent and flexible search An implementation of the World Wide Web Consortium's specification of theExtensible Markup Language XML It consists of a set of XML attributes that may be used to associate security-related metadata with XML elements in documents webservice transactions or data streams A set of XML document models that may be used to apply metadata to analytical data to produce publications IC MSP prescribes element models and associated attributes for use in marking up document-style products for posting on Intelink and other domain servers Defines interoperable metadata standards and specialized metadata vocabularies for describing resources that enable more intelligent UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-35 UNCLASSIFIED FOR OFFICIAL USE ONLY This Table is U Standard Description information discovery systems This Table is U 3410 2 2 3 2 2 5 U Costs limitations 3411 2 2 3 2 2 6 U Dependencies o U Access Control Policy Service 3412 3413 o U GIG Information Object Identity Assignment Service 3414 o U Identity and Privilege Service 3415 o U Cryptographic Binding Service 3416 3417 3418 3419 3420 3421 3422 3423 2 2 3 2 2 7 U Alternatives U FOUO Manual template-based metadata entry forms with limited syntax checking and external interfaces may be sufficient for the early stages of Dynamic Access RAdAC based Control 2 2 3 2 2 8 U References U FOUO Department of Defense Discovery Metadata Specification DDMS Version 1 1 U FOUO Intelligence Community Metadata Standards for Information Assurance Information Security Markings Implementation Guide Release 2 0 3425 U FOUO Intelligence Community Metadata Standard for Publications Implementation Guide Release 2 0 3426 U Dublin Core Metadata For Resource Discovery RFC 2413 IETF 3427 2 2 3 2 3 U Crypto-Binding of Metadata to Source Information Object U FOUO Cryptographically binding the metadata describing an information object to its source object provides a critical access control integrity mechanism Crypto-binding ensures at the time of creation or authorized modification that a trusted linkage is established between the two components of an information object source info and metadata This capability becomes important to GIG's implementation of Policy Based Access Control via RAdAC because metadata is one of the primary determining information inputs for access control decisions Without crypto-binding the metadata could be altered or maliciously pointed to an invalid metadata tag in order to gain unauthorized access to a source information element 3424 3428 3429 3430 3431 3432 3433 3434 3435 3436 3437 3438 2 2 3 2 3 1 U Technical details U FOUO The following list provides a brief inventory of capabilities and interfaces that will be required of crypto-binding of metadata to its source information object for the GIG UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-36 UNCLASSIFIED FOR OFFICIAL USE ONLY 3439 o U FOUO Interface capability to GIG metadata creation tools services 3440 o U FOUO Interfaces to accept and process key and or digital signature information as required o U FOUO Provide up to type 1 assurance of binding and digest functions for metadata and its source information object o U FOUO Ability support for rapid decryption of digest hash file and return original component files upon receipt of properly authorized command 3441 3442 3443 3444 3445 3446 3447 3448 3449 3450 3451 3452 3453 3454 3455 3456 2 2 3 2 3 2 U Usage considerations U FOUO Research to date indicates that the best standards technology available today to meet the required capabilities of the Cryptographic Binding function are best implemented via the Cryptographic Message Syntax RFC 2630 standard The Cryptographic Message Syntax CMS was derived from PKCS #7 version 1 5 as specified in RFC 2315 PKCS#7 U FOUO CMS is a data protection encapsulation syntax that employs ASN 1 X 208-88 X 209-88 This syntax is used to digitally sign digest authenticate or encrypt arbitrary messages It supports digital signatures message authentication codes and encryption The syntax allows multiple encapsulations so one encapsulation envelope can be nested inside another This capability aligns well with the needs defined for the cryptographic binding functionality see Figure 2 2-3 Encapsulation Notional diagram UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-37 UNCLASSIFIED FOR OFFICIAL USE ONLY ContentInfo SignedData InformationObjectCollection ContentInfo ContentInfo EncryptedData EncryptedData SignedData SignedData Information Object Source Metadata This figure is U 3457 3458 Figure 2 2-3 U Encapsulation Notional Diagram 3459 U FOUO CMS implementations must include the SHA-1 message digest algorithm defined in FIPS Pub 180-10 CMS implementations should include the MD5 message digest algorithm defined in RFC 1321 as well CMS implementations must include DSA signature algorithm defined in FIPS Pub 186 CMS implementations may also include RSA signature algorithm defined in RFC 2347 for use with SHA-1 and MD5 3460 3461 3462 3463 3464 3465 3466 3467 3468 3469 3470 3471 2 2 3 2 3 2 1 U Implementation Issues U FOUO The decision as to whether this crypto-binding and decrypt function is a central GIG service or a local plug in to affected applications may affect overall performance network overhead and user perception 2 2 3 2 3 2 2 U Advantages U FOUO CMS is flexible and nesting levels are expandable to meet program needs U FOUO CMS has been successfully implemented in commercial and government network environments UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-38 UNCLASSIFIED FOR OFFICIAL USE ONLY 3472 3473 3474 U FOUO CMS provides flexibility to program selection of message digest and signature algorithms Further as new encryption and signature algorithms the CMS syntax structure can be expanded to accommodate movement in the technology state of the art 3476 2 2 3 2 3 2 3 U Risks Threats Attacks U FOUO Decryption Analysis Attack 3477 U FOUO Compromised digital signatures 3478 3484 2 2 3 2 3 3 U Maturity U FOUO Elements of the CMS have a successful lineage from PKCS#7 and a wide variety of successful implementation examples in both commercial and DoD environments for the base encryption binding and linkage function However the interfaces to other GIG applications services and potential distributed nature of this function will drive a small to moderate level of new development As such we judge the overall TRL level of this technology to be in the Early to Emerging range 3-4 3485 2 2 3 2 3 4 U Standards 3475 3479 3480 3481 3482 3483 3486 Table 2 2-8 U Standards on Cryptographic Binding This Table is U Standard Description Cryptographic Message Syntax IETF RFC 2630 PKCS #7 version 1 5 9 IETF RFC 2315 This syntax is used to digitally sign digest authenticate or encrypt arbitrary messages Describes a general syntax for data that may have cryptography applied to it such as digital signatures and digital envelopes The syntax admits recursion It also allows arbitrary attributes such as signing time to be authenticated along with the content of a message and provides for other attributes such as countersignatures to be associated with a signature Standard specifies a Secure Hash Algorithm SHA-1 for computing a condensed representation of a message or a data file Standard describes the MD5 message-digest algorithm The algorithm takes as input a message of arbitrary length and produces as output a 128-bit fingerprint or message digest of the input Standard describes a keyed-hash message authentication code HMAC a mechanism for message authentication using cryptographic hash functions HMAC can be used with any iterative Approved cryptographic hash function in combination with a shared secret key This Table is U SHA-1 FIPS Pub 180-10 MD5 IETF RFC 1321 Hashed Message Authentication Codes FIPS PUB 198 3488 2 2 3 2 3 5 U Dependencies U Key management infrastructure 3489 U Metadata standards infrastructure 3487 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-39 UNCLASSIFIED FOR OFFICIAL USE ONLY 3490 3491 3492 3493 3494 3495 2 2 3 2 3 6 U Alternatives U FOUO SHA-1 in concert with RSA signature service could be implemented and used without standardized syntax CMS Syntax relation processing and infrastructure would need to be maintained in entirety by DoD GIG 2 2 3 2 3 7 U Complementary techniques U Described in section 2 2 3 2 3 2 3497 2 2 3 2 3 8 U References U Cryptographic Message Syntax IETF RFC 2630 3498 U PKCS #7 version 1 5 9 IETF RFC 2315 3499 U SHA-1 FIPS Pub 180-10 3500 U MD5 IETF RFC 1321 3501 U RSA IETF RFC 2347 3502 U Hashed Message Authentication Codes RFC 2401 3503 2 2 3 3 U Digital Access Control Policy U FOUO Influencing all aspects of the RAdAC model is the digital access control policy DACP It serves as an input to the Core RAdAC functions and as the deciding factor for allowing or denying access Although RAdAC will need specific capabilities in its DACP these policy needs should fold into the larger GIG dynamic policy effort Some potential technologies being examined for that enabler are WS-Policy Standard Deontic Logic and artificial intelligence constructs The scope of this section addresses only the RAdAC-specific needs for DACP and assumes that the dynamic policy enabler provides the necessary distributed functionality e g secure update revocation currency validation and caching for off-line use 3496 3504 3505 3506 3507 3508 3509 3510 3511 3512 3513 U FOUO The RAdAC model depicts DACP as influencing all aspects of internal RAdAC behavior In this role DACP must be expressive enough to address the following 3514 o U FOUO Minimum number of required inputs to calculate risk and operational need 3515 o U FOUO Relative weighting of the various inputs for risk and operational need 3516 o U FOUO Relative weighting of risk versus operational need for the final decision 3517 o U FOUO Ability to express stateful access control rules e g successive failed access attempts 3519 o U FOUO Ability to express policy according to enterprise and COI roles 3520 o U FOUO Ability to negotiate two or more conflicting access control rules 3521 o U FOUO Ability to negotiate access control policy with neighboring security domains 3518 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-40 UNCLASSIFIED FOR OFFICIAL USE ONLY in order to define an access control boundary interface that is agreeable to both sides 3522 3523 o U FOUO Ability to express and automatically select between multiple policies based on nationality or security domain o U FOUO Ability to express more granular or more restrictive access control policies at each successive echelon down the chain of command o U FOUO Ability to dynamically tighten or loosen access control policy based on situation INFOCON proximity to enemy forces etc o U FOUO Ability to reach a decision deterministically within bounded time 3524 3525 3526 3527 3528 3529 3530 3531 3532 3533 3534 U FOUO DACP also requires expressiveness to support RAdAC output For example the policy engine may recognize a specific request as having a compelling operational need but having too risky an IT Component to release the information to In this case policy should be expressive enough to conclude that an alternate path alternate Course of Action or COA for this LIMFAC should be examined For this role DACP expressiveness must address o U FOUO Ability to understand and specify in human- and machine-readable terms the limiting factors LIMFACs that contributed to a failed access attempt o U FOUO Ability to reason whether an alternate COA could sway the decision e g an uncleared user attempting to access Top Secret information could never be allowed-- regardless of the QoP offered by a specific route--because of national policy 3540 o U FOUO Integrity and timestamp features to avert malicious attacks 3541 o U FOUO Ability to select and reason about various enterprise alternatives e g alternate routing for higher QoP imposed digital rights to limit risk automatic sanitization options nearby neighbors with sufficient access via comparison and what if scenarios 3535 3536 3537 3538 3539 3542 3543 3544 3545 3546 3547 3548 3549 3550 3551 3552 3553 3554 3555 3556 3557 3558 U FOUO Finally extraordinary operations support requires that DACP be able to handle policy exceptions that are able to authorize normally disallowed actions due to an extremely urgent operational need Most likely such an authorization would be tightly constrained by time controls very limited access period and additional access distribution controls very minimal set of well-defined actions to limit risk 2 2 3 3 1 1 U Technical details U FOUO DACP must be able to reach a decision based on risk computation operational need computation and policy input Final decision logic uses digital policy to compare risk and need computations against acceptable thresholds specify a decision and generate a corresponding access token of some sort generate a decision rationale and generate an audit record U FOUO The DACP language features must support conflict detection and resolution negotiation across RAdAC domains COIs dynamic update ontology specification and human readability Policy must be able to be securely updated revoked and enforced within acceptable performance margins to ensure currency with dynamic enterprise policy UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-41 UNCLASSIFIED FOR OFFICIAL USE ONLY 3559 3560 3561 3562 3563 3564 3565 3566 3567 3568 3569 3570 3571 3572 3573 3574 3575 3576 3577 3578 3579 3580 3581 3582 3583 3584 3585 3586 3587 3588 3589 3590 3591 3592 3593 3594 3595 3596 3597 U FOUO RAdAC must have a grammar that can succinctly express decision rationale that is unequivocally tied to the input received including the ability to list limiting factors LIMFACs in both a machine-understandable and human-readable format U FOUO While the ability to discover and select an alternate COA is a highly desirable feature of a RAdAC-enabled system embedment of this capability within the core RAdAC model would severely impact the performance of the access decision process Rather than embed this functionality within RAdAC the preferred approach is to have an offload capability to a separate service to perform this analysis and make recommendations Similar digital access control policy can be used by this ACOA service to reason about alternatives it considers and this ACOA service may optionally provide a user interface for the User to select between possibly less desirable alternate COAs U FOUO The ability to handle temporal exceptions for extraordinary operations via dispensations or work flows is a critical DACP feature to enable RAdAC dynamic operations support Certain deontic languages provide this capability in the form of dispensations that augment the DACP based on a compelling temporal need Other approaches include work flows to address the specific LIMFACs identified in access control decisions Regardless of the technical approach great care must be taken to constrain where dispensations are allowed and not allowed within the policy language due to national law or immutable operational policy For example dispensations may be allowed for dissemination of a classified document to a cleared User without formal access approval given compelling operational need but may never be allowed for an uncleared User Dispensations may be the most appropriate way for digital policy to annotate and reason about a commander or supervisor's consent for a User's operational need to know a particular piece of information U FOUO The policy must be robust enough offer a low error rate i e meet extremely stringent false negative and false positive rates Since RAdAC would be replacing the traditional Mandatory Access Control model objectively false positives in particular cannot be tolerated for risk of information disclosure Dispensations for exception handling must be constrained in such a way that guarantees select portions of digital access control policy will comply with national law 2 2 3 3 1 2 U Usage considerations U FOUO Since DACP forms the primary underpinning of the RAdAC model its implementation will require significant analysis and community vetting It will also require protections against a wide range of security threats since it will be a likely target of IW attack 2 2 3 3 1 2 1 U Implementation Issues U FOUO Conflicting laws and policies - Established laws and organization security policies require sufficient clearance formal access approval and need to know to establish authorization for classified information We need to do an assessment of how RAdAC maps to these requirements e g does operational need equate to need to know to determine which laws and organization policies require amendment UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-42 UNCLASSIFIED FOR OFFICIAL USE ONLY 3598 3599 3600 3601 3602 3603 3604 3605 3606 3607 3608 3609 3610 3611 3612 3613 3614 3615 3616 U FOUO Human understandable access control policy - Enterprise managers and certifiers will want a human-readable format to the Access Control Policy to examine and evaluate its specifications but RAdAC will need fast machine-readable versions of the same policy to meet performance needs U FOUO Supporting decision rationale - A format grammar must be developed to express the rationale for an access control decision and any associated LIMFACs and deciding factors This grammar may need to be purposefully limited though to avoid disclosing too much information about the current DACP and how to influence its decisions U FOUO Minimal acceptable input parameters - Need to do research in defining the minimum quorum and pedigree of input parameters necessary to make an access decision with bounded risk Does this minimal set vary based on the Environment CONUS versus tactical or Situation exercise versus active engagement Are heuristics employed only if the access is not decidable given the other input parameters or is it always part of the decision process U FOUO IT Component integration - DACP and RAdAC's decision output must be tightly integrated with the policies that affect the management of the IT Components This avoids situations where RAdAC allows access through a given enterprise route but then the enterprise routes the information over a different path because of other decision metrics Digital rights policy enforcement must be tightly integrated with the end user equipment portion of IT Components so that the rights embedded with the information object are strictly enforced 3619 2 2 3 3 1 2 2 U Advantages U FOUO Supports dynamic operations through update and reasoning about operational need and security risk for access control decisions 3620 U FOUO Facilitates expression in human understandable format for analysis and update 3621 U FOUO Supports exception handling for extraordinary operations with compelling operational need 3617 3618 3622 3623 3624 U FOUO Extends beyond the access decision to address soft object life cycle and distribution controls 3626 2 2 3 3 1 2 3 U Risks Threats Attacks U FOUO Spoofing or man-in-the-middle unauthorized modification of policy updates 3627 U FOUO Replay of access control requests or decisions to cause a denial of service 3628 U FOUO Unintentional misconfiguration of DACP can introduce access denial or confidentiality breaches 3625 3629 3630 3631 U FOUO Exception handling could potentially be misused by insiders to gain access to unauthorized soft objects e g exaggerating operational need UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-43 UNCLASSIFIED FOR OFFICIAL USE ONLY 3632 3633 3634 3635 3636 3637 3638 3639 3640 3641 2 2 3 3 1 3 U Technology Standards Analysis U Specific technologies and standards for digital policy are analyzed in Section 2 4 This subsection applies that analysis specifically to the digital policy needs for Policy-Based Access Control U FOUO XML Access Control Markup Language XACML has been pushed within the web services and DoD network-centric initiatives and has reached significant maturity as a result but it has some serious limitations for digital access control policy The largest limitations are its present inability to understand ontology and to resolve conflicting policy assertions A third limitation is in the area of dispensations since they can only be approximated through a policy update and policy revocation after a specified period 3649 U FOUO The standards being developed under the W3C semantic web initiative appear to meet the wide range of needs for digital access control policy They address ontology via OWL and use deontic logic to capture reason through and apply business rules according to underlying mathematics Certain deontic logic technologies such as Rei and KaOS offer the ability to create and apply dynamic dispensation rules as well Though the expressiveness of the standards appear sufficient to cover the needs for digital access control policy further analysis needs to be done to extend the deontic logic math model to address specific access control needs verify performance of the technologies and verify scalability to an enterprise level 3650 2 2 4 3651 3657 2 2 4 1 U Core RAdAC Gap Analysis U FOUO The Core RAdAC functions are in their infancy with respect to concept formulation standards development and technology implementation as shown from a summary level in Table 2 2-9 Industry really will not benefit from RAdAC as the Government will so it is not surprising to see little research and development in this area Industry is showing interest in rolebased access control and now attribute-based access control but RAdAC's unique features put it on a complementary but dissimilar technology path 3658 U FOUO The following technology gaps exist for RAdAC 3642 3643 3644 3645 3646 3647 3648 3652 3653 3654 3655 3656 3659 3660 3661 3662 3663 3664 3665 3666 3667 3668 o U Distributed Policy Based Access Control Gap Analysis U FOUO Attribute Based Access Control standard - Although there is research and even initial product offerings for ABAC-based products there is no IETF or Government standard Cisco and Maxware have proprietary products and Network Associates is doing research funded by SPAWAR but none meets all of the attribute requirements for RAdAC Since we are looking at ABAC as an interim implementation of RAdAC we could employ a proprietary solution while RAdAC is being explored and developed in parallel But we would do so at the potential risk of it becoming the GIG standard if RAdAC is not realizable for a presently unknown technical or political reason Prudence dictates that we have an alternate fallback standard in place given the current immaturity of RAdAC and its critical role in the enterprise UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-44 UNCLASSIFIED FOR OFFICIAL USE ONLY 3669 o U FOUO Protection Profiles - There are no current or planned protection profiles that address RAdAC or attribute-based access control Existing protection profiles are limited to Orange Book approximations These protection profiles are necessary to establish the minimum security protections required for any implementation of RAdAC o U FOUO RAdAC standard - Since industry is not moving in the RAdAC direction there are no formal representations of architecture interface definitions performance requirements or protocol requirements o U FOUO RAdAC math model - RAdAC needs an underlying math model to meet medium and high assurance implementation requirements and to assist in the transformation from a DAC and MAC access control culture This math model needs to include the digital access control policy since the two are so tightly integrated Further extensions to the deontic logic math model need to be accomplished to apply it specifically to the access control domain and prove mappings of certain policy constructs to traditional DAC and MAC access control models o U FOUO Input parameter ontology - All attributes that feed the RAdAC model need to have an ontology that is accessible and standardized This applies to attributes of IT Components Environment Situation Soft Objects metadata and People 3670 3671 3672 3673 3674 3675 3676 3677 3678 3679 3680 3681 3682 3683 3684 3685 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-45 UNCLASSIFIED FOR OFFICIAL USE ONLY 3686 Table 2 2-9 U Technology Adequacy for Access Control 3687 This Table is U Enabler Attributes CoreAccess Control Digital Rights Access Control Policy Required Capability RCD attribute Risk Need Determination N A IAAC4 Math model N A IAAC4 Decision logic N A IAAC1 IAAC4 IAAC7 N A IAAC4 Exception handling N A IAAC5 Conflict resolution N A IAAC7 Ontology N A Object Lifecycle IAAC8 Protection Profile IAAC9 This Table is U 3688 3689 3690 3691 3692 2 2 4 2 U Assured Metadata Gap Analysis U FOUO From an overall prospective as shown in Table 2 2-10 U Technology Adequacy for Metadata the technology and functionality gaps in the assured metadata area will not require the same levels of technology leaps or major innovations in comparison to the RAdAC portion of this enabler or other technologies needed in the GIG UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-46 UNCLASSIFIED FOR OFFICIAL USE ONLY 3693 3694 3695 3696 3697 3698 3699 3700 3701 3702 3703 3704 3705 3706 3707 3708 3709 3710 3711 3712 3713 3714 3715 3716 3717 3718 3719 3720 3721 3722 3723 3724 3725 3726 U FOUO For the metadata standards area both the IC and DoD are working on the definition of standards to support discovery and marking of information that will be part of the GIG Both groups have built their standards implementation schemas based on a widely proven and available commercial language technology XML and OWL Further an initial gap analysis has been completed which compares the capabilities IA attributes needed to support RAdAC style access control decision making and discovery See Table 2 2-6 U Metadata Gap Analysis with these standards The process of coordinating between these two organizations has been started to ensure that these required IA attributes are integrated into these implementation standards Stability or backward compatibility of these IA attributes from a syntax and semantics prospective will be critical If not well planned changes after final approval will likely ripple to changes in supporting tools and infrastructure or could affect large quantities of previously populated information object metadata records Finally prior to stabilizing the metadata standards and IA attributes it is strongly recommended that further studies be conducted examining the impact and potential for optimization regarding the increased of metadata IA granularity and its potential GIG impact to network traffic overhead especially for real-time and session object types U FOUO The development of trusted metadata creation tools can parallel the metadata standards in initial design However final development integration and testing will be dependant on a stable and accepted metadata standard s with required IA attributes There have been successful implementations and commercial products that provide metadata creation tools based on the XML web publishing Dublin Core metadata standard and have been applied to their communities' metadata standard and creation needs in the commercial environment However the IA related capabilities and interfaces as defined in section 2 2 3 2 2 1 are new complex and unique to this GIG implementation U FOUO In the area of cryptographic binding of metadata to its source information Cryptographic Message Syntax RFC2630 is the recommended technology standard This syntax standard provides the capability to support selectable digest and signature algorithms It is also expandable to support the potential inclusion of other algorithms standards as technology progresses However like the metadata creation tools the GIG and IA interface aspects required of this capability will remain a technical challenge U FOUO NOTE The metadata IA attributes analysis is currently focused on the various forms of GIG information objects IA metadata attributes unique to service objects and their supporting tools are currently in work and will be addressed in the next release of the technology roadmap UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-47 UNCLASSIFIED FOR OFFICIAL USE ONLY Table 2 2-10 U Technology Adequacy for Metadata 3727 This Table is U Metadata Standards Language Metadata Creation Tools Metadata Cryptographic Binding Required Capability RCD attribute Commercial Standards Based IAIL1 IAIL2 IAIL3 IAIL4 IAIL6 IAIL13 IAIL16 Enabler Attributes GIG or IA assurance unique interfaces provided GIG Governance Standards Bodies in Place N A IAIL5 IAIL10 IAIL12 IAIL16 IAIL17 Need to Share Control Granularity supported N A IAIL9 IAIL10 IAIL12 IAIL14 RAdAC value and Modifier Construct supported N A IAIL9 IA Attribute Internal Consistency syntax Checking N A IAIL9 IAIL10 IAIL20 Cryptographic Performance up to Type 1 Assurance N A N A This Table is U 3728 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-48 IAIL15 UNCLASSIFIED FOR OFFICIAL USE ONLY 3729 3730 3731 3732 3733 3734 2 2 4 3 U Digital Access Control Policy Gap Analysis U FOUO The proposed OWL v2 0 standard for ontology and the deontic language implementations Rei and KaOS appear to meet the expressiveness required for digital access control policy but there is significant work needed to realize a complete implementation that will meet GIG information-sharing requirements The following list describes the major gaps o U DACP standard A digital access control policy standard that uses ontology and deontic languages needs to be developed based on the underlying math model This standard will address the access control policy grammar exception handling business rules about allowable and disallowable policy constructs and business rules for policy negotiation and deconfliction o U Digital Rights Management integration specification Digital Rights can be viewed as a static projection of digital access control policy onto a particular soft object There is currently ongoing research in the Digital Rights realm and proposed standards but none of them specify a relationship to digital access control policy An analysis of their relationships digital rights implementation XrML or otherwise and Policy Enforcement Point interface is necessary to complete the end-to-end access control of GIG information and support the transition to a need-to-share culture 3735 3736 3737 3738 3739 3740 3741 3742 3743 3744 3745 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-49 UNCLASSIFIED FOR OFFICIAL USE ONLY 3746 3747 3748 2 2 5 U Policy Based Access Control Recommendations and Timelines U FOUO The following is a list of prioritized distributed policy-based access control gap closure recommendations or actions They are listed from highest to lowest priority 3749 o U FOUO Develop Attribute-Based Access Control standard 3750 o U FOUO Develop ABAC and RAdAC Protection Profiles 3751 o U FOUO Develop RAdAC standard 3752 o U FOUO Develop RAdAC math model 3753 o U FOUO Conduct RAdAC prototyping for requirements discovery This activity feeds input ontology development RAdAC standard development DACP standard development and Digital Rights integration specification o U FOUO Work with IC and CES Metadata working groups to integrated IA attributes into a standard in accordance with detailed analysis or preferred support the merge of these standards and ensure IA RAdAC required attributes are included o U FOUO Begin early design of metadata creation tools in parallel with metadata standards definition to ensure IA specific attributes and authorization interface needs are addressed 3762 o U FOUO Develop input parameter ontology 3763 o U FOUO Conduct study on RAdAC performance and optimization techniques 3764 o U FOUO Conduct RAdAC pilot program to test fielding and operational issues 3765 o U FOUO Develop DACP standard with associated business rules 3766 o U FOUO Develop Digital Rights integration specification 3767 o U FOUO Conduct study on impact and potential for optimization of metadata IA granularity related to GIG network traffic overhead o U FOUO Continue work of defining the GIG services metadata tagging capabilities potential technologies 3754 3755 3756 3757 3758 3759 3760 3761 3768 3769 3770 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-50 UNCLASSIFIED FOR OFFICIAL USE ONLY 3771 U FOUO Figure 2 2-1 summarizes timeframes for these closure recommendations Technology 2004 Attribute-based Access Control Standard 2006 2008 2010 2012 Access control based on security label and privilege 2014 2016 2018 2020 Protection Profile for Med and High Assurance RAdAC and ABAC DACP Standard Approved DACP Standard Digital Rights Integration Specification Pilots using Policy-driven AC Mechanisms - IDs Privs and I A SoM with Manual Override Support Access control based on role and citizenship classification and I A SoM with manual override RAdAC Prototypes with Risk and Operational Need RAdAC Formal Math Model Input Ontology and Interface Definition RAdAC Standard Approved RAdAC Standard RAdAC Performance Study and Optimization All access control driven by RAdAC model - RAdAC fully implemented RAdAC Pilots DACP and RAdAC Standard Revision to Support Local Processing Model Distributed centralized and local Access Control Processing models all supported RAdAC Pilots Integrate IA Attribute Gaps into IC and CES Metadata WG Metadata Standard Initial IA Metadata Creation Tools Enhanced Metadata Creation Tools Cryptobinding of Metadata to Object Tools based on Metadata WGs and commercial standards Improved automation context help autofil policy based syntax checks Binding service and GIG IA interface based on Commercial Standards This Figure is U FOUO 3772 3773 Figure 2 2-4 U Policy-Based Access Control Gap Closure Timelines UNCLASSIFIED FOR OFFICIAL USE ONLY 2 2-51 UNCLASSIFIED FOR OFFICIAL USE ONLY 3774 3775 3776 3777 3778 3779 3780 3781 3782 3783 3784 3785 3786 3787 3788 3789 3790 3791 3792 3793 3794 3795 3796 3797 3798 3799 3800 3801 3802 3803 3804 3805 3806 3807 3808 3809 3810 3811 3812 2 3 U PROTECTION OF USER INFORMATION U FOUO Protection of user information provides the protection of data-at-rest and data-intransit from end-entity to end-entity For applications based on the client-server model common to much of today's networks this GIG vision would provide integrity confidentiality and other required security services in both directions between the originating client and the responding server For peer-to-peer-based applications this provides those same services between the corresponding peers For applications-based on other models appropriate security services will be applied U FOUO End-to-end protection of user information does not always mean security services are provided between the true endpoints of communication There is always a trade-off to be made For example if end-to-end confidentiality is provided that implies that the information is encrypted between the requesting client and the responding server That means that GIGprovided or organization-provided infrastructure devices such as intrusion detection systems and firewalls cannot examine the data as it passes This makes it difficult to detect and stop malicious code such as viruses or worms it makes it difficult to perform content-based filtering e g Spam checking and it makes it more difficult to detect and stop intrusions In this scenario the client node itself must provide all security This may not be feasible for commercial operating systems and products--even in the 2020 time frame--and it may make it very difficult to detect attacks from authorized GIG insiders U FOUO Even within single devices end-to-end protection of user information may have different meanings depending on the specific application or organization For example multiple users or user identifiers may share a single end-point e g multiple users may share a client node and multiple services may share a single server End-to-end communications security in this context may mean client-to-server security or it may mean end-user-to-server-identifier security U FOUO Thus depending on the enterprise and U S Government policy different applications may have end-to-end security between clients and servers or communicating peers or they may have end-to-end security between organizational enclaves or between other points These situations are entirely consistent with the GIG Vision U FOUO However there is much work to be done before this vision can be accomplished The current environment includes many systems operating in different domains and at different security levels Communication and interoperation among these domains and across these different security levels is not always possible True end-to-end secure communications cannot be provided in the current or near-term GIG U FOUO For the current and near-term GIG implementations Cross-Domain Solutions provides the necessary secure interoperation Applications and communications must be secured within a single security level--within a domain Then interactions between domains are allowed by using cross-domain solutions e g guards gateways and firewalls and specific routing techniques UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-1 UNCLASSIFIED FOR OFFICIAL USE ONLY 3813 3814 3815 3816 3817 3818 3819 3820 3821 U FOUO As the GIG evolves from the current capability set to the vision system this will gradually change As core systems are fielded that can allow the merger of domains and supporting multiple classification levels in a system less emphasis will be placed on such crossdomain solutions as guards and content filters More emphasis will be placed on security at the end-points whether those end-points are enclave boundaries or client nodes themselves 2 3 1 U GIG Benefits Due to Protection of User Information U FOUO The Information Assurance constructs used to support Protection of User Information provide the following services to the GIG o U FOUO Protects information in accordance with enterprise-wide policy and the data owner's specified Quality of Protection QoP o U FOUO Allows multiple users to use a single workstation so a user can walk up to a client and access their information o U FOUO Allows access to multiple levels of information on the same platform without compromising that information i e trusted hardware software platforms o U FOUO Protects against the analysis of network protocol information traffic volume and covert channels o U FOUO Provides user-to-user protection of secure voice traffic from speaker to listener 3822 3823 3824 3825 3826 3827 3828 3829 3830 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-2 UNCLASSIFIED FOR OFFICIAL USE ONLY 3831 3832 3833 3834 3835 3836 3837 3838 3839 3840 3841 3842 3843 3844 3845 3846 3847 3848 3849 3850 3851 3852 3853 3854 3855 3856 3857 3858 3859 3860 3861 3862 3863 3864 3865 3866 2 3 2 U Protection of User Information Description U FOUO Protection of user information provides the protection of data objects at rest and the protection of data-in-transit Data-at-rest protection is the protection of data objects while they are stored in repositories across the GIG and within a client's local environment Data-in-transit protection is the protection of information flows as they move across the GIG within all levels of the transmission protocol stack including application network and link level U FOUO Protection of User Information also includes the concept of the GIG Black Core The Black Core is the packet-based portion of the GIG where packet level protections are provided between end entities Over time end entities providing packet level protections move from the network boundaries to the enclave boundaries to the end clients Circuits within the GIG will be protected with circuit encryption In addition some high risk links may need additional protections if the risk of traffic analysis or other threat is exceptionally high Possible solutions include link encryption and TRANSEC U FOUO Classified information will be protected using high assurance Type 1 mechanisms while unclassified information will be protected using evaluated commercial mechanisms To support the end state capability to enable users to access the proper information encryption boundaries must be able to support both Type 1 and commercial mechanisms Encryption products must also have access to the proper key material to protect all classifications of information U FOUO The protection of user information must support large numbers of dynamic communities of interest COI Support for COIs does not necessarily imply encrypted tunnels between COI members COIs can also be accomplished through other mechanisms such as filtering e g Access Control Lists ACLs or logical separation e g Multi Protocol Label Switching MPLS Labeled Switch Path LSPs Sufficient auditing mechanisms are necessary to track the establishment and termination of COIs U FOUO To support connectivity between GIG networks and coalition networks mechanisms are necessary that allow information flows to pass between coalition partners and the GIG Each coalition network will be different and require different security mechanisms and procedures Some coalition networks will be owned and operated by the U S with partners using resources Other will be owned and operated by allies with U S users Still others will be owned and managed by a number of different allies all intended to seamlessly interconnect These mechanisms are enforced in a construct referred to as a trust manager U FOUO Trust managers enforce policy for connections to coalition partners and allow or disallow individual connections between GIG users and coalition partners Trust managers can filter traffic types allow or disallow specific users monitor information flows or enforce any other policy required for coalition connections UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-3 UNCLASSIFIED FOR OFFICIAL USE ONLY 3867 3868 3869 3870 3871 3872 3873 3874 3875 3876 3877 3878 3879 3880 3881 3882 3883 3884 3885 3886 3887 3888 3889 3890 3891 3892 3893 3894 3895 U FOUO Whenever GIG systems interact with coalition or an ally's resources both sides of the connection will have security mechanisms in place While the GIG will be able to control policy on the GIG side of the connection the coalition partner will set policy for the other side of the connection This compounds the problem of information sharing with coalition partners This is similar to the issues with sharing information across GIG systems as both policies must be coordinated Information shared with coalition partners could include all types of data objects and data formats including data files messaging video streaming video voice and web traffic U FOUO The GIG will require that clients and computing platforms i e hardware and software have more inherent trust than they do today Devices directly accessible by users-- running a variety of user applications and connected to untrusted networks--tend to be the least trustworthy devices in the network They are ripe targets for malicious code attacks and misconfiguration However the GIG will rely on clients to do a variety of security-critical functions e g maintain domain separation when accessing information at various levels of sensitivity support authentication of a user to the infrastructure support authentication of a client to the infrastructure properly label data enforce local security policy properly encrypt data U FOUO In today's system high environments i e JWICS SIPRNet less trust in clients is required since all users within an environment have an equivalent level of trust While placing trust in clients today may seem unreasonable the GIG Vision requires that procedures and mechanisms be in place to allow clients to perform critical security functions A higher level of trust within clients is especially important as coalition users and networks are connected to the GIG and as today's system high boundaries are eliminated A higher level of trust is required for all devices in the GIG-- not just end user clients All devices in the GIG will be required to perform security related functions and there must be a sufficient degree of trust in these devices for them to reasonably execute their functions U FOUO The GIG however will consist of IT devices i e routers servers clients with varying levels of trust The GIG will use a concept referred to as Quality of Protection for data objects As part of the data labeling an object will be associated with security properties and policies necessary for protecting the object Properties can include o U FOUO How to protect the object as it travels across the network e g commercial grade vs Type 1 protections object and or packet or link level data-in-transit protection requirements o U FOUO How the data object can be routed e g must be contained within the GIG can flow to or through networks external to the GIG such as coalition networks or the Internet o U FOUO How the data object must be protected while at rest QoP is different from metadata that describes the contents of the object 3896 3897 3898 3899 3900 3901 3902 3903 3904 3905 3906 U FOUO Metadata is designed to enable discovery and data sharing QoP defines how a data object is protected while it is at rest and in transit When QoP is defined it should not reveal attributes related to the data originator or client Policy-Based Access Control will provide the enforcement mechanisms to assure the specified QoP is provided UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-4 UNCLASSIFIED FOR OFFICIAL USE ONLY 3907 3908 3909 3910 3911 3912 3913 3914 3915 3916 3917 3918 3919 3920 3921 3922 3923 3924 3925 3926 3927 3928 3929 3930 3931 3932 3933 3934 3935 3936 3937 3938 3939 3940 3941 3942 3943 3944 3945 U FOUO Data-at-rest protection will be required for some types of data e g for extremely sensitive information and for certain environments e g information stored on a local client within a hostile environment The requirements for data-at-rest protection will be identified through a protection policy such as within a data object or client's protection policy For shared information data-at-rest protection must be provided at the object level where an object is defined as a file or pieces of a file such as paragraphs This leads to a large range of object types U FOUO All data objects must be protected properly GIG users must be able to discover and access objects This will require a key management infrastructure that can dynamically deliver the key material to access objects requested by the user Data-at-rest for local clients can be provided in a number of ways including media encryption mechanisms U FOUO Protection of data-in-transit consists of the ability to provide confidentiality integrity and authentication services to information as it is transmitted within the GIG The QoP information will describe the services needed for any specific data object U FOUO Protection of data-in-transit includes providing traffic flow security TFS TFS should be provided for all high-risk links in the GIG but could also be provided for medium or low-risk links In general TFS protections include mechanisms that protect against network mapping and traffic analysis In general the lower in the protocol stack confidentiality is applied the greater the TFS benefit For circuits end-to-end circuit encryption provides traffic flow security For IP networks a variety of mechanisms can be used For IP environments where the communications links are circuit based and the routers are protected one option could be hop-byhop link encryption applied to the communications links to provide traffic flow security for encrypted packet traffic TFS mechanisms however have a performance impact and should be carefully matched against the risk for the information flow U FOUO Protection of data-in-transit also includes the ability to prevent unauthorized transmission of data within the GIG A covert channel is an unauthorized information flow that is precluded by the network's security policies Covert channels must be eliminated to permit global access of information required within the GIG U FOUO Network layer data-in-transit security is the protection of IP packets as they flow across the GIG Protection could be from enclave to enclave to enclave or from host to host High Assurance Internet Protocol Encryptor HAIPE -compliant devices will be used to provide Type 1 data-in-transit network layer security for the GIG At a minimum Unclassified data will be protected using medium robustness Type 3 solutions U FOUO Speech traffic Voice over IP VoIP within the GIG can be protected at the Network Layer Currently HAIPE can only provide enclave-to-enclave protection In the future when HAIPE is integrated into end-systems the protection can be migrated from the enclave level back to the user level This functionality will require the development of a new mode within the HAIPE standard to meet the real-time performance requirements of a Voice over Secure IP VoSIP terminal UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-5 UNCLASSIFIED FOR OFFICIAL USE ONLY 3946 3947 3948 3949 3950 3951 3952 3953 3954 3955 3956 3957 3958 3959 3960 3961 3962 3963 3964 3965 3966 3967 3968 3969 3970 3971 3972 3973 3974 3975 3976 3977 3978 3979 3980 3981 3982 U FOUO Media gateways can also be defined to extend speech capability beyond the GIG to legacy circuit-based systems although Network Layer security is not effective beyond such a gateway Therefore using HAIPE to protect speech traffic would require Red gateways to legacy circuit-switched networks The appropriate security e g Future Narrow Band Digital Terminal FNBDT would have to be applied on the circuit-switched side of the gateway to protect the speech traffic over a legacy network U FOUO Application Layer data-in-transit security is the protection of information as it flows from one end user terminal to another where the end user terminals apply the protection mechanisms and the protected information is not accessible at any point during transmission U FOUO Within the GIG most speech traffic is carried across circuit switched networks Speech traffic in circuit switched networks is protected at the application layer using Secure Terminal Unit-Third Generation STU-III or Secure Terminal Equipment STE products STU and STE products provide application layer speaker to listener security Future secure voice products and architectures must consider interoperability with existing secure voice products e g secure voice products used by NATO tactical secure voice products U FOUO Application layer protection of speech traffic VoIP within the GIG could also be accomplished through development of secure VoIP terminals Interoperability of secure VoIP terminals will require a common implementation of FNBDT over IP Secure VoIP terminals will provide end-to-end Multiple Single Levels of security across the Black Core That is although only one session is permitted on each end terminal at a time subsequent sessions can be established at different security levels U FOUO Secure VoIP terminals can be placed on the Black Core to provide end-to-end Application Layer security across the Black Core VoIP gateways can also be developed to provide interoperability with legacy FNBDT products on the Public Switched Telephone Network PSTN Such a gateway requires access to the IP network on one side and access to appropriate circuit-based networks on the other The gateway then provides interworking between the IP protocol stack and a circuit-based modem There are some issues e g transcoding in the gateway needs to be disabled but these issues can be resolved to provide a Black gateway solution for the FNBDT Application Layer security approach U FOUO Secure VoIP terminals can also be placed in Red enclaves to provide user-to-user security whereas HAIPEs fronting the enclaves only provide enclave-to-enclave security FNBDT can be overlaid on HAIPE to provide this user-to-user level of security U FOUO Overlaying FNBDT on top of HAIPE provides several benefits First it provides confidentiality of user voice traffic within the enclave Second it allows the security level of the voice session to be based on the clearances of the users rather than the security level of the Red enclave Finally it enables interoperability between phones attached to networks at different security levels cross-domain solutions UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-6 UNCLASSIFIED FOR OFFICIAL USE ONLY 3983 3984 3985 3986 3987 3988 3989 3990 3991 3992 3993 3994 3995 3996 3997 3998 3999 4000 4001 U FOUO Communications between two secure VoIP terminals in different enclaves where the two enclaves are in the same security domain is relatively straightforward The HAIPE fronting the two enclaves perform network level encryption between the enclaves and the Secure VoIP phones attached to the Red enclave networks perform FNBDT application level encryption between the two users In this scenario the users are not restricted to a conversation at the security level of the Red enclave networks For example two users with Top Secret clearances could hold a Top Secret conversation on phones attached to secret level enclave networks Note this scenario utilizes Red enclave call control call control in the security domain of the Red enclaves U FOUO From the above examples it can be seen that there are potentially multiple domains of call control A single user and associated secure VoIP terminal could potentially use multiple call control domains The call control domain used for an instance of communications would be based on the security domains of the networks where the local and remote users' secure VoIP terminals are attached U FOUO Data-in-transit protection can also be applied to the GIG at protocol stack layers other than Network and Application This protection may be in place of or in addition to security at other layers Specifically many individual links within the GIG may require protection appropriate for the Physical Layer such as transmission security TRANSEC Security at this layer provides protection that cannot be obtained at other layers including 4002 o U FOUO Anti-Jam A J 4003 o U FOUO Low Probability of Interception Detection LPI LPD 4004 o U FOUO Traffic Flow Security TFS and Traffic Analysis Protection 4005 o U FOUO Signals Analysis Protection 4006 o U FOUO Protocol and Header Cover Packet Masking 4007 o U FOUO TRANSEC Isolation for Major Sets of Users 4008 4009 4010 4011 4012 4013 2 3 3 U Protection of User Information Technologies U FOUO The technologies in this enabler are organized into technologies that provide data-atrest protection data-in-transit protection trusted platforms trusted applications Cross Domain Solutions and non-repudiation The data-in-transit protection technologies are further organized by protocols layers Non-repudiation and Cross Domain Solutions are broken out separately because they do not fit cleanly into either data-at-rest or data-in-transit UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-7 UNCLASSIFIED FOR OFFICIAL USE ONLY 4014 4015 4016 4017 4018 4019 4020 4021 4022 4023 4024 4025 4026 2 3 3 1 U Technologies for Protecting Data-at-Rest U EDITOR'S NOTE MATERIAL ON PROTECTING DATA-AT-REST WILL BE ADDED IN A FUTURE RELEASE SECTIONS ARE PROVIDED BELOW THAT REFLECT THE TYPE OF CONTENT PLANNED 2 3 3 1 1 U Cryptography U There are several applications of cryptography for protecting data at rest including encryption signing authentication binding and integrity checking Cryptographic capability may reside in dedicated security devices or be provided within the host itself 2 3 3 1 1 1 U Storage Networks and Networked Storage Operations U There is an increasing trend towards the use of storage networks to share storage resources data and or capacity or to provide geographic distribution of storage assets for increased availability and survivability Network Attached Storage NAS and Storage Area Networks SAN are the two primary approaches SANs introduce or exacerbate security problems due to the following 4027 o U A very large amount of information may be contained within one system 4028 o U Storage resources may need to be shared between domains or enclaves 4029 o U Storage assets may be directly accessible from the network including the WAN 4030 o U The storage network management infrastructure needs protection 4031 o U Access enforcement is remote from data owners producers and data users 4032 o U Possible distribution of storage elements over large distances 4033 4034 4035 4036 4037 4038 4039 4040 4041 4042 4043 4044 4045 U A NAS provides file storage using Network File System NFS or Common Internet File System CIFS over TCP IP A SAN provides virtual disk volume storage using a Small Computer Systems Interface SCSI family protocol IP-based storage protocols are being developed and implemented Elements of a storage network include storage arrays switches host bus adapters hosts and security devices U Whether storage networks are used or not there are also existing storage operations across the GIG networks that have similar security concerns These include replication of data among distributed sites distributed data stores backup and restorable operations between sites and archives of data to remote sites U FOUO In general security standards and specifications for network storage are less mature than those for communications security There are no common definitions of security services across vendors Across security services vendors common definitions are lacking and a corresponding shortfall in security products and security features for storage devices exist UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-8 UNCLASSIFIED FOR OFFICIAL USE ONLY 4046 2 3 3 1 2 U Data Backup Archive 4047 2 3 3 1 3 U Data Destruction 4048 2 3 3 1 4 U Labeling 4049 2 3 3 1 5 U Periods Processing 4050 2 3 3 1 6 U Physical Controls 4051 2 3 3 1 7 U Quality of Protection U FOUO Quality of Protection is a ranked set of end-to-end protection properties of a system that collectively describe how resources will be protected within that system These properties may include network infrastructure characteristics client IT characteristics and the cryptographic capabilities of the IT and network components A resource will not be made available to a user unless the resource protection requirements can be met by the QoP level of the system or another policy supersedes these requirements The QoP of the system is not typically one fixed level but is instead a range of available capabilities that can be utilized by the component enforcing the resource protection requirements For example in routing a packet a path that meets the packet's resource protection requirements is utilized if available and if in accordance with QoS and other applicable policy For data-at-rest the QoP includes such topics as controls for copying the data moving the data and printing 4052 4053 4054 4055 4056 4057 4058 4059 4060 4061 4062 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-9 UNCLASSIFIED FOR OFFICIAL USE ONLY 4063 2 3 3 2 U Technologies for Protecting Data-in-Transit 4064 2 3 3 2 1 U Application Layer Technologies U Application Layer security technologies typically secure primary user data and may also secure aspects of the application protocols themselves Application Layer security can provide protection of user data while in transit and in some case while stored These security technologies do not generally provide protection against traffic analysis or attacks on lower layer protocols e g IP 4065 4066 4067 4068 4069 4070 4071 4072 4073 4074 4075 4076 U Application security technologies are characteristically different for real-time applications than for non-real-time applications Real-time applications include technologies such as streaming audio and video Non-real-time applications include such technologies as email web browsing and web services 2 3 3 2 1 1 U Non-Real-Time Data Technologies U Three basic classes of technology are used to provide non-real-time application security These consist of the following 4077 o U Traditional Layered Application Security Technologies 4078 o U Session Security Technologies 4079 o U Web Services Security Technologies 4080 4081 4082 4083 4084 4085 4086 4087 4088 4089 4090 4091 4092 4093 4094 U Security technologies for applications that operate in non real-time apply a wide spectrum of techniques to the problem of securing primary user data end-to-end Such technologies generally provide a generic framework for using basic security mechanisms--such as cryptography oneway functions and security protocols--to potentially provide abstract security services within the context of a particular type of information exchange between cooperating applications Figure 2 3-1 shows this relationship U Nearly all non-real-time applications interface to the layer below them in a connectionoriented manner making the dialog between the applications subject to security concerns Generally security will be provided by a sub-layer that operates below the application and applies security mechanisms to the communication In the Application Layer such security functionality is usually modeled as a discrete functional object rather than a sub-layer because same security mechanisms might be applied in different ways to different applications leading to layering inconsistencies Some security objects are generic and can offer service to multiple applications Others are tightly coupled to or embedded in the applications that they serve Like the applications themselves security objects exchange protocols with peer objects UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-10 UNCLASSIFIED FOR OFFICIAL USE ONLY End - system #1 End - system #2 Application Layer Application Layer Security Security Transport Layer Transport Layer Network Layer Network Layer Data Link Layer Data Link Layer Physical Layer Physical Layer This Figure is U 4095 Figure 2 3-1 U Context of Non Real-Time Application Security4 4096 4097 4098 4099 4100 4101 4102 4103 4104 4105 4106 4107 4108 4109 4110 4111 4112 4113 U Application security tailors the application of security techniques to the specific needs of the application This means that the security object can selectively apply security techniques differently to discrete fields or messages exchanged with the peer Security mechanisms can be applied selectively to specific fields using different keys for different fields to achieve different services This is superior in many regards such as better accommodating Cross Domain Solutions CDS by selectively leaving parts of the application data readable--or even unprotected--for use by CDS boundary protection devices U The concept of layered communications entails each layer operating semi-autonomously and adding its own additional protocol wrapper or control information to the data of the layer above it Figure 2 3-2 illustrates this concept The layer in question termed the n layer provides service to the layer above termed the n 1 layer since it is one layer higher and receives service from the layer below termed the n-1 layer Service is provided at the Service Access Point SAP for layer n also termed the n SAP To request service from the n layer the n 1 layer conceptually submits a request at the n SAP along with an Interface Data Unit IDU to support the request The IDU consists of a Service Data Unit SDU i e payload data from the n 1 layer and Protocol Control Information PCI associated with the requested n layer services 4 U Note that this figure uses the more commonly used OSI terminology for the layers but omits the Presentation and Session layers as in the Internet model because comparatively few applications in use today employ these layers UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-11 UNCLASSIFIED FOR OFFICIAL USE ONLY 4114 4115 4116 4117 4118 4119 4120 4121 o o o 4122 U A concrete example of this is an Application Programming Interface which typically consists of a calling address analogous to the n SAP and a convention for passing parameters analogous to the SDU and PCI The SDU and PCI passed to the n layer are used to formulate the SDU that is passed to the n-1 layer and thus the virtual Protocol Data Unit PDU exchanged with the n layer of a communicating peer end-system Security sub-layers or objects continue to follow this layered communication model Security objects provide service to the application above encapsulate the incoming SDU from the n 1 layer as part of the SDU that is passed down to the n-1 layer and incorporate some of the supplied PCI in the SDU and PCI that are passed down n 1 layer n SAP SDU PCI SDU PCI n layer PDU o o o n-1 layer n-1 SAP This figure is U 4123 4124 Figure 2 3-2 U Layered Protocol Wrapping Concept UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-12 UNCLASSIFIED FOR OFFICIAL USE ONLY 4125 4126 4127 4128 4129 4130 4131 4132 4133 4134 4135 4136 4137 4138 4139 U Engineering application security entails working through trade-offs among different choices of mechanisms used to provide the desired protection Application security usually contains embedded use of cryptography one-way functions and security protocols Cryptography is used to render selected portions of the application data unreadable to any entities not possessing the proper key material One-way functions are a class of mathematical operations that are elementary to perform but prohibitively difficult to reverse They are often used to embed irreversibility in application security operations Security protocols are the backbone of application security They define the data structures i e what to send and dialogs i e when to send it used to exchange information between the application security peer entities Protocols may resemble a simple one-way exchange or a complex conversation replete with security handshakes Security protocol design is crucial because most abstract security services e g integrity authentication are not possible except in a specific protocol context Design of the application security usually relies equally on all three of these types of mechanisms as part of an overall open system security solution Cryptography alone is not enough as a bad security protocol can hamper or compromise good cryptography 4149 2 3 3 2 1 1 1 U Traditional Application Security Technologies U Most development to date of application security has focused on so-called traditional layered technologies These are characterized by implementation of a standardized security element in the application layer with a strong relationship to and binding with the target application Such technology has been applied to many applications including message handling or electronic mail web hypertext and file transfer Development of security elements in this manner represents the old school of application security because doing so can require many years of standardization implementation and testing to realize workable secure solutions However considerable development of traditional application security has already taken place and it can be leveraged by the GIG 4150 2 3 3 2 1 1 1 1 U Technical Detail 4151 2 3 3 2 1 1 1 1 1 U Secure Messaging U Secure messaging is a good example of the evolutionary development of traditional layered application security technology Early messaging was based on Simple Mail Transfer Protocol SMTP and MSGFMT It offered ASCII-only messages without attachments security or other advanced features Many implementations of these messaging standards were created including most notably the SENDMAIL implementation which was bundled free with most UNIX implementations 4140 4141 4142 4143 4144 4145 4146 4147 4148 4152 4153 4154 4155 4156 4157 4158 4159 4160 4161 U The International Telegraph and Telephone Consultative Committee CCITT 5 entered the scene by developing its X 400 series of recommendations X 400 aimed to provide a fullfunction messaging system However the initial version of the X 400 released in 1984 contained no provision for security features 5 U CCITT has since reorganized into the International Telecommunications Union ITU Telecommunications Standardization Sector ITU-T UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-13 UNCLASSIFIED FOR OFFICIAL USE ONLY 4162 4163 4164 4165 4166 4167 4168 4169 4170 4171 4172 U As the U S government was becoming interested in X 400 as part of the developing Open Systems Interconnection OSI protocol stack NSA began development of the Message Security Protocol MSP as part of the Secure Data Network System SDNS MSP provided security to either X 400 or SMTP through the addition of a connectionless security protocol wrapper around the message content MSP evolved further as part of the Multilevel Information Systems Security Initiative MISSI and was eventually offered to the Allies as Allied Communications Publication ACP 120 CSP U ACP 120 is used in the presently deployed Defense Message System DMS The DMS implementation of ACP 120 works with the FORTEZZA card and the FORTEZZA Certificate Management Infrastructure CMI to provide encryption and digital signature for formal military messages When properly used ACP 120 is capable of providing the following security services 4173 o U Proof of Content Origin 4174 o U Proof of Content Receipt 4175 o U Content Confidentiality 4176 o U Content Integrity 4177 o U Common Security Protocol CSP Integrity 4178 o U Security Labeling 4179 o U Rules-based Access Control 4180 o U Secure Mail List Support 4181 4182 4183 4184 4185 4186 4187 4188 4189 4190 U While MSP was being developed and deployed CCITT was working on their security solution for X 400 This solution is today primarily described in X 400 X 402 and X 411 The X 400 security solution potentially offered all of the same services as CSP but offered too much flexibility and insufficient definition of necessary embedded security objects to suffice without additional profiling With the demise of OSI X 400 security has never achieved widespread implementation or deployment and is no longer a major factor in the evolution of secure messaging U With the wholesale abandonment of OSI and X 400 emphasis returned to providing security for SMTP and the recently standardized Multipurpose Internet Mail Extensions MIME Work began on the Privacy Enhanced Mail PEM project within the IETF UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-14 UNCLASSIFIED FOR OFFICIAL USE ONLY 4191 4192 4193 4194 4195 4196 4197 U While PEM ultimately failed6 it led to the private development of the Public Key Cryptographic Standard PKCS #7 PKCS7 and the Secure MIME S MIME development by RSA Data Security Inc An industry desire to expand the available choices of S MIME cryptography and achieve compatibility with MSP led to the development of S MIME v3 in the IETF The S MIME working group of the IETF has produced several proposed standards of note including CMS MSG CERT and ESS Like MSP S MIME v3 provides a wide range of security services including 4198 o U Proof of Content Origin 4199 o U Proof of Content Receipt 4200 o U Content Confidentiality 4201 o U Content Integrity 4202 o U S MIME Protocol Integrity 4203 o U Security Labeling 4204 o U Secure Mail List Support 4205 4206 4207 4208 4209 4210 4211 4212 4213 4214 4215 U Unlike some application security mechanisms the specification of the CMS is inherently designed to be a flexible and reusable module in the S MIME design It thereby has the potential to support other communications or non-communications applications This arrangement is illustrated in Figure 2 3-3 This situation already demonstrably exists in that the IETF Pubic Key Infrastructure X 509 PKIX working group has used CMS as the foundation for its successful Certificate Management Messages over CMS CMC protocol The IETF Long-Term Archive and Notary Services LTANS working group is planning to similarly use CMS as a foundation for their EvidenceRecord format CMS can and is similarly used locally for file encryption outside of the communication stack The inherent flexibility of this modular style of application security development has the potential to lead to expedited development of traditional layered application security elements in the future 6 U The failure of PEM had much to do with the conflicting requirements of the changing messaging environment at the time of its development Interested readers should also see the MIME Object Security Services MOSS enhancement of PEM UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-15 UNCLASSIFIED FOR OFFICIAL USE ONLY SMTP Server User Workstation TP SM ge ssa Me Application Layer PKIX CMC CA S MIME Client CMC Certificate Requestor CMS Engine Certificate Request LTANS Client LT Transport Layer Storage Subsystem AN S LT AP Evi den ce Re co LTANS Notary rd Network Layer This figure is U 4216 4217 Figure 2 3-3 U CMS Supports S MIME and Other Secure Applications 4218 U Another parallel track of secure messaging evolution is that of the Pretty Good Privacy PGP development PGP began as a piece of freeware code for file encryption with public keys Through the introduction of the PGP-MIME specification it also began to provide application security for SMTP MIME messaging The OpenPGP working group of the IETF is continuing to develop and advance PGP format and PGP-MIME as Internet standards PGP is not believed to be in use within DoD While not as capable as S MIME OpenPGP nevertheless remains a competitor in the marketplace OpenPGP is capable of providing the following security services 4219 4220 4221 4222 4223 4224 4225 o U Proof of Content Origin 4226 o U Content Confidentiality 4227 o U Content Integrity 4228 4229 4230 U The development and evolution of application security for message handling is a long story that is continuing to be written The widespread use of secure messaging both in DoD and industry will make it an important factor for the GIG for many years UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-16 UNCLASSIFIED FOR OFFICIAL USE ONLY 4231 4232 4233 4234 4235 4236 4237 4238 4239 4240 4241 4242 4243 4244 4245 4246 4247 4248 4249 4250 4251 4252 4253 4254 4255 4256 4257 4258 4259 4260 4261 4262 4263 4264 4265 4266 4267 2 3 3 2 1 1 1 1 2 U Web Security U Traditional layered application security technology has been applied to provide security for web browsing with the HyperText Transfer Protocol HTTP but have yielded only limited success This is not to be confused with Secure Sockets Layer SSL which is a different technology covered in Section 2 3 3 2 1 1 2 1 1 Salient examples of application security for web browsing include Secure HTTP S-HTTP and the IETF Web Distributed Authoring and Versioning WebDAV effort U The S-HTTP protocol extended the basic HTTP 1 1 protocol to provide mechanisms that can deliver strong authentication integrity and confidentiality While HTTPAuth provided a means for password and digest-based authentication and integrity for HTTP it failed to provide strong authentication or confidentiality S-HTTP defines its own URL protocol designator namely shttp 7 When a S-HTTP aware client or server detects a shttp URL it individually secures HTTP requests and responses while preserving the transaction model and implementation characteristics of HTTP The S-HTTP protocol provides flexibility in choice of cryptographic algorithms key management mechanisms and security policy by negotiating each option between the client and server Key exchange mechanisms include a password-style keying manually shared secret keys and public key The protocol has the capacity to use a variety of cryptographic message formats including CMS and MOSS While effective S-HTTP was never very successful as a technology S-HTTP is seldom used today U The IETF WebDAV working group is now taking another look at developing traditional application security for web transactions that are not well served by the simple SSL treatment of the application layer Web authoring as opposed to browsing has a strong emphasis on authentication access control and privileges The Distributed Authoring Protocol WebDAV built a framework for distributed authoring by standardizing HTTP extensions to support overwrite prevention locking metadata management properties and namespace management copy move collections The Access Control Protocol WebDAV-AC builds upon this to provide the means for a web client to read and modify access control lists ACLs that instruct a server whether to allow or deny operations upon a resource As implementation of List Based Access Control LBAC fundamentally requires authentication WebDAV-AC relies on existing authentication mechanisms defined for use with HTTP WebDAV-AC particularly specifies that if the basic authentication in HTTPAuth is used it must be performed over secure transport such as TLS WebDAV is still a relatively young developing standard and its support level in industry is still relatively low U On the whole traditional application security has not been very competitive for web security The ubiquitous support for SSL in web browsers has made a lot of past web security efforts irrelevant However the WebDAV effort appears to recognize the limits of SSL technology and is exploring richer application security features 7 U This should not be confused with https which signifies SSL TLS security UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-17 UNCLASSIFIED FOR OFFICIAL USE ONLY 4268 4269 4270 4271 4272 4273 4274 4275 4276 4277 4278 4279 4280 4281 4282 4283 4284 4285 4286 4287 4288 4289 4290 4291 4292 4293 4294 4295 4296 4297 4298 4299 4300 4301 4302 4303 4304 4305 4306 4307 2 3 3 2 1 1 1 1 3 U Strong Client Authentication U Several applications are known to employ traditional application security elements as part of their authentication design Some employ the reusable module philosophy already demonstrated for S MIME Applications known to do this include the Simple Authentication and Security Layer SASL the Post Office Protocol POP3 the Internet Message Access Protocol IMAP the Application Configuration Access Protocol ACAP and security extensions to the File Transfer Protocol FTP U Addition of strong client authentication has been a success from a standardization perspective However from an implementation and deployment standpoint the track record is spotty IMAP products commonly incorporate strong authentication However POP products still commonly rely on plaintext passwords ACAP products have been very slow to emerge overall but incorporate strong security where they exist FTP products incorporating strong authentication exist but are seldom used today 2 3 3 2 1 1 1 1 4 U Summary U As their widespread use demonstrates traditional layered application security technologies have a large footprint in industry and represent a mature stable development path However their maturity is offset by the long lead time associated with their evolution It is noteworthy though that a lot of this lead time is not profitless in that it allows interest and enthusiasm for the standard to build in the vendor community before the standard is finalized This can lead to improved standards and more widespread support among vendors Many application security protocols now also embrace a modular design philosophy such as employed by S MIME CMC and others which promises to shorten future development cycles 2 3 3 2 1 1 1 2 U Usage Considerations U Application security is generally highly tailored to the needs of the application in question Since the applications that will make up the GIG are necessarily a moving target it is difficult to provide a comprehensive overview of specific application security technologies that are of potential interest to the GIG community That type of analysis is best conducted within the framework of a particular project e g DMS GDS 2 3 3 2 1 1 1 3 U Maturity U Overall the traditional application security technology represents a mature foundation for GIG development Many application security standards have been developed Some have succeeded while others have failed Products for most widely-used applications offer at least some form of embedded application security today Secured application products are generally available functional reasonably secure interoperable and well tested However the maturity of specific application security varies dramatically S MIME security is widely available in mail clients Embedded strong IMAP authentication is likewise mature and dependable Toolkits are available to facilitate rapid integration of many technologies into existing or new product developments However other more negative examples such as strong POP3 authentication and S-HTTP also exist Thus the maturity of the different individual technologies must be assessed individually UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-18 UNCLASSIFIED FOR OFFICIAL USE ONLY 4308 4309 4310 2 3 3 2 1 1 1 4 U Standards U Table 2 3-1 summarizes pertinent application and traditional application security standards discussed in this section Table 2 3-1 U Traditional Layered Application Security Standards 4311 This table is U Reference Forum SMTP MSGFMT IETF IETF PEM IETF IETF IETF IETF MOSS IETF CMS IETF MSG IETF CERT IETF ESS IETF IETF IETF IETF CMC IETF HTTP IETF HTTPAuth IETF S-HTTP IETF Standards Date Maturity RFC 821 Simple Mail Transfer Protocol RFC 822 Standard for the Format of ARPA Internet Text Messages RFC 1421 Privacy Enhancement for Internet Electronic Mail Part I Message Encryption and Authentication Procedures RFC 1422 Privacy Enhancement for Internet Electronic Mail Part II Certificate-Based Key Management RFC 1423 Privacy Enhancement for Internet Electronic Mail Part III Algorithms Modes and Identifiers RFC 1424 Privacy Enhancement for Internet Electronic Mail Part IV Key Certification and Related Services RFC 1848 MIME Object Security Services RFC 3852 Cryptographic Message Syntax CMS RFC 3851 S MIME v3 1 Message Specification RFC 3850 S MIME v3 1 Certificate Handling RFC 2634 Enhanced Security Services for S MIME RFC 3854 Securing X 400 Content with S MIME RFC 3855 Transporting S MIME Objects in X 400 RFC 3370 CMS Algorithms August 1982 August 1982 Standard Standard February 1993 Proposed Standard February 1993 Proposed Standard February 1993 Proposed Standard February 1993 Proposed Standard October 1995 RFC 2797 Certificate Management Messages over CMS RFC 2616 Hypertext Transfer Protocol - HTTP 1 1 RFC 2617 HTTP Authentication Basic and Digest Access Authentication RFC 2660 The Secure HyperText Transfer Protocol April 2000 June 1999 Proposed Standard Proposed Standard Proposed Standard Proposed Standard Proposed Standard Proposed Standard Proposed Standard Proposed Standard Proposed Standard Draft Standard June 1999 Draft Standard August 1999 Experimental July 2004 July 2004 July 2004 June 1999 July 2004 July 2004 August 2002 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-19 UNCLASSIFIED FOR OFFICIAL USE ONLY This table is U Reference Forum WebDAV IETF WebDAVAC SASL IETF IETF IETF IETF POP3 IETF IETF IETF Standards Date RFC 2518 HTTP Extensions for Distributed Authoring -- WEBDAV RFC 3744 WebDAV Access Control Protocol RFC 2222 Simple Authentication and Security Layer SASL RFC 2444 The One-Time-Password SASL Mechanism RFC 2554 SMTP Service Extension for Authentication RFC 1939 Post Office Protocol Version 3 RFC 2449 POP3 Extension Mechanism February 1999 May 2004 October 1997 October 1998 March 1999 May 1996 November 1998 December 1994 IETF RFC 1734 POP3 AUTHentication command RFC 3206 The SYS and AUTH POP Response Codes RFC 3501 Internet Message Access Protocol IMAP - Version 4rev1 RFC 2195 IMAP POP AUTHorize Extension for Simple Challenge Response RFC 1731 IMAP4 Authentication Mechanisms RFC 2086 IMAP4 ACL extension January 1997 IETF RFC 2228 FTP Security Extensions October 1997 ACAP IETF X 400 ITU-T November 1997 June 1999 X 402 ITU-T X 411 ITU-T MSP CSP NSA CCEB RFC 2244 Application Configuration Access Protocol X 400 Information Technology - Message Handling Systems MHS - Message Handling System and Service Overview X 402 Information Technology - Message Handling Systems MHS - Overall Architecture X 411 Information Technology - Message Handling Systems MHS - Message transfer system Abstract Service Definition and Procedures SDN 701 Message Security Protocol ACP 120 Common Security Protocol CSP IETF IMAP4 IETF IETF IETF February 2002 March 2003 September 1997 December 1994 Proposed Standard Proposed Standard Proposed Standard Proposed Standard Proposed Standard Standard Proposed Standard Proposed Standard Proposed Standard Proposed Standard Proposed Standard Proposed Standard Proposed Standard Proposed Standard Proposed Standard Final Recomm June 1999 Final Recomm June 1999 Final Recomm June 1996 June 1998 v4 0 Base Edition UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-20 Maturity UNCLASSIFIED FOR OFFICIAL USE ONLY This table is U Reference PKCS7 4312 4313 4314 4315 4316 Forum RSA Standards PKCS #7 Cryptographic Message Syntax Standard This table is U Date November 1993 Maturity v1 5 2 3 3 2 1 1 1 5 U Dependencies U Traditional application security technologies rely extensively on cryptographic technologies to provide encryption digital signature hash and key exchange algorithms U Protocol development is a key enabling technology for traditional application security At present the dominant techniques rely on the following technologies 4317 o U Object-oriented design based on modeling in Abstract Syntax Notation One ASN 1 4318 o U Syntactic description using Augmented Backus-Naur Format ABNF 4319 o U Description of eXtensible Markup Language XML syntax using XML-Schema techniques 4321 o U Formal system state analysis and modeling 4322 o U Other formal techniques 4320 4323 4324 U These combined with a liberal application of English descriptive and ad-hoc techniques form a necessary part of application security development UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-21 UNCLASSIFIED FOR OFFICIAL USE ONLY 4333 2 3 3 2 1 1 2 U Session Security Technologies U As an alternative to developing application security many applications choose to rely on session security technology Session security technology protects all user data passed over a virtual connection between peer applications Implementation of session security technology varies and can be modeled variously as part of the application layer or part of the transport layer Session security technologies afford many of the same protections to user information but with reduced flexibility and perhaps often with less permanence Session security technologies are however vastly simpler than traditional layered application security and frequently offer rapid integration via exposed APIs 4334 2 3 3 2 1 1 2 1 U Technical Detail 4335 2 3 3 2 1 1 2 1 1 U Secure Sockets Layer Transport Layer Security U The Secure Sockets Layer began as a proprietary technology developed by Netscape SSL provided an extension to the popular Berkeley Sockets and Windows Sockets API to allow applications to invoke security services provided by a common encapsulation protocol Initially SSL was developed to service HTTP exclusively Eventually it began to be used by broader range of applications 4325 4326 4327 4328 4329 4330 4331 4332 4336 4337 4338 4339 4340 4341 4342 4343 4344 4345 4346 4347 4348 4349 4350 4351 4352 4353 U As SSL use became widespread an effort was made to open the protocol and API definition to industry This led to the development of the Transport Layer Security TLS standard in the IETF TLS v1 0 is based on the SSL v3 0 but the two protocols do not interoperate TLS implementations can however fall back to SSL 3 0 during negotiation TLS v1 0 offers more flexibility in features and cryptography than SSL v3 0 and is expected to be the platform for all future evolution and development of the technology U TLS works by using the TLS Record Protocol to fragment data into manageable blocks Each block has a MAC code applied is optionally encrypted and the resulting block is transmitted via TCP Record Protocol might also compress the fragmented data--depending on the specific implementation TLS uses the Record Protocol as a foundation for different types of protocol exchanges The basic TLS specification defines four record types Additional record types are supported as an extension mechanism The following types are defined o U Handshake Protocol - Enables mutual establishment of identity between the client and server and for negotiation of TLS options o U Alert Protocol - Conveys information about important events in the communication such as normal closure of the association and errors o U Change Cipher Spec Protocol - Enables the client and server to signal and mutually acknowledge transitions in ciphering strategies o U Application Data Protocol - Conveys the fragmented compressed and encrypted application data Messages are treated as transparent data 4354 4355 4356 4357 4358 4359 4360 4361 4362 4363 U Although three of these protocols are quite simple the TLS Handshake Protocol uses several staged exchanges Figure 2 3-4 illustrates the context and operation of TLS and the Handshake Protocol UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-22 UNCLASSIFIED FOR OFFICIAL USE ONLY Client Server TLS Handshake Protocol ClientHello ServerHello Certificate ServerKeyExchange CertificateRequest ServerHelloDone Certificate ClientKeyExchange CertificateVerify ChangeCipherSpec Finished ChangeCipherSpec Finished Application Data Application Layer SDU TLS TCP Transport Layer Network Layer This figure is U 4364 Figure 2 3-4 U TLS Handshake Protocol 4365 4366 U The TLS Handshake Protocol involves the following steps o U Exchange hello messages to agree on algorithms exchange random values and check for session resumption o U Exchange the necessary cryptographic parameters to allow the client and server to agree on a pre-master secret o U Exchange certificates and cryptographic information to allow the client and server to authenticate themselves 4373 o U Generate a master secret from the pre-master secret and exchanged random values 4374 o U Provide security parameters to the record layer 4375 o U Allow the client and server to verify that their peer has calculated the same security parameters and that the handshake occurred without tampering 4367 4368 4369 4370 4371 4372 4376 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-23 UNCLASSIFIED FOR OFFICIAL USE ONLY 4377 4378 4379 4380 4381 4382 4383 4384 U While the average user experience with TLS has mainly to do with confidentiality and integrity the protocol is capable of strong mutual authentication Authentication is only as strong as the Public Key Infrastructure PKI underlying the certificates issued to the client and server While TLS-enabled servers commonly have certificates issued for their domains most web browser implementations using TLS do not Such browsers commonly establish an anonymous but encrypted association with the TLS server and then perform basic authentication within that virtual circuit in accordance with HTTPAuth When properly provisioned with certificates TLS is capable of providing the following security services to an application 4385 o U Authentication of Server Identity 4386 o U Authentication of Client Identity 4387 o U Data Confidentiality 4388 o U Data Integrity 4389 U TLS has been successfully applied to several different applications including 4390 o U HTTP see HTTPTLS 4391 o U LDAPv3 see LDAPAuth and LDAPTLS 4392 o U POP see RFC 2595 4393 o U IMAP see RFC 2595 4394 o U ACAP see RFC 2595 4395 o U SMTP see SMTPTLS 4396 4397 4398 4399 4400 4401 4402 4403 4404 4405 4406 4407 2 3 3 2 1 1 2 1 2 U Generic Upper Layer Security U In the early 1990s the International Organization for Standardization ISO and International Telecommunication Union Telecommunication Standardization Sector ITU-T began to recognize a gap between the requirements for applications security set forth in CCITT X 800 ISO IEC 7498-2 see OSISecArc and ITU-T X 803 ISO IEC 10745 see ULSecMode and the practice of building security into individual applications from scratch This realization led eventually to the development of the Generic Upper Layer Security GULS standards GULS provided a set of standardized ASN 1 conventions to facilitate development of secure application syntaxes It also defined a Security Exchange Service Element SESE which would establish and maintain a secure association over which application data could be exchanged securely The SESE would function somewhat similarly to TLS Unlike TLS GULS was unambiguously modeled in the application layer and was distinct from OSI transport layer security standards UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-24 UNCLASSIFIED FOR OFFICIAL USE ONLY 4408 4409 4410 4411 4412 4413 4414 4415 4416 4417 4418 4419 4420 4421 4422 4423 4424 4425 4426 4427 4428 4429 4430 4431 4432 4433 4434 4435 4436 4437 4438 4439 U Unfortunately GULS was of little value to existing OSI applications e g X 400 and X 500 without modification Also since GULS was unambiguously wedded to ASN 1 and the OSI application layer structures it was only of value to OSI applications The total collapse of interest in OSI development in the mid-1990s virtually eliminated any work on new OSI applications or updates to existing applications These factors have combined to make GULS virtually irrelevant today 2 3 3 2 1 1 2 1 3 U Summary U Session security technologies provide a very simple and potent solution for securing application communication The development of TLS has proven extremely effective on widespread deployments and has been applied to a variety of applications However there are a number of limitations and security concerns on use of TLS for application security GULS is of little present-day interest but the similarity of evolution between GULS and TLS is noteworthy from the perspective of examining session security technologies as a whole 2 3 3 2 1 1 2 2 U Usage Considerations U Caution should be exercised in employing session security technologies such as TLS for application security purposes The suitability of TLS depends heavily on it functioning in an overall security architecture For example TLS can be subjected to man-in-the-middle attacks So care must be taken that strong 2-way authentication is applied during the Handshake Protocol and that certificates or other credentials are validated and recognized This is true even if subsequent access control based on HTTPAuth with be used within the TLS association TLS is also vulnerable to compromise of its feature negotiation mechanisms So care must be taken to ensure that the implementation minimum acceptable security measures reflect the security policy in force TLS is also not suitable for application architectures that require secure multipoint communications multiple different application entities or architectures that require persistent security that endures through a relaying application entity 2 3 3 2 1 1 2 3 U Maturity U Session security technologies are Mature TRLs 7 - 9 and TLS in particular is a Mature widely implemented and well deployed solution It is worth noting that most TLS client implementations operate without certificates or public keys by default Most are not easily configurable to employ a per-application certificate much less a per-user certificate Therefore it seems likely that more product improvement must take place for TLS to expand beyond web browsing and properly provide security to multiple applications UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-25 UNCLASSIFIED FOR OFFICIAL USE ONLY 4440 4441 2 3 3 2 1 1 2 4 U Standards U Table 2 3-2 summarizes pertinent session security standards discussed in this section Table 2 3-2 U Session Security Standards 4442 This table is U Reference Forum Standards Date TLS IETF RFC 2246 The TLS Protocol v1 0 January 1999 HTTPTLS IETF May 2000 TLSEXT IETF IETF RFC 2817 Upgrading to TLS Within HTTP 1 1 RFC 2818 HTTP Over TLS RFC 3546 TLS Extensions May 2000 June 2003 AESTLS IETF RFC 3268 AES Ciphersuites for TLS June 2002 LDAPAuth IETF May 2000 LDAPTLS IETF RFC 2829 Authentication Methods for LDAP RFC 2830 LDAPv3 Extension for TLS LDAPv3 IETF RFC2595 IETF September 2002 June 1999 SMTPTLS IETF GULS ISO RFC 3377 LDAP v3 Technical Specification RFC 2595 Using TLS with IMAP POP3 and ACAP RFC 3207 SMTP Service Extension for Secure SMTP over TLS ISO IEC 11586-1 Information technology -- Open Systems Interconnection -- Generic upper layers security Overview models and notation ISO IEC 11586-2 Information technology -- Open Systems Interconnection -- Generic upper layers security Security Exchange Service Element SESE service definition ISO IEC 11586-3 Information technology -- Open Systems Interconnection -- Generic upper layers security Security Exchange Service Element SESE protocol specification ISO IEC 11586-4 Information technology -- Open Systems Interconnection -- Generic upper layers security Protecting transfer syntax specification ISO ISO ISO May 2000 February 2002 1996 Proposed Standard Proposed Standard Informational Proposed Standard Proposed Standard Proposed Standard Proposed Standard Proposed Standard Proposed Standard Proposed Standard International Standard 1996 International Standard 1996 International Standard 1996 International Standard UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-26 Maturity UNCLASSIFIED FOR OFFICIAL USE ONLY This table is U Reference Forum ISO ISO OSISecArch ISO ULSecModel ISO OSISecArch ITU-T ULSecModel ITU-T GULS ITU-T ITU-T ITU-T Standards ISO IEC 11586-5 Information technology -- Open Systems Interconnection -- Generic upper layers security Security Exchange Service Element SESE Protocol Implementation Conformance Statement PICS proforma ISO IEC 11586-6 Information technology -- Open Systems Interconnection -- Generic upper layers security Protecting transfer syntax Protocol Implementation Conformance Statement PICS proforma ISO IEC 7498-2 Data Communication Networks - Open Systems Interconnection OSI - Security Structure and Applications - Security Architecture for Open Systems Interconnection for CCITT Applications ISO IEC 10745 Information Technology - Open Systems Interconnection - Upper Layers Security Model CCITT X 800 Data Communication Networks - Open Systems Interconnection OSI - Security Structure and Applications - Security Architecture for Open Systems Interconnection for CCITT Applications ITU-T X 803 Information Technology - Open Systems Interconnection - Upper Layers Security Model ITU-T X 830 Information technology -Open Systems Interconnection -Generic upper layers security Overview models and notation ITU-T X 831 Information technology -Open Systems Interconnection -Generic upper layers security Security Exchange Service Element SESE service definition ITU-T X 832 Information technology -Open Systems Interconnection -Generic upper layers security Security Exchange Service Element SESE protocol specification Date 1997 International Standard 1997 International Standard 1989 International Standard July 1994 International Standard 1991 Final Recomm July 1994 Final Recomm April 1995 Final Recomm April 1995 Final Recomm April 1995 Final Recomm UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-27 Maturity UNCLASSIFIED FOR OFFICIAL USE ONLY This table is U Reference Forum ITU-T ITU-T ITU-T 4443 4444 4445 Standards ITU-T X 833 Information technology -Open Systems Interconnection -Generic upper layers security Protecting transfer syntax specification ITU-T X 834 Information technology -Open Systems Interconnection -Generic upper layers security Security Exchange Service Element SESE Protocol Implementation Conformance Statement PICS proforma ITU-T X 835 Information technology -Open Systems Interconnection -Generic upper layers security Protecting transfer syntax Protocol Implementation Conformance Statement PICS proforma This table is U Date Maturity April 1995 Final Recomm October 1996 Final Recomm October 1996 Final Recomm 2 3 3 2 1 1 2 5 U Dependencies U Neither cryptography nor security protocol development are discussed in detail in this section However session security technologies have a similar dependency on them UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-28 UNCLASSIFIED FOR OFFICIAL USE ONLY 4446 4447 4448 4449 4450 4451 4452 4453 4454 4455 4456 4457 4458 4459 4460 4461 4462 4463 4464 4465 4466 4467 4468 4469 4470 4471 4472 4473 4474 2 3 3 2 1 1 3 U Web Services Security Technologies U The future of application development for the GIG is expected to take a different direction from past application layer development The emphasis for GIG applications is expected to be service-oriented architectures And the primary focus for service-oriented application development is the technology known as Web Services Unfortunately development security technology for Web Services is still in its infancy 2 3 3 2 1 1 3 1 U Technical Detail U With the tremendous success of web browsing as the Internet's second killer application pressure grew to leverage the success and ubiquity of the web for other purposes Recognition also dawned that while HTTP servers and dynamically generated HTML documents were sufficient to allow humans users basic access to databases they were not sufficient to enable automated systems to access information in those same databases This was a function of HTML being optimized for specifying presentation rather than semantics This led to the development of the XML which was optimized instead for identifying the semantics of data U In the late 1990s the Simple Object Access Protocol SOAP was developed as a means to allow XML objects to be requested and transferred over HTTP or a variety of other protocols SOAP provides an XML envelope consisting of a heading and body The specification in SOAP provides bindings between SOAP and HTTP so that SOAP transactions can take advantage of the existing ubiquitous HTTP infrastructure Other bindings such as to SMTP or other existing protocols are also possible but seldom seen Services built to request and delivery specific data using XML and SOAP have come to be known as Web Services U Developing security services as a common add-on to the web services framework offer significant benefits over traditional layered application security development Figure 2 3-5 contrasts the web services model with that shown previously for CMS and S MIME In the web services framework a variety of service offerings can be provided through SOAP and HTTP Each service would benefit from the same security elements applied to the common SOAP envelope This form of security is called Web Services Security WSS Conceptually WSS has much in common with a reusable module such as CMS or session security services such as TLS However WSS has the potential to combine the best elements of both UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-29 UNCLASSIFIED FOR OFFICIAL USE ONLY Web Services Client Service Offerers Application Layer AP SO Tr n tio ac s an WSS saction SOAP Tran SOAP SO AP T Transport Layer ran sac tion Network Layer This figure is U 4475 4476 4477 4478 4479 4480 4481 4482 4483 4484 4485 4486 4487 4488 4489 4490 4491 4492 4493 Figure 2 3-5 U Model for Web Services Security U Different organizations are involved in developing standards and specifications for WSS The World Wide Web Consortium W3C the organization responsible for the original development of both XML and SOAP has contributed to the development of WSS by introducing the XML Digital Signature XML_DSIG and XML Encryption XML_ENC standards These have the potential to become foundation standards for more advanced WSS development In competition with the W3C standards is the work of the American National Standards Institute ANSI ANSI has developed an XML Cryptographic Message Syntax XCMS which provides functions similar to XML_DSIG and XML_ENC but does so by applying a relatively simple XML wrapper to the existing IETF CMS wrappers It is unclear at this point which approach will dominate U The Organization for the Advancement of Structured Information Standards OASIS is developing several standards that have the promise to contribute to WSS These include SAML XACML and WSS U Another significant WSS development is under way at the Web Services Interoperability WS-I Organization WS-I is engaged in an effort to achieve commonality and interoperability among web service components WS-I has already released the WS-I Basic Profile for web services and is continuing work on a draft Basic Security Profile for WSS UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-30 UNCLASSIFIED FOR OFFICIAL USE ONLY 4494 4495 4496 4497 4498 4499 U Another contender in the WSS area is Liberty Alliance They are focused on solving the problem of cooperation between federated web services to provide secure operation where all of the participants may not be part of the same organization or necessarily share a common security policy It is unclear how the Liberty Alliance work will ultimately affect the overall WSS effort Liberty Alliance has released three sets of standards that promise to have an impact on WSS o U The Identity Federation Framework ID-FF offers an approach for establishing a standardized multi-vendor web-based SSO with federated identities based on commonly deployed technologies o U The Identity Web Services Framework ID-WSF is a set of specifications for creating using and updating various aspects of identities o U The Identity Services Interface Specifications ID-SIS define profiles for commonly useful services including a personal profile service ID-SIS-PP that provides basic profile information such as contact information and an employee profile service ID-SISEP that provides Employee's basic profile information 4500 4501 4502 4503 4504 4505 4506 4507 4508 4509 4510 4511 4512 4513 4514 4515 4516 2 3 3 2 1 1 3 2 U Maturity U WSS standards are Emerging TRLs 4 - 6 They are still under development and are not ready for full scale deployment Further there are different standards competing for many of the same functional requirements It is not clear at this point which standards will succeed and in what market segments It is possible that some security standards will prove to be suited to certain types of web service while others will better support different forms of web service So there is considerable risk in early adoption of any of these immature solutions 2 3 3 2 1 1 3 3 U Standards U Table 2 3-3 summarizes pertinent web services security standards discussed in this section Table 2 3-3 U Web Services Security Standards 4517 This table is U Reference XML Forum W3C XML-DSIG XML-ENC SOAP SAML XACML OASIS Standards Date XML XML Schema XML-DSIG XML-ENC XKMS SOAP WSDL SAML XACML UDDI SPML XCBF Maturity Final Stable Final Final Revision Revision Revision Stable Revision Revision Stable Final UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-31 UNCLASSIFIED FOR OFFICIAL USE ONLY This table is U Reference Forum WSS WSI-SEC WS-I ANSI XCMS ID-FF ID-SIS ID-WSF 4518 4519 4520 4521 4522 ITU-T ISO Liberty Alliance Standards Date XCBF Token Profile Web Services Security WSS WSS UsernameToken Profile WSS X 509 Certificate Token Profile Web Services Reliable Messaging ebXML Registry ebSOA WSDM XrML eXtensible Rights Management Language Web Application Security Digital Signature Services Security Services Web Services Distributed Management Basic Security Profile Security Scenarios Basic Profile ANSI X9 84 XCBF ANSI X9 96 XCMS ANSI X9 73 CMS ITU-T X 509 ISO 19092 biometric formats ID-FF ID-SIS ID-WSF draft-lib-arch-soap-authn This table is U Maturity Final Revision Revision Revision Draft Draft Draft Revision Final Draft Stable Revision Revision Draft 2 3 3 2 1 1 3 4 U Dependencies U Neither cryptography nor security protocol development are discussed in detail in this section However web services security technologies have a similar dependency on them It should be noted that web services' exclusive focus on SOAP and XML narrow the range of techniques used in security protocol development UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-32 UNCLASSIFIED FOR OFFICIAL USE ONLY 4523 2 3 3 2 1 2 U Real-Time Data Technologies 4524 2 3 3 2 1 2 1 U FNBDT 4525 2 3 3 2 1 2 1 1 U Technical Detail U Future Narrowband Digital Terminal FNBDT is a group of signaling and cryptography specifications designed to allow end-to-end secure communications using commercial communications channels FNBDT operates at the Application Layer see Figure 2 3-6 and is designed to operate over whatever transport method is available 4526 4527 4528 4529 FNBDT Voice Data Encryption Layer 7 - Application Fragmentation Layer 6 - Presentation Reliable Transport Layer 5 - Session Framing Layer 4 - Transport Layer 3 - Network Layer 2 - Data Link This figure is U FOUO Layer 1 - Physical 4530 Figure 2 3-6 U FNBDT Location in Network Protocol Stack 4531 4532 4533 U FOUO FNBDT specifications define the following aspects of secure voice and data communication o U FOUO The signaling required to establish and maintain secure calls independent of the transport network o U FOUO A Minimum Essential Requirement MER mode which guarantees interoperability between FNBDT-compliant devices 4538 o U FOUO Key management for generating and maintaining compatible encryption keys 4539 o U Encryption algorithms 4540 o U FOUO MELP 2400 bps and G 729D 6400 bps voice coders 4541 o U FOUO Cryptographic synchronization management functionality 4542 o U FOUO An escape mechanism enabling venders to implement proprietary modes 4534 4535 4536 4537 4543 4544 4545 U FOUO Currently the FNBDT specifications specify only Type 1 encryption methods although the signaling is directly applicable to vendor-defined non-Type 1 applications Multiple vendors have introduced Type 1 and non-Type 1 products based on the FNBDT specifications UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-33 UNCLASSIFIED FOR OFFICIAL USE ONLY 4550 U FOUO FNBDT provides the ability for products to operate in high Bit Error Rate BER environments Establishing an FNBDT channel involves an initial negotiation of capabilities between endpoints with the ability to select vendor proprietary modes if both endpoints have compatible capabilities Compatible operational modes encryption algorithms and key sets are also selected during this initial exchange 4551 2 3 3 2 1 2 1 2 U Usage Considerations 4552 2 3 3 2 1 2 1 2 1 U Implementation Issues U FOUO The FNBDT signaling protocol at the Application Layer has proved to be a successful method of providing security for voice systems While the FNBDT protocol is not oriented toward a packet-based system it does not inherently prohibit operating with such a system FNBDT is a streaming protocol that defines a constant-rate bitstream For voice applications this bitstream is either 2400 bps or 7200 bps As long as the receiving end of the communication link can receive the bits and reformat them into the same constant-rate bitstream that was presented to the network at the transmit end of the link the FNBDT signaling protocol will be adequate for secure voice applications 4546 4547 4548 4549 4553 4554 4555 4556 4557 4558 4559 4560 4561 4562 4563 4564 4565 4566 4567 4568 4569 4570 4571 4572 4573 4574 4575 4576 4577 4578 4579 4580 4581 U Packet-based transport systems present unique challenges for streaming protocols such as FNBDT The following list identifies several sources of degradation introduced by packet-based systems and evaluates the tolerance of the FNBDT signaling protocol to these degradation sources U FOUO Packet latency This refers to the network delay in transporting bits from one end to the other Two-way real-time applications such as voice conversations are negatively affected by total delay times that are perceptible to the user typically in the 0 5 sec range Because there are other sources of delay in the system besides packet transport time the delay introduced by packet transport must be significantly less than this The FNBDT protocol is not inherently affected by increased packet latency although of course the regenerated speech at the receiving end of the link will be delayed accordingly U FOUO Packet jitter Packet jitter refers to the difference in time required to transport packets as opposed to the absolute delay packet latency Streaming protocols such as FNBDT are required to maintain a constant-rate output even when the network transport mechanism results in packets arriving at different times This is typically resolved by buffering at the receive end of the link Packets are fed into the buffer at varying times as they arrive but are read out of the buffer at the constant streaming rate required by the application a process shown in Figure 2 3-7 The buffer must be able to accommodate the largest potential jitter and therefore the net result of this arrangement is that the received signal is delayed enough to account for the largest potential jitter This delay is in addition to the delay introduced by packet latency As with packet latency the FNBDT protocol is not inherently affected by increased jitter UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-34 UNCLASSIFIED FOR OFFICIAL USE ONLY Bursty Input Buffer length Expected Packet Jitter Buffer Average Buffer Latency 1 2 Buffer Length Constant Rate Output This figure is U 4582 4583 Figure 2 3-7 U Packet Jitter Mitigation Process 4584 U Packet loss Packets may be lost during the transport process resulting in missing data at the receiver In the case of secure applications missing data invariably leads to loss of cryptographic synchronization Any subsequent data received and decrypted will be garbled until cryptographic synchronization is re-established This potentially devastating situation is mitigated by the FNBDT signaling protocol which includes embedded cryptographic synchronization information periodically in the transmitted bitstream This cryptographic re-synchronization information occurs every 320 msec for G 729D speech and every 540 msec for MELP speech The potential impact of individual lost packets is therefore a short 0-500 msec section of garbled speech during a conversation Periods of sequential lost packets will result in appropriately long periods of missing or garbled speech with a 0-500 msec period for reestablishing cryptographic synchronization when the packets begin arriving again 4585 4586 4587 4588 4589 4590 4591 4592 4593 4594 4595 4596 4597 4598 4599 4600 4601 4602 4603 4604 4605 4606 4607 4608 4609 4610 4611 4612 U Packet re-ordering Some packet transport systems have the capability to use different paths for transporting packets resulting in the potential for packets to arrive out of order Often the transport system has the capability to rearrange the received packets to the correct order before presenting them to the upper layers resulting in packet jitter rather than actual ordering errors in the bitstream If however information is presented to an FNBDT receiver with segments out of order the out-of-order segments will result in random garbled information The length of any such garbled data will depend on the packet size Since speech applications will likely keep packets small in order to reduce latency the period of speech degradation will likewise be small Packet re-ordering issues lead to cryptosync loss with appropriate recovery periods as described in the previous paragraph U FOUO Packet bit-errors Uncorrected bit errors within transmitted packets will have the same effect as bit errors in a circuit switched network The FNBDT protocol was designed for relatively high bit-error rate environments 2% and includes automatic retransmission capabilities for those portions of the signaling which must arrive error-free Once a secure call is established the speech algorithms themselves are extremely tolerant to random bit errors Individual bit errors seldom result in noticeable degradation to the received speech FNBDT traffic modes use crypto methods that do not result in bit error extension meaning that single bit errors in the received ciphertext do not extend to multiple bit errors in the decrypted plaintext UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-35 UNCLASSIFIED FOR OFFICIAL USE ONLY 4613 4614 4615 4616 4617 4618 4619 4620 4621 4622 4623 4624 4625 2 3 3 2 1 2 1 2 2 U Advantages U FOUO FNBDT is an end-user to end-user protocol Information is encrypted at the transmitting end-user where traffic is generated and is never decrypted until it arrives at the receiving end-user where the traffic is consumed User data is protected through whatever network and across whatever communication channels might be traversed Where gateways are required to deliver bits from one protocol stack to another e g VoIP to PSTN user data remains encrypted as it traverses the gateway U FOUO The FNBDT protocol provides inherent transport reliability Ack Nak with retransmission for signaling messages Voice modes operate without any underlying retransmission protocol to reduce latency Data modes are defined with and without retransmission to allow increased throughput Guaranteed Throughput mode or increased reliability Reliable Transport mode as required for specific applications The frame structure for signaling transport reliability and Reliable Transport data mode is shown in Figure 2 3-8 FNBDT Capabilities Message shown as example 2 MID message 2 2 message message length version 1 1 8 2 2 Init neg Sig Plan version ID Oper modes length 1'st Oper mode 0x0002 1 reliable transport block count n 13 2 CRC 4 1 FEC block count n 1 2 2 Keysets 1st length keyset type 13 2 CRC 2 3 1st keyset length 1 1st keyset parameters UID CKL ver 4 1 FEC block count n 2 13 11 2 pad 0 CRC 4 FEC 13- octet block 20-octet FNBDT frame 8 min 60 8 SOM Capabilities EOM framing FNBDT frame group This figure is U FOUO 4626 4627 4628 4629 4630 4631 4632 4633 Figure 2 3-8 U FOUO FNBDT Frame Structure for Signaling Reliability and Reliable Transport Data Mode U FOUO An inherent strength of the FNBDT protocol is its ability to maintain cryptographic synchronization for secure voice applications throughout signal fading and high BER environments Without this ability the application data would continually need to be interrupted to resynchronize the cryptography as data is lost or corrupted leading to annoying gaps and artifacts in encrypted speech UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-36 UNCLASSIFIED FOR OFFICIAL USE ONLY 4634 4635 4636 4637 4638 4639 4640 4641 U FOUO Synchronization is accomplished by periodically embedding information in the transmitted bitstream This allows the receiver to resynchronize the cryptography without using channel resources other than the periodic embedded information When the MELP vocoder has been selected the FNBDT specifications define both a Blank and Burst mode where cryptographic resynchronization information replaces every 24th vocoder frame as indicated in Figure 2 3-9 and a Blank without Burst mode where all vocoder frames are transmitted The Blank and Burst mode results in no additional overhead for the embedded resync information which occur every 540 msec and results in a composite bitstream of 2400 bps 54 54 54 54 54 54 Sync Mgt Encrypted Speech Frame #1 Encrypted Speech Frame #2 Encrypted Speech Frame #3 Encrypted Speech Frame #22 Encrypted Speech Frame #23 54 54 MELP frame MELP frame 22 5 msec speech 22 5 msec speech Two MELP frames per codebook cycle 16 16 14 8 PN Partial Long Component Short Component CRC 0x7AC8 4642 This figure is U FOUO 4643 Figure 2 3-9 U FOUO FNBDT 2400 bps MELP Blank and Burst Superframe Structure 4644 U FOUO When the G 729D vocoder has been selected cryptographic resynchronization information is inserted every 8th vocoder frame as shown by Figure 2 3-10 This allows the cryptography to resynchronize every 320 msec and results in a composite bitstream of 7200 bps 4645 4646 64 280 280 280 Sync Mgt Encrypted Speech Fram e #1 Encrypted Speech Fram e #2 Encrypted Speech Fram e #3 16 8 PN 280 280 Encrypted Speech Fram e #7 Encrypted Speech Frame #8 64 64 64 64 G 729D fram e G 729D fram e G 729D fram e G 729D fram e 10 m sec speech 10 m sec speech 10 m sec speech 10 m sec speech 0x5E26 Low-order 8 bits of Short Com ponent corresponding to following codebook cycle 16 16 14 PN Partial Long Component Short Com ponent 0x7AC8 4647 4648 4649 4650 2 8 8 CRC Pad Two G 729D frames per codebook cycle This figure is U FOUO 0x00 PLC Count Figure 2 3-10 U FOUO FNBDT 7200 bps G 729D Superframe Structure U FOUO FNBDT is particularly useful in high BER environments where channels are likely to fade and where low latency real-time encrypted speech and data applications are required UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-37 UNCLASSIFIED FOR OFFICIAL USE ONLY 4651 4652 4653 4654 4655 4656 4657 4658 4659 4660 4661 4662 4663 4664 4665 4666 4667 4668 4669 4670 4671 4672 4673 U FOUO The FNBDT protocol is transport-independent in that it is designed to operate over whatever lower-layer protocols might be available Within constraints applicable to specific applications timeouts speech delay etc the FNBDT protocol can operate over any channel capable of transporting bits between two end-user terminals FNBDT terminal vendors have implemented products utilizing PSTN ISDN GSM CDMA Iridium satellite digital radio and other channel types for data transport 2 3 3 2 1 2 1 2 3 U FOUO Risks Threats Attacks U FOUO Since the FNBDT protocol operates at the Application Layer in the network protocol stack risks associated with lower protocol layers are not addressed Issues such as Traffic Flow analysis LPI LPD and DoS must be dealt with outside the bounds of the FNBDT protocols 2 3 3 2 1 2 1 3 U FOUO Maturity U FOUO The FNBDT protocol is Mature in the sense that products have been implemented and deployed for several years Users have real-world experience with FNBDT products--both wired and wireless Additional modes and features will continue to be added to the specifications but the basic interoperable FNBDT modes are mature and will continue to exist for some time into the future The TRL of the basic FNBDT bitstream definition is 9 Mature products deployed in operational mission conditions U FOUO Application of the FNBDT protocol to IP-based transport is less mature Although different vendors are working to apply FNBDT technology to IP networks there are currently no interoperable standards for this specific application The TRL for using FNBDT over IP networks is currently estimated at 4 Emerging - breadboard validation in lab environment 2 3 3 2 1 2 1 4 U Standards U FOUO The FNBDT protocols are defined by the standards listed in Table 2 3-4 Table 2 3-4 U FNBDT Standards 4674 This table is U FOUO Name FNBDT-210 Signaling Plan FNBDT-230 Cryptography Specification Proprietary extensions Description This unclassified specification defines the signaling requirements for FNBDT operational modes A secure overlay capable of interoperation with FNBDT compatible equipment on various similar or disparate networks is defined Since the various networks will often have different lower-layer communications protocols the FNBDT secure overlay specification specifies the higher-layer endto-end protocols only Appendices to this specification define operation using specific networks This classified specification outlines details of the cryptography defined for FNBDT Issues such as key generation traffic encryption and compromise recovery are specified in sufficient detail to allow interoperable implementation The FNBDT signaling and cryptography specifications define interoperable branch points allowing vendors to implement proprietary modes This allows vendors to take advantage of the basic FNBDT structure to add modes fulfilling specific needs Legacy FNBDT implementations have used these branch points to implement custom cryptographic modes Details of such modes are contained in vendor proprietary specifications UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-38 UNCLASSIFIED FOR OFFICIAL USE ONLY This table is U FOUO 4675 4676 4677 4678 4679 4680 Name Description Other specifications Other interoperable FNBDT specifications have been suggested and are currently under consideration by the FNBDT Working Group These additional documents would provide interoperable ways of implementing additional features such as non-Type 1 operation and key management This table is U FOUO 2 3 3 2 1 2 1 5 U Cost Limitations U FOUO Although the FNBDT protocol is a good choice for solving many speech-related security issues there are limitations with this protocol as well Potential limiting factors that must be considered when evaluating FNBDT as a candidate protocol for solving security problems include o U FOUO Point-to-point operation The current definition of FNBDT includes point-topoint operation only There are no provisions in place for multi-user conferencing or net broadcast capabilities The FNBDT Working Group is currently active in defining net broadcast modes and Pre-Placed Key PPK methods allowing multiple users to decrypt a common encrypted bitstream o U FOUO Voice coders The FNBDT specifications currently define two voice coders 2400 bps MELP and 6400 bps G 729D FNBDT-compatible speech equipment must include one of these vocoders in order to interoperate with FNBDT equipment provided by other vendors o U FOUO Legacy interoperability FNBDT equipment is not compatible with other types of secure voice equipment Specifically the older generation STU-III devices that have been widely deployed throughout the world during the past 20 years are not compatible with the cryptography speech coders or wireline modems used by FNBDT equipment o U FOUO Establishing a channel FNBDT is defined as an application layer technology that provides the encrypted bitstream to transfer between two endpoints The details regarding how the digital channel is established between these two endpoints is left outside the scope of the FNBDT specifications As a result potential users must be aware of channel establishment procedures to make sure this process is successful outside the bounds of FNBDT o U FOUO Trusted platform requirement Application Layer security methods are not suitable for operation using general purpose computing equipment FNBDT and other Application Layer security approaches require trusted hardware to support separation requirements 4681 4682 4683 4684 4685 4686 4687 4688 4689 4690 4691 4692 4693 4694 4695 4696 4697 4698 4699 4700 4701 4702 4703 4704 4705 4706 4707 2 3 3 2 1 2 1 6 U Dependencies U FOUO FNBDT cryptography specifications depend on terminals containing appropriate key material The necessary key material is supplied by the Government's Electronic Key Management System EKMS UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-39 UNCLASSIFIED FOR OFFICIAL USE ONLY 4708 4709 4710 4711 4712 4713 4714 4715 4716 4717 4718 4719 4720 4721 4722 4723 4724 4725 4726 4727 4728 4729 4730 4731 U FOUO The call control process call establishment maintenance teardown etc is not defined by the FNBDT protocol These processes which are a necessary part of a successful FNBDT voice or data call must occur outside the scope of the FNBDT specifications 2 3 3 2 1 2 1 7 U Alternatives U FOUO The most widespread alternative to FNBDT secure speech systems continues to be the STU-III terminals These devices which are based on approximately 20-year old technology are no longer produced but are so pervasive throughout the Government that they continue to be a factor in secure speech system decisions The Government expects to continue producing key material to support these terminals through the GIG 2008 Vision timeframe U FOUO Other tactical and strategic secure voice system terminals exist in lower quantities Systems such as Advanced Narrowband Digital Voice Terminal ANDVT MSE etc are also relatively dated but continue to provide acceptable quality encrypted speech communications for certain specific applications U FOUO Depending on specific operational requirements a speech channel could be protected at the IP layer e g HAIPE rather than the Application Layer This approach referred to as Voice over Secure IP rather than Secure Voice over IP provides an alternative to the FNBDT Application Layer protection approach for user environments where separation within an enclave is not a consideration 2 3 3 2 1 2 1 8 U Complementary Techniques U FOUO Any given user situation may require a combination of technologies in order to meet all operational requirements For example the FNBDT protocol may provide confidentiality at the Application Layer but does nothing toward meeting any potential Traffic Flow Security or TRANSEC requirements at the lower layers Additional technologies will often need to be used in combination with the FNBDT protocol in order to meet all applicable security requirements UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-40 UNCLASSIFIED FOR OFFICIAL USE ONLY 4732 2 3 3 2 1 2 2 U Interoperability Gateways 4733 2 3 3 2 1 2 2 1 U Technical Detail U FOUO Interoperability is an important GIG consideration both from enclave to enclave within the GIG and from GIG resources to infrastructure external to the GIG Gateways provide the necessary interworking and protocol stack adaptation to provide this interoperability 4734 4735 4736 4737 4738 4739 4740 4741 4742 4743 4744 4745 4746 4747 4748 4749 4750 4751 U Gateways adapt the communication needs of different networks such that user data can be sent from one to another Gateways can be described as relay devices that is they relay user traffic from one protocol stack to another U Gateways can be grouped according to the specific functions they perform Some are signaling gateways that adapt the call control and other signaling needs of a particular network to the signaling needs of a different network Some are media gateways that adapt user speech from one form to another Signaling and media functions can be combined such that a common device provides both functions U FOUO Within the GIG architecture gateways will be necessary both for providing interoperability between different vendors VoIP implementations and for providing interoperability between packet-switched and circuit-switched networks U Figure 2 3-11 illustrates the protocol stacks associated with a typical Media Gateway MG included with a VoIP system for interoperation with legacy PSTN networks This MG provides a termination point for the IP UDP and RTP layers as well as providing a transcoder function The result is audio speech that can be routed to the PSTN 3 1 kHz Audio Transcoder RTP UDP Layer 3IP Network Layer 2Link - Data Link Layer 2 - Data Link Physical Layer 1 - Physical LayerPSTN 1 - Physical IP This figure is U 4752 4753 4754 4755 4756 4757 Figure 2 3-11 U Media Gateway Protocol Stack Illustration U FOUO Tactical networks within the GIG may also include gateway functionality to allow interoperation with other systems Like the commercial VoIP gateways these tactical versions contain a protocol stack appropriate to the specific tactical network on one side and a protocol stack appropriate to the target network on the other UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-41 UNCLASSIFIED FOR OFFICIAL USE ONLY 4762 U FOUO Although gateways will remain a necessary part of the infrastructure it is important that secure system architectures are designed so that gateways remain Black This means that although the gateways may remove or adapt network protocol stack layers they must not be expected to decrypt user traffic User traffic must remain encrypted as it traverses the gateway-- resulting in true end-user to end-user encryption 4763 2 3 3 2 1 2 2 2 U Usage Considerations 4764 2 3 3 2 1 2 2 2 1 U Implementation Issues U Legacy PSTN-based secure voice systems transport bits using a commercial wireline modem to modulate digital traffic over the analog PSTN In order for secure VoIP terminals to interoperate with these legacy systems the gateway must provide a compatible modem function on the PSTN side Although commercial VoIP systems today have recognized the need for PSTN Interworking and have included the Media Gateway functionality there is no commonly recognized need to include the modem function in this gateway 4758 4759 4760 4761 4765 4766 4767 4768 4769 4770 4777 U FOUO Therefore non-standard gateways are required to allow interworking between secure VoIP systems and legacy secure PSTN-based systems Although gateways containing this functionality have not been identified as a requirement in commercial VoIP systems it is important to point out that implementation and maintenance of such a gateway does not necessarily need to be carried out by the same vendor that supplies the basic VoIP system A system integrator having access to the IP network on one side and the PSTN on the other could insert the required gateway independent of the other infrastructure 4778 U FOUO The functionality associated with a secure VoIP gateway is shown in Figure 2 3-12 4771 4772 4773 4774 4775 4776 FNBDTVoIP Terminal VoIP Gateway Supporting FNBDT VoIP Server FNBDT Terminal Analog Analog PBX PBX Black VoIP Black PBXVoIP PBX FNBDT FNBDTVoIP Terminal RTP UDP IP Link Physical V xx modem Abstract Protocol Stack This figure is U FOUO 4779 4780 Figure 2 3-12 U FOUO Secure Voice Gateway Functionality UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-42 UNCLASSIFIED FOR OFFICIAL USE ONLY 4781 4782 4783 2 3 3 2 1 2 2 2 2 U Advantages U Gateway technology allows interoperation in at least two areas that would not be possible without gateways 4784 o U Operation with legacy equipment on circuit-switched networks 4785 o U Operation with different technologies within the same user environment 4786 4787 4788 4789 4790 4791 4792 4793 4794 4795 4796 4797 4798 4799 4800 4801 4802 4803 4804 4805 2 3 3 2 1 2 2 2 3 U Risks Threats Attacks U FOUO The basic risk associated with Black gateway technology is DoS If an adversary can gain access to the control mechanisms of the gateway traffic channels can be blocked such that users can be kept from using them There is no additional risk associated with the confidentiality of the user data since it is not decrypted at the gateway 2 3 3 2 1 2 2 3 U Maturity U Commercial signaling and media gateways are Mature TRLs 7 - 9 and exist for solving specific problems within specific bounds For instance the gateway technology associated with interoperating standard non-secure calls between VoIP systems and the PSTN is well understood and has been implemented in many forms U FOUO However the non-standard variations required for secure voice systems are Emerging TRLs 4 - 6 Commercial vendors have not seen a business case for defining and implementing gateways containing modem functionality as will be required for secure voice interoperation U FOUO Commercial VoIP systems on system-high networks are Mature TRL 9 - successful mission operations Secure Voice variants are Emerging TRL 5 -breadboard evaluation in relevant environment 2 3 3 2 1 2 2 4 U Standards U The following standards are used for gateway control in VoIP systems o U MEGACO also referenced as Gateway Control Protocol GCP RFC 3525 formerly RFC 3015 Also published by the ITU-T as Recommendation H 248 1 o U Media Gateway Control Protocol MGCP RFC 3435 4806 4807 4808 4809 4810 4811 4812 2 3 3 2 1 2 2 5 U Cost Limitations U FOUO Use of commercial media gateways is a cost-effective approach for VoIP systems that provide security by residing on system-high networks For VoIP systems that require FNBDT security there are at least two options to provide the necessary gateways o U FOUO Dedicated special-purpose gateway that leaves out the transcoder function and includes the modem function o U FOUO Modifications to commercial gateways to allow a client to bypass the transcoder in the gateway and route the information through a modem instead UNCLASSIFIED FOR OFFICIAL USE ONLY 4813 4814 4815 2 3-43 UNCLASSIFIED FOR OFFICIAL USE ONLY 4816 U FOUO Either of these options will result in additional complexity and associated cost 4817 2 3 3 2 1 2 2 6 U Dependencies U FOUO Gateway technology is highly dependent on the specific systems a particular gateway is providing interoperability between A gateway is designed to be completely compatible with a particular system on each side If a third system is introduced into the architecture it is highly likely that a separate gateway will be required 4818 4819 4820 4821 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-44 UNCLASSIFIED FOR OFFICIAL USE ONLY 4822 4823 4824 4825 4826 4827 2 3 3 2 1 2 3 Secure Voice over IP U FOUO Secure VoIP technologies described here secure the voice bearer or user voice packets Secure VoIP call or session control used to establish calls is addressed in section 2 3 3 2 2 2 1 2 3 3 2 1 2 3 1 U Technical Detail U FOUO Security technologies considered for VoIP voice packets include 4828 o U Secure Real-Time Protocol SRTP 4829 o U FOUO FNBDT over RTP 4830 o U FOUO Secured voice such as FNBDT over V 150 Modem Relay Simple Packet Relay Transport protocol SPRT 4831 4832 4833 4834 4835 4836 4837 4838 4839 4840 4841 4842 4843 4844 4845 4846 4847 4848 4849 4850 4851 4852 4853 4854 4855 4856 U FOUO A brief introduction to the VoIP technology is presented before a description of potential security technologies VoIP call control is described in section 2 3 3 2 2 2 1 VoIP architectures typically include control planes to set up VoIP calls and execute network services They also include bearer planes used to transfer voice packets between users after the call has been established H 323 and SIP are the leading protocol systems used for VoIP call control Other notable VoIP protocols specifically MGCP and GCP H 248 MEGACO reside between control and bearer planes They are used when VoIP-PSTN Gateways and Multimedia conference units are decomposed into Media Gateway Controllers MGCs and Media Gateways MGs MGCs use protocols such as MGCP to control the bearer path through MGWs U FOUO QoS protocols and systems such as RSVP and DiffServ are complementary technologies needed to support VoIP services but are not call control protocols themselves QoS should be established or negotiated outside of the voice bearer plane as part of the overall call set up process and subsequently applied to the actual voice stream packets Security mechanisms are needed to protect QoS mechanisms but such are outside the scope of this section U RTP is used in all common VoIP systems to transport voice packets between users A closer look at RTP follows 2 3 3 2 1 2 3 1 1 U RTP and RCTP Overview U Real-Time Transport Protocol is designed to transport real-time applications over IP networks RTP runs in conjunction with RTCP RealTime Control Protocol which provides feedback to applications about the quality of the media transmission U RTP provides time-stamping and Sequence Numbering of the Multimedia packets to enable synchronization of a received media stream As shown in Figure 2 3-13 RTP along with RTCP reside on UDP Reliability mechanisms such as re-transmits are not included since latency and jitter are more important to voice quality than bit errors or occasional voice packet losses A description of the fields within the RTP header follows the figure UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-45 UNCLASSIFIED FOR OFFICIAL USE ONLY This figure is U 4857 4858 Figure 2 3-13 U Real-Time Protocol 4859 U Version V 2 bits - This field identifies the version of RTP The current version is two 2 4860 U Padding P 1 bit - If the padding bit is set the packet contains one or more additional padding octets at the end that are not part of the payload Padding may be needed by some encryption algorithms with fixed block sizes or for carrying several RTP packets in a lower-layer protocol data unit 4861 4862 4863 4864 4865 4866 4867 4868 4869 4870 4871 4872 4873 4874 4875 4876 4877 4878 4879 4880 U Extension X 1 bit - If the extension bit is set the fixed header is followed by exactly one header extension U CSRC count CC 4 bits - The CSRC count contains the number of CSRC identifiers that follow the fixed header CSRCs are media contributors that reside behind a conference unit U Marker M 1 bit - The interpretation of the marker is defined by a profile It is intended to allow significant events such as frame boundaries to be marked in the packet stream A profile may define additional marker bits or specify that there is no marker bit by changing the number of bits in the payload type field U Payload type PT 7 bits This field identifies the format of the RTP payload and determines its interpretation by the application A profile specifies a default static mapping of payload type codes to payload formats An RTP sender emits a single RTP payload type at any given time this field is not intended for multiplexing separate media streams U Sequence number 16 bits - The sequence number increments by one for each RTP data packet sent This number can be used by the receiver to detect packet loss and to restore packet sequence The initial value of the sequence number is random unpredictable to make knownplaintext attacks on encryption more difficult even if the source itself does not encrypt because the packets may flow through a translator that does UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-46 UNCLASSIFIED FOR OFFICIAL USE ONLY 4881 4882 4883 4884 4885 4886 4887 4888 4889 4890 4891 4892 U Time-stamp 32 bits - The time-stamp reflects the sampling instant of the first octet in the RTP data packet The sampling instant must be derived from a clock that increments monotonically and linearly in time to allow synchronization and jitter calculations U SSRC 32 bits - The Synchronization Source Real-time Content SSRC field identifies the synchronization source This identifier is chosen randomly with the intent that no two synchronization sources within the same RTP session will have the same SSRC identifier U CSRC list 0 to 15 items 32 bits each - The Contributing Source Real-time Content CSRC list identifies the contributing sources for the payload contained in this packet U RTCP runs in conjunction with RTP Receiving participants send periodic information using RTCP back to the originating source to convey quality information about the received data RTCP provides the following services o U Quality Monitoring and Congestion Control - This is the primary function of RTCP and it provides feedback to senders about the quality of the connection The sender can use this information to adjust transmission Also third party monitors can use the information to access network operation o U Source Identification - The source field in the RTP header is a 32 bit identifier randomly generated and not user friendly RTCP provides a more user friendly identification of the 32 bit RTP source field by providing a global identification of session participants This information is typically user name telephone number email address etc o U Inter-Media Synchronization - RTCP sends information that can be used to synchronize audio and video packets o U Control Information Scaling - As the number of participants increase the amount of control information must be scaled down to allow sufficient bandwidth for the RTP channels This is done by the RTP protocol by adjusting the RTCP generation rate Typically the control bandwidth is limited to 5% of the RTP traffic 4893 4894 4895 4896 4897 4898 4899 4900 4901 4902 4903 4904 4905 4906 4907 4908 4909 4910 4911 4912 4913 4914 U FOUO Each RTCP packet begins with a fixed part similar to that of RTP data packets followed by structured elements that may be of variable length according to the packet type The alignment requirement and a length field in the fixed part are included to make RTCP packets stackable Multiple RTCP packets may be concatenated without any intervening separators to form a compound RTCP packet that is sent in a single packet of the lower layer protocol such as UDP There is no explicit count of individual RTCP packets in the compound packet since the lower layer protocols are expected to provide an overall length to determine the end of the compound packet UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-47 UNCLASSIFIED FOR OFFICIAL USE ONLY 4915 4916 4917 4918 4919 4920 4921 4922 4923 4924 4925 4926 U FOUO Figure 2 3-14 displays the format of one of the five RTCP messages--the RTCP Send Report RTP receivers provide reception quality feedback using RTCP report packets which may take one of two forms depending upon whether or not the receiver is also a sender The only difference between the sender report SR and receiver report RR forms besides the packet type code is the sender report includes a 20-byte sender information section active senders can use U FOUO It is expected that reception quality feedback will be useful not only for the sender but also for other receivers and third-party monitors The sender might modify its transmissions based on the feedback Receivers can determine whether problems are local regional or global Network managers can use profile-independent monitors that receive only the RTCP packets and not the corresponding RTP data packets to evaluate the performance of their networks for multicast distribution V P RC Length PT SR 200 RTCP Header 8 Octets SSRC of Sender NTP Timestamp - Most Significant Word NTP Timestamp - Lease Significant Word Sender Info 20 Octets RTP Timestamp Sender's Packet Count Sender's Octet Count SSRC_1 SSRC of first source fraction lost cumulative number of packets lost extended highest sequence number received Report Block 1 24 Octets interarrival jitter last SR LSR delay since last SR DLSR SSRC_2 SSRC of second source oo oo Report Block 2 24 Octets Profile Specific Extensions V Version now 2 P Padding RC Reception Report Count PT Payload Type Source RFC 1889 This figure is U 4927 4928 Figure 2 3-14 U RTCP Sender Report Format- Sender Report SR UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-48 UNCLASSIFIED FOR OFFICIAL USE ONLY 4929 U Secure RTP SRTP and Secure RTCP SRTCP per RFC 3711 4930 U FOUO SRTP SRTCP are used to protect the RTP RTCP protocols SRTP supports both IP unicast and multicast communications SRTP is a commercial security system and no type 1 versions are available Therefore SRTP can be used within a security domain but without further development is not advised to use to secure voice traffic across separate security environments Therefore another lower layer protocol such as IPsec should be used to transport secure voice across security domains 4931 4932 4933 4934 4935 4936 4937 4938 4939 4940 U FOUO Secure RTP is used to authenticate and protect RTP headers and payloads It is defined as an extension to the RTP Audio Video profile per RFC 3551 Each SRTP stream is organized around cryptographic contexts that senders and receivers use to maintain cryptographic state information The cryptographic context is uniquely mapped to the combination of 4941 o U The destination IP address 4942 o U The destination port 4943 o U The SSRC as seen in the RTP header 4944 4945 4946 4947 U FOUO SRTP session keys are cryptographically derived per the RFC from master keys and salt keys that are initialized via key management The salt keys are updated per the RFC for use in subsequent session key derivations The session keys are then applied to the voice media stream to provide encrypted voice 4950 U FOUO SRTP does not define or mandate a specific key management protocol However it does place requirements and considerations on the key management system These considerations are described in the dependencies section below 4951 U The SRTP Protocol 4952 U FOUO Figure 2 3-15 illustrates the format of SRTP 4953 U FOUO As can be seen from Figure 2 3-15 the SRTP format uses the RTP header and RTP payload followed by the SRTP MKI and Authentication tag fields The entire SRTP packet is authenticated while the RTP payload and SRTP MKI and authentication tags are encrypted 4948 4949 4954 4955 4956 4957 4958 4959 4960 4961 U FOUO The optional SRTP MKI Master Key Identifier field identifies the master key used in the session It does not indicate cryptographic context The MKI is defined and distributed by the key management system U FOUO The SRTP authentication tag is used to carry message authentication data The tag provides authentication of the RTP header and payload and indirectly provides replay protection by authenticating the RTP sequence number The tag is recommended for use by the RFC UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-49 UNCLASSIFIED FOR OFFICIAL USE ONLY 0 31 V P X CC M Sequence Number PT Time Stamp Synchronization Source ID - SSRC Contributing Source ID - CSRC Authenticated Portion Voice Bits RTP Padding RTP pad count Encrypted Portion SRTP MKI optional Authentication tag recommended For one Audio Source 0 Octets CC CSRC Count M Marker PT Payload Type V Version now 2 P Padding X Extension Source RFC 1889 This figure is U 4962 Figure 2 3-15 U SRTP Format 4963 4964 U The SRTCP protocol 4965 U FOUO Figure 2 3-16 illustrates the format of SRTCP 0 31 15 V P RC PT SR or RR Length SSRC of Sender Sender Info Report Block s V P SC PT SDES Authenticated portion Length SSRC CSRC_1 Encrypted portion SDES items E SRTCP index SRTCP MKI OPTIONAL Authentication tag This figure is U 4966 4967 Figure 2 3-16 U SRTCP Format UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-50 UNCLASSIFIED FOR OFFICIAL USE ONLY 4972 U FOUO As can be seen from Figure 2 3-16 the SRTCP format uses the RTCP header and RTCP payload reports followed by the SRTP 'E' SRTCP index SRTPC MKI and Authentication tag fields The entire SRTCP packet is authenticated while the RTCP payload is encrypted along with SRTCP specific fields Note that Figure 2 3-16 shows a generalized representation of the RTCP reports but this does impact the discussion of SRTCP fields 4973 U FOUO The 'E' field is a one-bit flag that indicates if the current RTCP packet is encrypted 4974 U FOUO The SRTCP index is a 31-bit counter for the SRTCP packet It is initially set to zero before the first SRTCP is sent and incremented by one after each SRTCP packet It is not reset to zero after a rekey event to help provide replay protection 4968 4969 4970 4971 4975 4976 4977 4978 U FOUO The optional SRTCP MKI field indicates the master key used to derive the session key for the RTCP context 4981 U FOUO The SRTCP authentication tag is used to carry message authentication data The tag provides authentication of the RTCP header and payload The tag is recommended for use by the RFC 4982 U Encryption algorithms 4983 4986 U FOUO SRTP calls out AES in counter mode for encryption and HMAC-SHA1 for message authentication and integrity The RFC explicitly states that any transforms added to SRTP must be added with a companion standard track RFC that exactly defines how the transform is used with SRTP 4987 U FNBDT over RTP 4988 U FOUO The second technology considered for secure voice is to create an RTP payload type for FNBDT type 1 secured voice Please refer to section 2 3 3 2 1 2 1 for a description of FNBDT The new RTP profile is defined to support both FNBDT signaling and data This FNBDT media type needs to be identified and negotiated between clients within the GIG VoIP call control architecture The RTP protocol field described above contains a GIG unique payload value indicating FNBDT to GIG users In such a scenario a client could start a clear voice call using an Internet Assigned Numbers Authority IANA standard RTP payload type voice codec and then use call control signaling to transition to the FNBDT profile 4979 4980 4984 4985 4989 4990 4991 4992 4993 4994 4995 4999 U FOUO Note that certain FNBDT modes add overhead to the clear voice codec approaches in order to maintain crypto-synchronization Differences in network resource requirements when transitioning between clear and secured FNBDT voice would need to be accounted for in the GIG QoS architecture 5000 U Secured voice such as FNBDT encryption over V 150 1 Modem Relay 5001 U FOUO Secure voice such as FNBDT encryption over V 150 1 modem relay applies type 1 secured voice over a commercial standard real-time transport mechanism for data Please refer to section 2 3 3 2 1 2 1 for a description of FNBDT The following is a brief overview of V 150 1 modem relay UNCLASSIFIED FOR OFFICIAL USE ONLY 4996 4997 4998 5002 5003 5004 2 3-51 UNCLASSIFIED FOR OFFICIAL USE ONLY 5005 5006 5007 5008 5009 5010 U FOUO ITU specification V 150 1 Modem Relay hereafter referred to V 150 1 MR is a VoIP-PSTN gateway feature It is designed to allow the successful transfer of data from a modem on a circuit network through a PSTN-VoIP GW and across an IP network through a second VoIP-PSTN GW and back onto a second modem over circuit network FNBDT secure voice over V 150 1 MR exploits the V 150 1 SPRT protocol as illustrated in Figure 2 3-17 below FNBDT Terminal VoIP Gateway Supporting V 150 1 MR FNBDT VoIP Terminal Analog Analog PBX PBX IP Network Analog PBX FNBDT Secured voice Voice codecs SPRT RTP UDP IP SS E voice FNBDT Secured voice V xx modem circuit This figure is U FOUO 5011 5012 Figure 2 3-17 U FOUO FNBDT over V 150 1 Modem Relay 5013 5024 U FOUO V 150 1 supports several modes that allow a user to multiplex between voice and data transport As can be seen from Figure 2 3-17 V 150 1 enables clear voice and the V 150 1 defined State Signaling Protocol to be carried over RTP SSE is used to transition between voice and modem data transport modes at a V 150 1 PSTN-VoIP GW As such State Signaling Event SSE instructs the GW to initiates a V xx modem on the circuit network in preparation of making a voice to data transition Data bearer however is carried over the IP network with the V 150 1 Simple Packet Relay Transport protocol SPRT SPRT is placed on UDP and includes both reliable and transparent sequenced modes FNBDT secured voice is carried over the SPRT transparent sequenced mode which is designed to support real-time data SPRT includes sequence numbers to facilitate proper packet ordering at receivers As such V 150 1 MR is able to transport type 1 secured voice between VoIP and circuit networks using a V 150 1 commercial standard VoIP GW 5025 U Figure 2 3-18 below illustrates the SPRT format 5014 5015 5016 5017 5018 5019 5020 5021 5022 5023 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 X SSID R PT TC Sequence Number NOA Base Sequence Number TCN Sequence Number TCN Sequence Number TCN Sequence Number This figure is U 5026 5027 5028 Figure 2 3-18 U V 150 1 Simple Packet Relay Transport for IP networks U The SPRT header fields are summarized as follows UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-52 UNCLASSIFIED FOR OFFICIAL USE ONLY 5029 U X Header Extension Bit currently reserved by ITU 5030 U SSID SubSession ID used to identify a media stream 5031 U R reserved by ITU 5032 U PT payload type The payload is set to the value assigned by the media stream by call control signaling Note that the R and PT field together are consistent with the same fields seen in the RTP header such that clients and GWs can transition between voice RTP and data SPRT over the same UDP port 5033 5034 5035 5036 5037 5038 5039 5040 5041 5042 5043 5044 5045 U FOUO TC - Transport Channel number FNBDT uses transport channel 3 designed for real-time data without acknowledgements U FOUO The sequence number field is incremented with each SPRT packet similar to the sequence number in RTP U FOUO NOA - Number of Acknowledgments Acknowledgments are set to zero for FNBDT and other real-time data services U FOUO The Base Sequence number field is used to manage re-transmits It is set to zero for TC 3 the channel used by FNBDT U FOUO TCN and subsequent sequence number fields are used for re-transmits These fields are not used with FNBDT over V 150 1 MR 5048 U FOUO In summary an FNBDT over V 150 1 client can first establish a clear voice call and send clear voice via RTP It can then use SSE to transition to data mode Once in data mode the client then used SPRT to transport FNBDT signaling and secured voice 5049 2 3 3 2 1 2 3 2 U Usage Considerations 5050 2 3 3 2 1 2 3 2 1 U Implementation Issues U SRTP 5046 5047 5051 5052 5053 5054 5055 5056 5057 5058 5059 5060 U FOUO Each media stream in a multimedia session requires its own SRTP session key This multiplies the potential number of security contexts initiated per user This is a concern for mobile multimedia services with limited battery and processing power More security contexts could also multiply the amount of key management traffic U FOUO Forward error correction and interleaving if required by the RTP media type need to be completed before application of SRTP U FOUO SRTP cannot span into non-IP networks such as the PSTN or DSN Therefore a VoIP-PSTN GW would need to terminate SRTP and invoke another security mechanism for the PSTN side of a VoIP to PSTN call This requires a complex Red GW function UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-53 UNCLASSIFIED FOR OFFICIAL USE ONLY 5063 U FOUO Note that SRTP can be used for end-to-end security in half duplex voice conferences using multicast But full duplex conferences require a Red conference unit either at each client or in a central server 5064 U FNBDT over RTP 5065 5070 U FOUO The custom RTP profile developed for RTP complicates the use of existing VoIP call control mechanisms which will need to be extended for this unique media type It should also be noted that the RTP header time stamp is not used as originally intended since the RTP payload contains a mixture of FNBDT security signaling besides ciphered voice FNBDT over RTP does not fit within conventional VoIP-circuit GWs A custom GW would be required for FNBDT over RTP See section 2 3 3 2 1 2 2 for further discussion of GW topics 5071 U FNBDT over V 150 1 Modem Relay 5072 U FOUO V 150 1 MR is defined for PSTN-IP-PSTN scenarios and as such is a GW architectural element Therefore this GW function would need to be collapsed into a voice client for application in an all IP environment This may be considered complex for a mobile user device Since V 150 1 MR is not a widely used transport mechanism in IP networks it potentially introduces a new network transport mechanism in the GIG specifically for secure voice 5061 5062 5066 5067 5068 5069 5073 5074 5075 5076 5077 5078 5079 5080 5081 5082 5083 5084 5085 5086 5087 5088 5089 5090 5091 5092 5093 5094 5095 5096 2 3 3 2 1 2 3 2 2 U Advantages U FOUO SRTP fits well within conventional VoIP architectures and promises to become a widely known commercial standard It is less complex than other approaches when used in an all IP network of a single-security domain U FOUO FNBDT is a proven type 1 protocol The use of RTP fits within conventional VoIP architectures although it is extended for the non-standard FNBDT media type But FNBDT over RTP would require custom black circuit-VoIP GWs U FOUO V 150 1 MR can be used within an all IP network as well across black V 150 1 PSTN GWs to legacy FNBDT devices As such it offers the potential to provide type 1 security from a VoIP to a PSTN-based terminal as it leverages an established type 1 security protocol 2 3 3 2 1 2 3 2 3 U Risks Threats Attacks U SRTP U FOUO SRTP does support type 1 algorithms without extending the protocol with a new standards track RFC As such it should not be used to transport secure voice across security domain boundaries U FOUO RTP uses the 16-bit RTP header sequence number to help set the KG state Use of the RTP sequence number to set KG state may not be sufficient for type 1 algorithms The RTP header used is subject to manipulation although the SHA-1 authentication mechanism provides at least partial protection UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-54 UNCLASSIFIED FOR OFFICIAL USE ONLY 5099 U FOUO SRTP would also require custom red VoIP- circuit GWs Since SRTP requires Red GWs to reach circuit networks it may not be the leading security protocol candidate for secure voice 5100 U FNBDT over RTP 5101 5103 U FOUO There are no risks threats or attacks unique to FNBDT over RTP identified that are not common to any type 1 application transferred over an RTP UDP IP stack Specifically the IP UDP and RTP headers are not protected nor authenticated 5104 U FNBDT over V 150 5105 U FOUO There are no risks threats or attacks unique to FNBDT over V 150 1 identified that are not common to any type 1 application transferred over a SPRT UDP IP stack Specifically the IP UDP and SPRT headers are not protected nor authenticated 5097 5098 5102 5106 5107 5108 5109 5110 5111 5112 5113 5114 5115 5116 2 3 3 2 1 2 3 3 U Maturity U SRTP U FOUO SRTP is Emerging with an estimated TRL of 4 since it is well specified and released as an RFC dated March 2004 It is assumed that portions of the function have been demonstrated with experimental code by SRTP within the IETF community SPRT products are widely available in commercial products U FOUO Areas of further study and development are recommended before SRTP can be used within the GIG--specifically o U FOUO A Key management system that incorporates SRTP requirements needs to be defined and developed o U FOUO A concept of operations that describes how SRTP is supported within the GIG call session control architecture needs to be developed o U FOUO Methods to transition between clear and secure voice within a single session using SRTP need to be defined and developed o U FOUO An evaluation of how SRTP might evolve to support type 1 security might be considered o U FOUO Performance evaluation and prediction of SRTP within mobile environments should be addressed 5117 5118 5119 5120 5121 5122 5123 5124 5125 5126 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-55 UNCLASSIFIED FOR OFFICIAL USE ONLY 5127 U FNBDT over RTP 5128 U FOUO FNBDT and RTP are both Mature with a TRL of 9 since they have been proven in multiple product deployments But use of an FNBDT RTP profile or media type is new and has progressed little past laboratory demonstration As such we consider the combination of FNBDT and RTP to be Emerging with a TRL of 4 5129 5130 5131 5132 5133 U FOUO Areas of further study and development are recommended before FNBDT over RTP can be used within the GIG--specifically 5134 o U FOUO FNBDT rekey over IP needs to be developed 5135 o U FOUO A concept of operations that describes how FNBDT over RTP is supported within the GIG call session control architecture needs to be developed o U FOUO Methods to transition between clear and secure voice within a single session using FNBDT over RTP need to be defined and developed o U FOUO FNBDT over RTP is currently defined for point-to-point communications An evaluation of how FNBDT and RTP constructs could be extended to support multicast communications is advised o U FOUO Performance evaluation and prediction of FNBDT over RTP within mobile environments should be addressed 5136 5137 5138 5139 5140 5141 5142 5143 5144 U FNBDT over V 150 1 5145 U FOUO FNBDT is a Mature secure technology as merits a TRL of 9 5146 U FOUO V 150 1 MR is a new immature transport technology that may not be widely used or supported in the commercial world Several sections in the ITU are labeled 'to be defined ' and standard evolution is likely Even so a commercial manufacturer has demonstrated V 150 1 MR capability and is likely to offer the function in commercial products For this reason FNBDT over V 150 1 is Emerging TRL 4 5147 5148 5149 5150 5151 5152 U FOUO Areas of further study and development are recommended before V 150 1 MR can be used within the GIG--specifically 5153 o U FOUO FNBDT rekey over IP needs to be defined and developed 5154 o U FOUO A concept of operations that describes how V 150 1 media type is supported within the GIG call session control architecture needs to be developed o U FOUO Methods to transition between clear and secure voice within a single session using RTP - V 150 1 SPRT session need to be defined and developed o U FOUO FNBDT over V 150 1 is currently defined for point-to-point communications An evaluation is advised on how FNBDT and V 150 1 constructs could be extended to support multicast communications 5155 5156 5157 5158 5159 5160 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-56 UNCLASSIFIED FOR OFFICIAL USE ONLY 5161 o 5162 5163 U FOUO Performance evaluation and prediction of V 150 1 within mobile environments should be addressed 2 3 3 2 1 2 3 4 U Standards Table 2 3-5 U Secure Voice over IP Standards 5164 This table is U FOUO Name Description FNBDT-210 Signaling Plan Revision 2 0 ITU V 150 Procedures for the end-to-end connection of V-series DCEs over and IP network RFC 3550 RTP A Transport Protocol for Real-Time Applications RFC 3711 The Secure Real-time Transport Protocol SRTP This table is U FOUO 5165 5166 5167 5168 5169 5170 5171 5172 5173 5174 5175 5176 5177 5178 5179 5180 5181 2 3 3 2 1 2 3 5 U Cost Limitations U FOUO SRTP cannot be used with COTS PSTN GWs to reach secure voice devices on the PSTN or DSN SRTP must be terminated at the GW This lack of PSTN interoperability 1 can complicate migration plans 2 might restrict mobile GIG user communications in less developed countries and 3 can restrict secure voice with less developed coalition partners A custom Red PSTN GW is required U FOUO FNBDT over RTP has the same restriction as SRTP It cannot be used with COTS PTSN GWs to reach secure voice devices on the PSTN or DSN A custom Black PSTN GW is required Furthermore FNBDT currently does not support multicast or groups call FNBDT standards development is required for group calling U FOUO V 150 1 may not be widely used in the commercial market It might be used exclusively for secure voice within the GIG As such it is a network transport mechanism that may not enjoy economies of scale as other approaches might Furthermore V 150 1 was not defined for multicast groups so a concept of operations for secure group calls utilizing V 150 1 needs to be developed U FOUO FNBDT currently does not support multicast or group calls Further FNBDT standards development is required 5183 2 3 3 2 1 2 3 6 U Dependencies U SRTP 5184 U Key Management Dependencies and interaction 5185 U FOUO SRTP places a number of dependencies upon key management Section 8 2 of the RFC details a list of parameters the key management system provides including 5182 5186 5187 o U FOUO Master key parameters for an SSRC 5188 o U FOUO Salt keys parameters for an SSRC UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-57 UNCLASSIFIED FOR OFFICIAL USE ONLY 5189 5190 o U FOUO Initial RTP sequence number and other crypto context index parameters optional 5193 U FOUO Clients will need to account for the amount of traffic protected with a single master key and request a rekey from the key management system based on specific usage criteria The key management system can of course push keys to SRTP clients 5194 U QoS management 5195 U FOUO Network QoS mechanisms suitable for VoIP and RTP should be sufficient for SRTP 5196 U FNBDT over RTP and FNBDT over V 150 1 MR 5197 5198 U FOUO FNBDT has specific key management requirements and specifications and currently supported with deployed facilities These facilities may need to be upgraded to meet GIG needs 5199 U QoS management 5200 U FOUO Network QoS mechanisms need to be developed that take into account the resource utilization of FNBDT particularly between clear and secure voice transitions 5191 5192 5201 5202 5203 5204 5205 5206 2 3 3 2 1 2 3 7 U Alternatives U FOUO IP layer security could be used as an alternative to SRTP and FNBDT over RTP 2 3 3 2 1 2 3 8 U Complementary Techniques U FOUO Type 1 IPsec is needed to secure SRTP protected voice traffic across security domains UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-58 UNCLASSIFIED FOR OFFICIAL USE ONLY 5207 2 3 3 2 2 U Transport Network Layer Technologies 5208 2 3 3 2 2 1 U Non-Real-Time Data Technologies 5209 2 3 3 2 2 1 1 U IP Layer Security U FOUO IP layer security enables the Black Core concept allowing IP layer routing and subnetwork layer switching to occur on the Black Core whereas traditional link security required all routers and switches to be Red 5210 5211 5212 5213 5214 5215 5216 5217 5218 5219 5220 5221 5222 5223 5224 5225 5226 5227 5228 5229 5230 5231 5232 5233 5234 5235 5236 5237 5238 5239 2 3 3 2 2 1 1 1 U Technical Detail U FOUO Commercial IPsec can be used to protect SBU traffic and HAIPE can be used to protect classified traffic HAIPE was originally based on the existing commercial IPsec standards but has shifted from these standards to provide the higher level of security necessary in a Type-1 application U FOUO Commercial IPsec defines separate protocols for confidentiality and authentication but the confidentiality protocol ESP provides an optional authentication mechanism HAIPE requires authentication as well as confidentiality U FOUO Commercial IPsec has defined both a transport mode and a tunnel mode and is intended to support both end system and intermediate system implementations HAIPE has defined only a tunnel mode and is intended to support only intermediate system INE implementations The GIG vision is to migrate HAIPE back to end system implementations and consequently some modifications will be required to HAIPE to achieve this vision U FOUO HAIPE v1 supported IPv4 only and HAIPE v2 is intended to support both IPv4 and IPv6 The GIG vision is to migrate to IPv6 U FOUO HAIPE supports a Security Policy Database SPD to control the flow of IP datagrams HAIPE supports selectors such as source destination addresses IPv4 and IPv6 to map IP datagram traffic to policy in the SPD Each entry specifies the relevant selectors and whether data should be tunnel-mode encrypted or discarded If an SPD entry cannot be found for an IP datagram the IP datagram is discarded Entries in the SPD are ordered The SPD can be managed locally by the administrator operator HMI or remotely from the SMW U FOUO HAIPE also supports a Security Association Database SAD The SPD is consulted in formation of SA entries in the SAD during an Internet Key Exchange IKE Separate distinct SAs are used for inbound and outbound traffic The two SAs use the same Traffic Encryption Key TEK but have different SPI values Entries in the SAD are not ordered The SAD is consulted in the processing of all traffic including non-IPsec traffic i e bypassed regenerated traffic as well as traffic encrypted in tunnel mode UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-59 UNCLASSIFIED FOR OFFICIAL USE ONLY 5248 U FOUO HAIPE utilizes the ESP tunnel mode to provide data integrity anti-replay protection confidentiality and authentication The original Red IP datagram is encapsulated with the HAIPE ESP protocol and then a Black IP protocol as shown in Table 2 3-6 Table 2 3-6 indicates a total overhead of 83 octets or 664 bits for each Red datagram assuming Black IP is v4 The HAIPE trailer padding includes both crypto padding and TFS padding Crypto padding varies from 0-47 octets HAIPE supports crypto block sizes of 4 8 and 48 octets and an average value of 23 octets is assumed for the overhead calculation in Table 2 3-6 No TFS padding is assumed in the overhead calculation in Table 2 3-6 Of course the addition of TFS padding would increase the overhead 5249 Table 2 3-6 U FOUO HAIPE ESP Tunnel Mode Encapsulation 5240 5241 5242 5243 5244 5245 5246 5247 This table is U FOUO Field Authenticated Black IP Header HAIPE SPI X ESP Header ESP Sequence Number State Variable Payload Sequence Number X Red IP Red IP Header X Datagram Red IP Payload X HAIPE Padding Crypto TFS X ESP Trailer Dummy X Pad Length X Next Header X Authentication Data Total This table is U FOUO Encrypted X X X X X X X X Overhead Bits Octets 160 32 32 128 64 184 8 16 8 32 664 20 4 4 16 8 23 1 2 1 4 83 5250 5251 5252 5253 5254 5255 5256 5257 5258 5259 U FOUO Note that HAIPE provides authentication anti-spoof protection of the Red IP datagram and parts of the HAIPE header and trailer as indicated in the Authenticated column in Table 2 3-6 PDUs that fail the authentication check are discarded This may be undesirable for voice and video data where a few bit errors are tolerable HAIPE provides confidentiality encryption of the Red IP datagram and parts of the HAIPE header and trailer as indicated in the Encrypted column in Table 2 3-6 U FOUO The 32-bit SPI identifies the security association to the receiving HAIPE device The SPI is either calculated from key material and peer information for PPKs or developed during the IKE exchange for automatic TEK generation UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-60 UNCLASSIFIED FOR OFFICIAL USE ONLY 5260 5261 5262 5263 5264 5265 5266 5267 5268 U FOUO HAIPE uses the payload Payload Sequence Number PSEQN for anti-replay service Therefore even though transmitting HAIPE devices initially set the ESP SEQN value to a random number and increment for each packet set receiving HAIPE devices ignore the ESP SEQN value U FOUO The state variable is used to synchronize the crypto state of the transmitting and receiving HAIPE device and does not repeat for any given TEK The state variable is transmitted with each PDU so that the receiving HAIPE device can independently decrypt each PDU Table 2 3-7 shows contents of the state variable Table 2 3-7 U FOUO HAIPE State Variable Content This table is U FOUO Value On Wire Encryption Decryption Value Field Bits Update Count 16 Indicates daily update count of TEK Unique 69 Unique LRS 36 SEQ# 4 SEG# 3 Total 128 Stepped when SEG# has value 0 Unique All zeros Stepped from 0-3 for WEASLE Mode - - This table is U FOUO 5269 5272 U FOUO The update count field represents the number of daily updates performed on the TEK The receiver uses to determine which update version of the TEK was used by the transmitter to encrypt the PDU 5273 U FOUO The Unique LRS SEQ# and SEG# fields are unique on the wire for each PDU 5274 5277 U FOUO The initial value for the Linear Recursive Sequence LRS is transmitted on the wire and is uniquely generated for each PDU During encryption or decryption processing of crypto blocks of the same PDU the LRS is stepped each time the SEG# has the value zero illustrated in Figure 2 3-19 The polynomial for the LRS is 1 x11 x36 5278 U FOUO The SEQ# field is unique on the wire but all zeros for encryption and decryption 5279 U FOUO The SEG# is unique on the wire During encryption or decryption processing of crypto blocks of the same PDU the SEG# is stepped from 0 to 3 in WEASEL mode as illustrated in Figure 2 3-19 5270 5271 5275 5276 5280 5281 5282 5283 5284 5285 U FOUO The PSEQN value provides anti-replay services for HAIPE The PSEQN value is both authenticated and encrypted The PSEQN value is initialized to zero by the transmitting HAIPE upon SA setup and incremented for each PDU sent for the duration of the TEK The receiving HAIPE uses the PSEQN value to detect and discard PDUs that are replayed UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-61 UNCLASSIFIED FOR OFFICIAL USE ONLY 5286 U FOUO Inner IP header fields are coded in accordance with RFC 2401 5287 U FOUO Padding ensures the encrypted PDU is an integer multiple of the encryption block size which may be negotiated during the IKE Padding is also used to provide TFS protection The ESP padding is added by the transmitting HAIPE and removed by the receiving HAIPE 5288 5289 Receive PDU Move SV into State Register SEQ# 0 SEG# 0 Shift LSR Encrypt Block Increment SEG# mod 4 Yes Last block of PDU No No SEG# 0 Yes 5290 This figure is U 5291 Figure 2 3-19 U FOUO State Variable Stepping 5292 U FOUO The ESP dummy field is used to support TFS protection A value of all 0s indicates a dummy PDU whereas a value of all 1s indicates a Valid PDU 5293 5294 5295 5296 5297 5298 5299 5300 5301 5302 5303 U FOUO The ESP pad length field is used by the receiving HAIPE to determine the amount of padding added by the transmitting HAIPE so the receiver can remove this padding before forwarding the decrypted PDU to the receiving host U FOUO The ESP next header field indicates the encapsulated protocol In the case of tunneled user traffic this field will indicate IPv4 or IPv6 U FOUO HAIPE supports both the BIP-32 and SHA-1 algorithms for authentication In either case the authentication value is encrypted under the negotiated cryptographic algorithm operating in WEASEL mode U FOUO The BIP-32 algorithm is a 32-bit exclusive-or function of each of the 32-bit words of data to be authenticated and a 32-bit word of hexadecimal A s 0xAAAAAAAA UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-62 UNCLASSIFIED FOR OFFICIAL USE ONLY 5304 2 3 3 2 2 1 1 2 U Usage Considerations 5305 2 3 3 2 2 1 1 2 1 U Implementation Issues U FOUO The application of IPsec to protect Unclassified traffic in the GIG introduces key management issues In order to provide sufficient protection secure Type 3 key material must be generated distributed stored updated and destroyed The current KMI is only designed for Type 1 key material Given the volume of Unclassified data in the GIG the number of IPsec devices that must be keyed will also be significant residing on every client in the GIG Vision Without a key management infrastructure for Type 3 keys deployment of IPsec to protect Unclassified traffic may be unmanageable 5306 5307 5308 5309 5310 5311 5312 5313 5314 5315 5316 5317 5318 5319 5320 5321 5322 5323 5324 5325 5326 5327 5328 5329 5330 5331 5332 5333 5334 5335 5336 5337 5338 5339 5340 U FOUO HAIPE does not support dynamic routing in a multi-homed environment i e an enclave fronted by more than one HAIPE This limitation may be overcome by placing external routers behind HAIPEs and using IP tunneling e g see RFC-2784 on Generic Routing Encapsulation between the routers to disguise the ultimate destination from the INE This approach requires an extra IP header and therefore increases bit overhead across the Black Core U FOUO An alternative is to integrate a router into the Red side of the INE and to select the SA based on the next hop instead of the ultimate destination address This approach has less bit overhead than the external router approach but couples the routing function with the HAIPE security function U FOUO HAIPE does not fully support QoS mechanisms for real-time traffic like voice HAIPE does support bypass of IPv4 Type of Service ToS field and IPv6 Traffic Class field but does not support reservation protocols For example TSAT has proposed modifications to HAIPE to provide an RSVP proxy service where a HAIPE INE would aggregate multiple Red side RSVP requests into a single Black side RSVP request U FOUO HAIPE does not provide true end-to-end security Currently HAIPE is designed to support INE implementations with multiple end-systems behind an INE Even when migrated to end-systems HAIPE will not provide true end-to-end security for some applications For example e-mail is a store-and-forward application with multiple IP end-systems in the path Likewise secure voice through a gateway will have IP end-systems as intermediate nodes Additional security protocols may be overlaid on top of HAIPE to provide true end-to-end security e g SMIME v3 for secure e-mail and FNBDT for secure voice U FOUO HAIPE is currently not designed for end system implementation HAIPE version 1 and version 2 only support tunnel mode and does not support transport mode HAIPE version 3 will support both tunnel and transport modes Anti-tamper and TEMPEST are also significant issues for a Type-1 end-system implementation U FOUO HAIPE discovery does not support dynamic Black-side IP addresses Dynamic Black-side IP addresses are common in a mobile IPv4 environment The migration to IPv6 in the future will help to resolve this issue to some extent UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-63 UNCLASSIFIED FOR OFFICIAL USE ONLY 5341 5342 5343 5344 5345 5346 5347 5348 5349 5350 5351 5352 5353 5354 5355 5356 5357 5358 5359 U FOUO HAIPE has significant complexity and was not intended for implementation in a resource-constrained environment e g memory and processing power A profile of HAIPE may be desirable for implementation in hand-held mobile devices U FOUO HAIPE was not intended for low bandwidth and or high BER environments HAIPE has significantly more bit overhead than FNBDT for protecting secure voice traffic There have been several HAIPE-lite proposals to address this issue These proposals do reduce the bit overhead associated with HAIPE but are still not as efficient as FNBDT for secure voice applications HAIPE is also not tolerant to bit errors HAIPE provides cryptographic error extension and also implements an integrity check on every packet A single bit error will cause the packet to be discarded This is not necessarily desirable for applications like secure voice that can tolerate a few bit errors 2 3 3 2 2 1 1 2 2 U Advantages U FOUO IP layer security supports a black core concept allowing switches and routers to exist on the black side of the crypto 2 3 3 2 2 1 1 2 3 U Risks Threats Attacks U FOUO IP layer security is somewhat susceptible to Traffic Flow Analysis Moving IP layer security HAIPE back to end systems will likely increase susceptibility to Traffic Flow Analysis Link layer security may be used to provide Traffic Flow Security TFS for traffic encrypted at the IP layer 5365 2 3 3 2 2 1 1 3 U Maturity U FOUO IPsec is a Mature technology in the commercial world but continues to evolve Type 1 IP security standards SDNS and HAIPE have been around for quite some time but HAIPE continues to evolve and the current standard is not adequate to support the long-term GIG vision The TRLs for the IP security technology are illustrated in Table 2 3-8 below Table 2 3-8 is based on the HAIPE Roadmap presentation dated May 12 2004 5366 Table 2 3-8 U FOUO IP Security Technology Readiness Levels 5360 5361 5362 5363 5364 This table is U FOUO Specification Core Extension Features TRL IPsec November 1998 9 IPsec March 2004 2 HAIPE v1 3 5 Core BATON and FIREFLY IPv4 Core MEDLEY and Enhanced FIREFLY IPv6 QoS Multicast Over the Network Management Extension Interim Routing Enclave Prefix Discovery Server Foreign Interoperability HAIPE v2 0 0 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-64 9 2 UNCLASSIFIED FOR OFFICIAL USE ONLY This table is U FOUO Specification Core Extension Features Core Bandwidth Efficiency v3 OTNK Beyond v3 Over the Network Management Enhancements Beyond v3 Extension Standard HAIPE MIB Scalable Efficient Routing End-to-End QoS Voice over Secure IP VoSIP HAIPE v3 Beyond This table is U FOUO 5367 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-65 TRL 1 UNCLASSIFIED FOR OFFICIAL USE ONLY 5368 5369 5370 5371 2 3 3 2 2 1 1 4 U Standards U FOUO The standards applicable to IP security technology are identified in Table 2 3-9 below Table 2 3-9 U FOUO Standards Applicable to IP Security Technology This table is U Number RFC-2401 RFC-2402 Title Version Date Interoperability Specification For High Assurance Internet Protocol Encryptor HAIPE Devices 1 3 5 May 2004 Interoperability Specification For High Assurance Internet Protocol Encryptor HAIPE Devices 2 0 0 May 2004 Security Architecture for the Internet Protocol http www ietf org rfc rfc2401 txt November 1998 Security Architecture for the Internet Protocol http www ietf org internet-drafts draft-ietf-ipsec-rfc2401bis02 txt April 2004 IP Authentication Header http www ietf org rfc rfc2402 txt November 1998 IP Authentication Header http www ietf org internet-drafts draft-ietf-ipsec-rfc2402bis07 txt RFC-2406 IP Encapsulating Security Payload ESP http www ietf org rfc rfc2406 txt IP Encapsulating Security Payload ESP http www ietf org internet-drafts draft-ietf-ipsec-esp-v3-08 txt March 2004 November 1998 March 2004 This table is U 5372 5373 5374 5375 5376 5377 5378 5379 5380 5381 5382 5383 2 3 3 2 2 1 1 5 U Cost Limitations U FOUO Moving HAIPE back to end systems may not be as economical as fronting multiple end systems with a single HAIPE INE 2 3 3 2 2 1 1 6 U Dependencies U FOUO Key management is needed to support commercial IPsec and HAIPE implementations HAIPE supports Pre-Placed Keys PPKs as well as auto-generated Traffic Encryption Keys TEKs Auto-generation includes FIREFLY and Enhanced FIREFLY U FOUO HAIPE also depends on remote security management via a Security Management Workstation SMW 2 3 3 2 2 1 1 7 U Alternatives U FOUO FNBDT application layer security can be used to provide end-to-end protection for secure voice traffic UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-66 UNCLASSIFIED FOR OFFICIAL USE ONLY 5384 5385 5386 5387 5388 5389 5390 5391 5392 5393 5394 5395 5396 5397 5398 5399 5400 5401 U FOUO Sub-network layer security can be used to protect information as it crosses a subnetwork Sub-network layer security allows black side switches but still requires all IP routers to be red For example the CANEWARE Front End had a mode where it encrypted the payload of X 25 packets A more modern example is FASTLANE which provides security of the payload of ATM cells U FOUO It is also possible to tunnel red side sub-network link and physical layers over a black IP network For example BLACKER provided the ability to map red side X 25 addresses to black side IP addresses creating a Red Virtual Network which spanned a black side internet Additional examples include the NES and Sectera INEs which provide the ability to map red side MAC addresses to black side IP addresses essentially bridging a black side internet U FOUO Security is also possible over SONET using the KG-189 to provide security of the SONET payload 2 3 3 2 2 1 1 8 U Complementary Techniques U FOUO Link and physical layer mechanisms provide additional security TRANSEC mechanisms support LPI LPD HAIPE has some TFS mechanisms but link security can be used to enhance Traffic Flow Security TFS Higher layer mechanisms e g S MIME v3 for secure e-mail and FNBDT for secure voice can be used to provide true end-to-end security and confidentiality within a domain UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-67 UNCLASSIFIED FOR OFFICIAL USE ONLY 5402 5403 2 3 3 2 2 1 2 U Traffic Flow Security TFS U EDITOR'S NOTE MATERIAL ON TFS WILL BE INCLUDED IN A FUTURE RELEASE UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-68 UNCLASSIFIED FOR OFFICIAL USE ONLY 5404 5405 5406 5407 5408 5409 5410 5411 5412 5413 5414 5415 5416 5417 5418 5419 5420 2 3 3 2 2 1 3 U Virtual Private Networks VPN U FOUO A Virtual Private Network VPN generally connects two private networks over a publicly accessible network e g the Internet Most VPNs are IP implementations that can be handled by a company's existing Internet technology A VPN can provide a secure connection between remote sites without additional expenses for leased lines ISDN or frame-relay and Asynchronous Transfer Mode ATM technologies 2 3 3 2 2 1 3 1 U Technical Detail U FOUO VPNs provide authentication integrity and confidentiality security services across a network usually a publicly accessible network Most VPN products use IPsec to carry out these security features but other protocols e g SSL are also used in some products For non-IP networks e g Internetwork Packet Exchange IPX or AppleTalk Layer 2 Tunneling Protocol L2TP is more suitable U IPsec VPNs are a network layer technology This means they operate independent of the applications that may use them Tunnel mode IPsec encapsulates the IP data packet hiding the application protocol information Once the IPsec tunnel is created various connection types e g web email VoIP FTP can flow through the tunnel each destined for different destinations on the other side of the VPN gateway 5422 U SSL VPNs are a remote access solution because they do not require IT departments to upgrade and manage client software All a user needs is a Web browser 5423 U FOUO VPN products can be grouped into three categories 5421 5424 o U Hardware-based systems 5425 o U Firewall-based systems 5426 o U Stand-alone application packages 5427 5428 5429 5430 5431 5432 5433 5434 5435 5436 5437 5438 U FOUO Hardware-based VPNs typically use encryption routers providing IP services such as IPsec tunneling This is a common deployment strategy in a corporate network infrastructure to securely connect remote networks Another hardware implementation involves VPN gateways used as IPsec tunnel endpoints The VPN gateways provide firewalls and routing as well as authentication encryption and key management capabilities U FOUO Firewall VPNs take advantage of a firewall's authentication and access control features adding a tunneling capability and encryption functionality U FOUO Stand-alone application VPNs use software to perform the access control authentication and encryption needed for the VPN The software VPN solution is the least expensive but generally has the worst performance Software VPNs are adaptive to technology changes because no hardware changes are involved The software VPN is ideal for company employees working on travel or from home UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-69 UNCLASSIFIED FOR OFFICIAL USE ONLY 5439 5440 2 3 3 2 2 1 3 2 U Usage Considerations U FOUO When setting up a VPN you must consider the following options 5441 o U Security protocols supported 5442 o U Cryptographic algorithms supported 5443 o U Key management system used 5444 o U User authentication used 5445 o U Server platforms that run the product 5446 o U Client platforms supported 5447 o U Accreditation or approval 5448 o U Price and maintenance costs 5449 o U Number of users or connections supported 5450 5451 5452 5453 5454 5455 5456 5457 5458 5459 5460 5461 5462 5463 5464 2 3 3 2 2 1 3 2 1 U Implementation Issues U FOUO Commercial venders have VPN capabilities built into firewall gateway or router products There are currently dozens of different COTS VPN products available today These products range from supporting small business connections to supporting large organizations requiring thousands of connections Many vendors have a family of VPN products that support the different ranges of user needs Some products support modular upgrades and have integrated hardware VPN acceleration capabilities delivering highly scalable high-performance VPN services U FOUO As the VPN products have advanced their configuration and administration has become easier Configuration and management tools have been created to make the establishment administration and monitoring of VPN clients and networks easier to perform Some products advertise a One-click VPN where VPNs can be created with a single operation by using VPN communities As new members are added to the community they automatically inherit the appropriate properties and can immediately establish secure IPsec IKE sessions with the rest of the VPN community 5468 U FOUO IPsec is still the most popular protocol for performing VPN security but SSL has been gaining support in the last few years Many VPN vendors now support both protocols in either the same product or as a separate item One advantage of SSL over IPsec is that SSL does not require special VPN client software on remote PCs which reduces administrative costs 5469 U VPN Products 5470 U There are many COTS VPN products The following is a list of some of the VPN products available today 5465 5466 5467 5471 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-70 UNCLASSIFIED FOR OFFICIAL USE ONLY o 5474 U Cryptek's DiamondTEK has been evaluated and validated in accordance with the provisions of the NIAP Common Criteria Evaluation and Validation Scheme and the Common Criteria Recognition Arrangement as a EAL4 product - 5475 http www cryptek com SecureNetworks 5472 5473 5476 o U Blue Ridge Networks' VPN CryptoServer is also on the Common Criteria validated products list EAL2 - http www blueridgenetworks com o U Check Point's VPN-1 Pro product line is an integrated VPN and firewall gateway which offers management capability attack protection and traffic shaping technology http www checkpoint com products index html o U Nortel Networks Contivity is a line of VPN switches and gateways with supporting configuration and management tools http www nortelnetworks com products family contivity html o U Cisco PIX Security Appliances support hardware and software VPN clients as well as PPTP and L2TP clients http www cisco com en US products hw vpndevc index html o U SafeNet's HighAssurance TM Gateway product lines provide IPsec VPN solutions for small to large customers SSL VPN also supported - http www cylink com o U Avaya Secure Gateway products have specialized support for voice-over-IP VoIP applications - http www1 avaya com enterprise vpn sg203_sg208 o U Symantic Gateway supports both IPsec and SSL based VPN products http enterprisesecurity symantec com content productlink cfm EID 0 o U SonicWall has firewall and gateway products that feature IPsec VPN security http www sonicwall com products vpnapp html o U ADTRAN's NetVanta 2000 Series is a family of VPN firewall appliances http www adtran com o U ArrayNetworks Array SP family of appliances offers SSL VPNs http www arraynetworks net globalaccess htm o U Celestix's RAS3000 supports SSL VPN for Microsoft Exchange Server 2003 http www celestix com products ras ras3000 sslvpnforexchange htm o U Lucent Technologies Access Point R supports routing secure VPN QoS firewall security and policy management - http www lucent com solutions o U Juniper Networks Netscreen SSL VPNs provide a broad range of SSL VPN appliances - http www juniper net products ssl o U V-ONE produces both IPsec and SSL VPN products - http www v-one com 5477 5478 5479 5480 5481 5482 5483 5484 5485 5486 5487 5488 5489 5490 5491 5492 5493 5494 5495 5496 5497 5498 5499 5500 5501 5502 5503 5504 5505 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-71 UNCLASSIFIED FOR OFFICIAL USE ONLY 5506 5507 5508 5509 5510 5511 5512 5513 5514 5515 5516 5517 5518 5519 5520 5521 5522 5523 5524 5525 5526 5527 5528 5529 5530 5531 5532 2 3 3 2 2 1 3 2 2 U Advantages U FOUO VPNs provide economical and secure solutions for remote access users mobile users and telecommuters intranets site-to-site connections within a company or organization and extranets organization to organization network connections to suppliers customers or partners 2 3 3 2 2 1 3 2 3 U Risks Threats Attacks U FOUO VPN clients should not be able to access your private network and the Internet at the same time Doing so can be a security risk if the VPN client can become a gateway between the Internet and the private network U FOUO PPTP authentication dependence on Microsoft Challenge Handshake Authentication Protocol MSCHAP makes it vulnerable to attacks using a hacker tool called l0phtcrack U FOUO Nearly all computer equipment is susceptible to Distributed Denial of Service DDoS attacks The Corrent Corporation's S3500 Turbocard Firewall VPN accelerator is one VPN product that can withstand a massive DDoS attack while keeping valid network traffic flowing at a high rate The new Corrent R S3500 Turbocard is able to sustain 50 000 TCP sessions per second and deliver 648 Megabits per second in throughput in the face of a concentrated attack 2 3 3 2 2 1 3 3 U Maturity U FOUO VPNs are a mature technology in the commercial world and continue to evolve Products continue to support additional protocols and algorithms and run on more and more different platforms U FOUO Interoperability between different manufacturers has seen significant improvements over the last few years but interoperability issues still exist U FOUO VPNs are Mature TRLs 7 - 9 Interoperability between different manufacturers and platforms should continue to move forward 2 3 3 2 2 1 3 4 U Standards U FOUO Table 2 3-10 identifies the standards applicable to VPN technology UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-72 UNCLASSIFIED FOR OFFICIAL USE ONLY Table 2 3-10 U FOUO Standards Applicable to VPN Technology 5533 This table is U Number RFC-2401 Title Security Architecture for the Internet Protocol http www ietf org rfc rfc2401 txt http www ietf org internet-drafts draft-ietf-ipsec-rfc2401bis-02 txt RFC-2402 IP Authentication Header http www ietf org rfc rfc2402 txt http www ietf org internet-drafts draft-ietf-ipsec-rfc2402bis-07 txt RFC-2406 IP Encapsulating Security Payload ESP http www ietf org rfc rfc2406 txt http www ietf org internet-drafts draft-ietf-ipsec-esp-v3-08 txt Date November 1998 April 2004 November 1998 March 2004 November 1998 March 2004 The SSL Protocol Version 3 0 http wp netscape com eng ssl3 ssl-toc html November 1996 RFC 3031 Multiprotocol Label Switching Architecture http www ietf org rfc rfc3031 txt January 2001 RFC 2661 Layer Two Tunneling Protocol L2TP http www ietf org rfc rfc2661 txt August 1999 RFC 2637 Point-to-Point Tunneling Protocol PPTP http www ietf org rfc rfc2637 txt July 1999 VPN Protection Profile for Protecting Sensitive Information http www iatf net protection_profiles file_serve cfm chapter vpn_pp pdf February 2000 This table is U 5534 5535 5536 5537 5538 5539 5540 2 3 3 2 2 1 3 5 U Cost Limitations U FOUO Most VPN products have a maximum connection number So before purchasing a VPN product you must determine the maximum number of VPN connections you expect to have 2 3 3 2 2 1 3 6 U Alternatives U FOUO There are several alternatives to VPN security of information over an untrusted network o U FOUO FNBDT application layer security can be used to provide end-to-end protection for secure voice traffic o U FOUO Sub-network layer security can be used to protect information as it crosses a sub-network Sub-network layer security allows black side switches but still requires all IP routers to be red For example the CANEWARE Front End had a mode where it encrypted the payload of X 25 packets A more modern example is FASTLANE which provides payload security for ATM cells 5541 5542 5543 5544 5545 5546 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-73 UNCLASSIFIED FOR OFFICIAL USE ONLY 5547 5548 o U FOUO Security is also possible over SONET using the KG-189 to provide security of the SONET payload 5550 2 3 3 2 2 1 3 7 U References U http www cryptek com SecureNetworks 5551 U http www blueridgenetworks com 5552 U http www checkpoint com products index html 5553 U http www nortelnetworks com products family contivity html 5554 U http www cisco com en US products hw vpndevc index html 5555 U http www cylink com 5556 U http www1 avaya com enterprise vpn sg203_sg208 5557 U http enterprisesecurity symantec com content productlink cfm EID 0 5558 U http www sonicwall com products vpnapp html 5559 U http www adtran com 5560 U http www arraynetworks net globalaccess htm 5561 U http www celestix com products ras ras3000 sslvpnforexchange htm 5562 U http www lucent com solutions 5563 U http www juniper net products ssl 5564 U http www v-one com 5565 U Security Architecture for the Internet Protocol - http www ietf org rfc rfc2401 txt and http www ietf org internet-drafts draft-ietf-ipsec-rfc2401bis-02 txt 5549 5566 5567 5568 U IP Authentication Header - http www ietf org rfc rfc2402 txt and http www ietf org internetdrafts draft-ietf-ipsec-rfc2402bis-07 txt 5570 U IP Encapsulating Security Payload ESP - http www ietf org rfc rfc2406 txt and http www ietf org internet-drafts draft-ietf-ipsec-esp-v3-08 txt 5571 U The SSL Protocol Version 3 0 - http wp netscape com eng ssl3 ssl-toc html 5572 U Multiprotocol Label Switching Architecture - http www ietf org rfc rfc3031 txt 5573 U Layer Two Tunneling Protocol L2TP - http www ietf org rfc rfc2661 txt 5569 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-74 UNCLASSIFIED FOR OFFICIAL USE ONLY 5574 U Point-to-Point Tunneling Protocol PPTP - http www ietf org rfc rfc2637 txt 5575 U VPN Protection Profile for Protecting Sensitive information http www iatf net protection_profiles file_serve cfm chapter vpn_pp pdf 5576 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-75 UNCLASSIFIED FOR OFFICIAL USE ONLY 5577 2 3 3 2 2 2 U Real-Time Data Technologies 5578 2 3 3 2 2 2 1 U Secure VoIP Call Control U FOUO Secure VoIP Call Control addresses technologies used to protect the signaling plane or VoIP call establishment protocols Secure VoIP technologies that focus on the voice packets are described in the previous secure VoIP section 5579 5580 5581 5582 5583 5584 5585 5586 5587 U FOUO Note that Secure VoIP call control mechanisms may be considered part of network management and control technologies within the GIG Further information on VoIP call controls from the view of network security may be addressed in the GIG network control technology section This section concerns itself with the protection of user information that is potentially vulnerable when using VoIP call control This section also complements the secure VoIP section that describes methods to secure user voice 5590 2 3 3 2 2 2 1 1 U Technical Detail U FOUO A brief introduction to VoIP call control is presented followed by a description of security mechanisms that can be used to secure call control 5591 U The most common call control protocols used in VoIP system today include 5588 5589 5592 o U Session Initiation Protocol SIP 5593 o U H 323 5594 o U Media Gateway Control Protocol MGCP 5595 o U Gateway Control Protocol GCP formerly MEGACO and H 248 5596 5597 5598 5599 5600 5601 5602 5603 5604 5605 5606 5607 5608 5609 5610 5611 5612 5613 U In the spirit of distributed call control rather than centralized integrated call managers the IETF has decomposed gateways into Media Gateway Controllers and Media Gateways As such MGCP and GCP are protocols that can be used when PSTN-VoIP Gateways PSTN-VoIP GWs and multi-media conference units are decomposed between control and media processing units This document does not address MGCP and GCP security mechanisms It is assumed that GW control and processing units are integrated or collocated within a single security domain such that security mechanisms do not need to be applied to MGCP or GCP Commercial IPsec or TLS could be used to secure these protocols within a single security domain if needed U FOUO VoIP networks also require a QoS architecture designed to support the voice service As such secure mechanisms for the GIG QoS architecture needs to be developed as a complementary technology for secured voice GIG secure VoIP call control and secure QoS mechanisms may likely need to work with each other possibly thorough a network interface Secure QoS security mechanisms are beyond the scope of this section U FOUO Priority of Service PoS is another important voice feature This feature allows users to pre-empt other voice calls or be placed in a higher priority queue for call processing The GIG secure VoIP call control will need to request or invoke priority of service and therefore is likely to interact with GIG PoS security mechanisms PoS security mechanisms are beyond the scope of this section UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-76 UNCLASSIFIED FOR OFFICIAL USE ONLY 5620 U FOUO Also note that the GIG VoIP call control architecture will need to include a dialing plan that not only includes SIP and H 323-based user identities but also users on non-GIG networks expected to conform to E 164 numbering plans This implies directory service techniques such as Electronic Numbering ENUM As such GIG directory services that provide VoIP calling plans will need to be secured The VoIP call control security mechanisms will need to interact with the security mechanisms of these directory services GIG directory service security technologies are beyond the scope of this section 5621 U Therefore this section focuses on SIP and H 323 as addressed below 5622 U SIP 5623 U SIP is a text based client server protocol that can establish modify and terminate multimedia sessions conferences or Internet telephony calls SIP can invite participants to unicast and multicast sessions An initiator does not necessarily have to be a member of the session to which it is inviting and new media streams and participants can be added to an existing multi-media session It can establish modify and terminate multimedia sessions or calls such as conferences Internet telephony and similar applications SIP enables VoIP gateways client end points Private Branch Exchanges PBX and other communications systems and devices to communicate with each other 5614 5615 5616 5617 5618 5619 5624 5625 5626 5627 5628 5629 5630 5633 U SIP transparently supports name mapping and redirection services allowing the implementation of Intelligent Network telephony subscriber services These facilities also include mobility that allows the network to identify end users as they move 5634 U SIP supports five facets of establishing and terminating multimedia communications 5631 5632 5635 o U User location determination of the end system to be used for communication 5636 o U User capabilities determination of the media and media parameters to be used 5637 o U User availability determination of the willingness of the called party to engage in communications 5639 o U Call setup ringing establishment of call parameters at both called and calling party 5640 o U Call handling including transfer and termination of calls 5638 5644 U SIP does not offer conference control services such as floor control or voting and does not prescribe how a conference is to be managed but SIP can be used to introduce conference control protocols SIP does not allocate multicast addresses and does not reserve network resources 5645 U SIP network elements are shown in Figure 2 3-20 and described below 5641 5642 5643 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-77 UNCLASSIFIED FOR OFFICIAL USE ONLY Public or Private IP network FIREWALL IP GW SIP Registrar with Location Services Circuit Switched Networks PSTN ISDN wireless SIP Proxy Server PSTN GATEWAY SIP TERMINAL This figure is U 5646 5647 Figure 2 3-20 U SIP Architecture 5648 U USER AGENT The user agent shown here as a client accepts requests from a user and provides the appropriate SIP messages or receives SIP messages and provides appropriate responses to the user It is the SIP end point in the network Examples for such a user agent might be an SIP-enabled PC or a SIP-enabled UMTS mobile device Gateways can also act as SIP user agents for example a VoIP SIP phone calling a POTS line will connect to the PSTN via a VoIP GW The VoIP GW then provides the SIP endpoint or user agent for the POTS line 5649 5650 5651 5652 5653 5654 5655 5656 5657 5658 5659 5660 5661 5662 5663 5664 5665 5666 5667 5668 5669 U REGISTRAR The SIP Registrar is a server that receives registration requests from USER AGENTS in order to keep a current list of all SIP users and their location which are active within its domain network A registrar is typically collocated with a proxy or redirect server U LOCATION SERVICES Location services find the location of a requested party in support of SIP based mobility For example when a SIP agent places a session or call request to another network user the SIP location server will find the domain in which the second party was last registered When found the SIP request SIP INVITE to the session will be forwarded to the appropriate domain U PROXY SERVER The proxy server is an intermediate device that receives SIP requests from a user agent and then forwards the requests on the client's behalf The proxy server can stay in a signaling path for the duration of the session Proxy servers can also provide functions such as authentication authorization network access control routing reliable request retransmission and security Equally important the proxy server can be used by the network to execute a range of supplementary services Soft switches for example may use the SIP proxy as a way to interface the call or session model to the user agent In the VoIP world call forwarding on busy can be implemented and invoked in the proxy server UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-78 UNCLASSIFIED FOR OFFICIAL USE ONLY 5674 U RE-DIRECT SERVER The re-direct server provides the client with information about the next hop or hops that a message should take and then the client contacts the next hop server or user agent directly Unlike the use of a proxy server the re-direct server simply serves to direct on-going communications at session initiation but does not stay in the signaling path for the duration of the data session 5675 U SIP Security Mechanisms 5676 5686 U The SIP RFCs describe a number of security mechanisms that can be used within a SIP system Message authentication and encryption of SIP messages are supported Since SIP uses proxy servers and registrars in support of service execution on behalf of the user SIP assumes security associations between the SIP client and various SIP infrastructure elements rather than secured end-to-end call control security between voice users This of course means that all SIP servers need to be trusted network elements As such all SIP call control is assumed to be located within a single security domain IPsec can be used to tunnel SIP call control from SIP clients to SIP servers across backhaul networks that may be outside the SIP security domain Note that SIP is a text-based protocol borrowing many elements from other text based protocols such as HTTP As such SIP security reuses HTTP and MIME security mechanisms as explained below Note that PGP is not longer recommended in the latest SIP RFC 5687 U The following encryption scenarios are identified in the SIP RFCs 5670 5671 5672 5673 5677 5678 5679 5680 5681 5682 5683 5684 5685 o U A network can use lower layer security protocols such as IPsec or TLS between the SIP UA and SIP server Although many implementations transport SIP with UDP SIP can also be transported with TCP so that TLS can be used 5691 o U TLS can be used between servers 5692 o U S MIME techniques can be used to encrypt SIP bodies for end-to-end security of the SIP message payload while leaving SIP headers in the clear for server support S MIME also provides for integrity and supports mutual authentication Note that this method does offer protection of user network address or URI information Furthermore specific applications of SIP servers can offer the user a number of network enabled services The set of services offered by these kinds of SIP servers may be restricted if the SIP message body is opaque to the SIP server 5688 5689 5690 5693 5694 5695 5696 5697 5698 5699 5700 5701 5702 5703 5704 5705 5706 5707 U FOUO SIP includes basic password authentication mechanisms as well as digest based mechanisms The SIP protocol includes messages that facilitate authentication For example SIP protocol specific authentication challenge messages Response 401 Unauthorized or Response 407 Proxy Authentication Required can be used in conjunction with a cryptographic mechanism The Digest authentication mechanisms called out by the SIP RFCs are based upon HTTP authentication U SIP also defines option mechanisms to convey user privacy requirements Finally SIP extensions are identified for media and QoS authorization as a means of protecting against DoS attacks UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-79 UNCLASSIFIED FOR OFFICIAL USE ONLY 5708 U A Brief Overview of H 323 5709 U H 323 from the ITU is binary based ASN 1 and provides for both signaling plane messaging as well as signaling to bearer control Because it was initially designed to support video packets H 323 has considerable overhead which is a disadvantage for IP telephony applications 5710 5711 5712 5713 5714 5715 5716 5717 5718 5719 U Note that H 323 is an umbrella specification covering several protocols related to call setup and signaling Chief among these are H 225 which defines the call signaling channel H 245 or the call control channel and RAS - registration admission status Underlying these are the Real Time Transport Protocol RTP and or the Real Time Control Protocol RTCP which define the basic requirements for transporting real time data over a packet network U The H 323 architecture and components are introduced in Figure 2 3-21 and summarized below Public or Private IP network MCU FIREWALL IP GW Circuit Switched Networks PSTN ISDN wireless GATEKEEPER PSTN GATEWAY H 323 TERMINAL This figure is U 5720 Figure 2 3-21 U H 323 Network Elements 5721 5722 U Gatekeeper 5723 o U Manages an H 323 zone or network collection of H 323 devices 5724 o U Supports address translation access and admissions control bandwidth control and allocation o U Optional functionality includes call authorization supplementary services directory services call management services 5725 5726 5727 5728 U Gateway UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-80 UNCLASSIFIED FOR OFFICIAL USE ONLY o U The Gateway provides interoperability between different networks by converting signaling and bearer between as an example IP and circuit-based networks 5731 o U H 323 Terminal 5732 o U The Terminal is the H 323 signaling endpoint client on an IP network 5733 o U Supports real-time 2-way communications with another H 323 entity Must support voice audio codecs and signaling Q 931 H 245 RAS Optionally supports video and data e g PC phone or videophone Ethernet phone 5729 5730 5734 5735 5736 U Multipoint Control Unit MCU 5737 o U The MCU supports conferences between 3 or more endpoints 5738 o U The MCU must contain multi-point controller MC for signaling and may contain multi-point processor MP for media stream processing The MCU can be stand-alone or integrated into gateway gatekeeper or terminal 5739 5740 5741 U H 323 Security Framework defined in H 235 5742 U The H 235 standard defines a security framework to be used within H 323 systems H 323 supports a menu of encryption and authentication options are supported Note that H 235 defines security mechanisms between H 323 clients and H 323 call control servers Gatekeepers MCUs Gateways End-to-end call control security between clients is not provided Therefore H 235 requires all H 323 infrastructure elements to be trusted servers The H 245 signaling protocol used within H 323 systems includes methods to negotiate the security algorithms and keys used for a secure call control connection 5743 5744 5745 5746 5747 5748 5749 5750 5751 5752 5753 U H 235 supports DES 3DES and AES encryption algorithms H 235 allows for TLS or IPsec to be used amongst H 323 clients and H 323 call control servers U A variety of authentication options are identified which include HMAC-SMA1-96 Public certificates as well as subscription-based authentication mechanisms can be used Three options for subscription-based authentication are identified specifically 5754 o U Password-based with symmetric encryption shared secret 5755 o U Password-based with hashing 5756 o U Certificate based subscriptions with digital signatures 5761 U Key management is incorporated into the H 323 family of signaling specifications H 235 describes the use of H 245 signaling protocol messages for key management The use of H 323 RAS protocol for key management has been identified in the specification but is not completely defined Third party key escrow schemes are described and Diffe-Hellman can be use for key agreements 5762 U This menu of security options is organized within three security profiles as listed below 5757 5758 5759 5760 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-81 UNCLASSIFIED FOR OFFICIAL USE ONLY o U The Basic security profile employs user passwords as part of the authentication approach 5765 o U An optional Digital Signature profile utilizing certificates 5766 o U A Hybrid profile that combines elements of Basic and Digital Signature 5763 5764 5767 5768 U H 235 also describes secure call control consideration in the presence of firewalls and Network Address Translation devices 5772 U Finally H 235 also references H 510 and H 530 which together describe security mechanisms for mobility across H 323 systems These specifications describe a generic security concept for mobility among domains Hop-by-hop security with shared secrets is employed to protect call control 5773 2 3 3 2 2 2 1 2 U Usage Considerations 5774 2 3 3 2 2 2 1 2 1 U Implementation Issues U Call Control Environment 5769 5770 5771 5775 5784 U FOUO Since both SIP and H 323 security measures rely upon trusted call control network elements to complete call processing the VoIP call control will need to reside within a single security domain Furthermore SIP and H 323 security mechanisms are not type 1 and do not lend themselves to existing type 1 solutions Therefore other security mechanisms such as HAIPEs are required to transport call control across security domain boundaries For example Secure SIP mechanisms at the session layer can be used amongst devices within the security domain Clients roamed onto other security domains can use HAIPEs to tunnel back into the security domain to join VoIP calls using the SIP security As such the client would apply SIP security over HAIPEs security for the call control 5785 U Clear - Secure Transitions 5786 5788 U FOUO Note that the ability to transition between clear and secure voice is an important security feature for voice services As such the GIG VoIP architecture needs to allow for a transition between clear and secure voice media types within a single call 5789 U Multiple call control systems and user mobility 5790 U FOUO Since SIP and H 323 need to reside in a single security domain it is conceivable that a SIP client may need to operate with a number of call control managers depending upon the security domain of other call participants For example a user may need to register on the GIG VoIP call control manager for communications with on-GIG users and another call control manager to communicate with a non-GIG or coalition user This means that user mobility may need to be tracked in multiple call control planes based upon security domain 5776 5777 5778 5779 5780 5781 5782 5783 5787 5791 5792 5793 5794 5795 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-82 UNCLASSIFIED FOR OFFICIAL USE ONLY 5796 U Security technologies within the call control environments 5797 U SIP security 5798 5803 U FOUO The SIP security RFCs call out a menu of security options Therefore the GIG security architecture will need to standardize on a specific SIP security profile to ensure interoperability This is especially important since call control needs to pass through a chain of trusted clients and trusted call control network elements servers in order to place a VoIP call Furthermore non-GIG networks may use other SIP security profiles requiring GIG clients to support additional security mechanisms when communicating with non-GIG users 5804 U FOUO SIP interaction with IPv6 firewalls is not clearly defined and needs to be studied 5805 5807 U FOUO Note that many VoIP networks place SIP on top of UDP But TLS forces SIP to be placed on TCP reducing the efficiency of the protocol in comparison with UDP-based approaches IPsec may be more efficient alternative to TLS in this case 5808 U H 323 security 5809 U FOUO The implementation of H 323 security shares much of the same concerns as SIP security H 323 offers a wide variety of security mechanisms within three profile types The GIG security architecture will need to standardize on a specific set of security functions for interoperability Although H 235 does address interaction with IPv4 firewalls IPv6 firewall interaction requires further study 5799 5800 5801 5802 5806 5810 5811 5812 5813 5814 5815 U Unlike SIP H 323 was originally designed for TCP so the use of TLS amongst clients and servers fits well within the H 323 system 5818 2 3 3 2 2 2 1 2 2 U Advantages U SIP security mechanisms fit well within a VoIP architecture and reuse many techniques from HTTP and S MIME security 5819 U H 323 security is flexible and like SIP is intended to fit well within VoIP architectures 5820 2 3 3 2 2 2 1 2 3 U Risks Threats Attacks U FOUO The SIP RFCs declare SIP to be difficult to secure SIP security requires trusted SIP infrastructure proxies registrars etc and hop-by-hop security mechanisms such as TLS to avoid security risks Even so SIP security features are not type 1 and would need to be extended to support type 1 techniques This limits SIP to reside within a single security domain 5816 5817 5821 5822 5823 5824 5825 5826 5827 5828 5829 5830 U FOUO As with SIP H 323 requires trusted call control infrastructure and hop-by-hop security to avoid security risks Although H 235 describes a number of possible non-repudiation techniques the overall topic of non-repudiation is listed for further study in the specification Further security evolution is likely As with SIP H 323 is not defined to support type 1 security and would need to be extended to do so This limits H 323 to reside within a single security domain UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-83 UNCLASSIFIED FOR OFFICIAL USE ONLY 5831 5832 5833 5834 5835 5836 5837 5838 5839 2 3 3 2 2 2 1 3 U Maturity U FOUO Although some of the security techniques SIP leverages are well known and have deployed in commercial networks the overall SIP security is immature and not widely used Therefore SIP Security as defined in the RFCs is Emerging with an estimated TRL of 5 U FOUO Similar to SIP many of the H 323 security mechanism are used in deployed networks But the overall H 235 security framework is not widely used in VoIP networks As such H 235 is also Emerging with an estimated TRL of 5 2 3 3 2 2 2 1 4 U Standards U Table 2 3-11 summarizes the standards relevant to secure VoIP call control Table 2 3-11 U Secure VoIP Call Control Standards 5840 This table is U Name H 235 H 245 H 323 H 510 H 530 RFC 3262 RFC 3310 RFC 3313 RFC 3323 RFC 3325 RFC 3329 RFC 3435 RFC 3525 RFC 3761 RFC 3762 RFC 3853 5841 5842 5843 5844 5845 5846 Description Security and encryption for H-series multimedia terminals Call Control Protocol for multimedia communication Series H Packet-based multimedia communications Series H Mobility for H 323 multimedia systems and services Symmetric security procedures for H 323 mobility in H 510 SIP Session Initiation Protocol HTTP Digest Authentication Using Authentication and Key Agreement AKA Private SIP Extensions for Media Authorization A Privacy Mechanism for the SIP Private Extensions to the SIP for Asserted Identity within Trusted Networks Security Mechanism Agreement for the SIP Media Gateway Control Protocol Gateway Control Protocol The E 164 to Uniform Resource Identifiers URI Dynamic Delegation Discovery System DDDS Application ENUM Telephone Number Mapping ENUM Service Registration for H 323 S MIME Advanced Encryption Standard AES Requirement for the Session Initiation Protocol SIP This table is U 2 3 3 2 2 2 1 5 U Cost Limitations U FOUO SIP and H 323 security mechanisms require trusted call control network elements restricting application of SIP and H 323 security to within a single security domain Lower layer security such as HAIPE is required to tunnel SIP across security domain boundaries These multiple layers of security add complexity to client call control processing and may help increase costs UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-84 UNCLASSIFIED FOR OFFICIAL USE ONLY 5847 5848 5849 5850 5851 5852 5853 5854 5855 5856 5857 5858 5859 5860 5861 5862 5863 5864 5865 5866 5867 5868 5869 U FOUO Note that there is no method defined to provide protection of circuit-based signaling Therefore any protection offered SIP or H 323 would terminate at a VoIP-circuit signaling gateway 2 3 3 2 2 2 1 6 U Dependencies U FOUO The level of trust of any proxy within the call control chain for either SIP or H 323 call control may impact RAdAC and policy enforcement U FOUO The GIG key management architecture will need to take into account SIP and H 323 key management requirements Although SIP does not specify key management systems H 245 does include key manage messages U FOUO The security mechanism of a VoIP architecture will likely need to interact with the security mechanisms applied to the GIG QoS and PoS architectures U FOUO Also note that GIG directory services will need to accommodate GIG and off GIG 'dialing plans' to support VoIP call control The protection of these directory services and VoIP call control security will need to interact and be coordinated within the GIG architecture 2 3 3 2 2 2 1 7 U Alternatives U FOUO HAIPE could be applied not only to tunnel SIP across security domains but could also be used to protect call control within a single domain A HAIPE tunnel could be applied between clients and servers and between servers 2 3 3 2 2 2 1 8 U Complementary Techniques U FOUO Protection of QoS protection of PoS protection of directory services and the use of HAIPEs to span security domains are complementary technologies to secure VoIP call control U FOUO A secure key management system that accommodates VoIP call control security mechanisms is also a complementary technology UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-85 UNCLASSIFIED FOR OFFICIAL USE ONLY 5870 2 3 3 2 3 U Link Physical Layer Technologies 5871 2 3 3 2 3 1 U Anti-Jam U EDITOR'S NOTE MATERIAL ON ANTI-JAM WILL BE ADDED IN A FUTURE RELEASE 5872 5873 5874 5875 5876 5877 5878 2 3 3 2 3 2 U Link Encryption U EDITOR'S NOTE MATERIAL ON LINK ENCRYPTION WILL BE ADDED IN A FUTURE RELEASE IT WILL ADDRESS IMPLICATIONS OF EXPANDING LINK ENCRYPTIONS CAPABILITIES TO MEDIUM AND LOW ASSURANCE LINKS 2 3 3 2 3 3 U TRANSEC U EDITOR'S NOTE MATERIAL ON TRANSEC WILL BE ADDED IN A FUTURE RELEASE UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-86 UNCLASSIFIED FOR OFFICIAL USE ONLY 5879 2 3 3 3 U Trusted Platforms 5880 2 3 3 3 1 U Technical Detail 5881 2 3 3 3 1 1 U Definition U A trusted platform is a GIG component that is relied upon to enforce its security policy That is it has been assigned a set of security rules to enforce its policy and is relied upon to enforce those rules No other GIG component will prevent a violation of the security policy if the trusted platform is subverted successfully attacked or otherwise fails to act appropriately 5882 5883 5884 5885 5886 5887 5888 5889 5890 5891 5892 5893 5894 5895 5896 5897 5898 5899 5900 5901 5902 5903 5904 5905 5906 5907 5908 5909 5910 5911 5912 5913 5914 5915 U By contrast an untrusted platform is not relied upon to enforce any specific policy It is prevented from harming the GIG or its users by other trusted platforms U The security policy enforced by a given trusted platform can vary In the 1980s a trusted platform was considered to be one that could enforce a multilevel security policy See TCSEC for technical details That is one could have information at different classification levels e g SECRET information and TOP SECRET information on the system at the same time and possibly have users with different clearances accessing the system at the same time And one could have some appropriate level of confidence that a confidentiality policy would be correctly enforced Examples that TOP SECRET information would not be disclosed directly or indirectly to a user with only a SECRET clearance or that TOP SECRET and SECRET information would not be co-mingled in a file labeled SECRET There might also be an integrity policy of some sort enforced e g it might be prohibited for a SECRET user to modify or delete a TOP SECRET file U FOUO With the GIG's Task Post Process Use TPPU model and different operational networking scenarios the definition of a trusted platform has been expanded from this previous meaning It now has the more generic meaning given above that is a trusted platform enforces whatever security policy it has been assigned It does not have to be a traditional multilevel security policy Some trusted platforms enforce MILS policies These policies allow the platform to be used for different levels of security at different times--while restricting use to one level at any given time For example a device could be used to connect to an unclassified network and process unclassified information and then later be used to connect to a classified command and control network and process SECRET information U FOUO The concept of MILS is similar to the traditional periods processing operations of processing one security level of information wiping the system of any information e g by removing disks tapes etc and then reloading it to process another level of information However it is not acceptable to have to physically change a GIG component e g to remove a SECRET hard drive and replace it with an UNCLASSIFIED hard drive given the need for network connectivity and communications Thus a MILS system must enforce a security policy that separates information and grants access appropriately while not requiring significant reconfiguration UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-87 UNCLASSIFIED FOR OFFICIAL USE ONLY 5916 5917 5918 5919 5920 5921 5922 5923 5924 5925 5926 5927 5928 5929 5930 5931 5932 5933 5934 5935 5936 5937 5938 5939 5940 5941 5942 5943 5944 5945 5946 5947 5948 5949 5950 5951 U Trusted platforms have two types of mechanisms functions and assurances Functions are the things that the platform actually does to enforce its security policy Typical security functions in a trusted platform include identification and authentication of users access controls and auditing of security relevant events U Assurance mechanisms are things used during the development and operation of the trusted platform to gain confidence that it actually will work correctly in its intended environment and that it will not have hidden undocumented or unintended features that will allow the security functions to be subverted Assurance mechanisms that can be used for trusted platforms include things like mapping levels of specification to determine consistency in the development of the platform adherence to software development standards and practices and testing U The earliest work in trusted platforms was carried out from the late 1960's to the early 1980's It led to the DoD Trusted System Evaluation Criteria TCSEC which was the DoD standard from 1985 until the late 1990s Work from other organizations such as NIST and other countries such as Canada which published its own Canadian Trusted Computing Platform Evaluation Criteria and the United Kingdom Germany France and the Netherlands which jointly published the Information Technology Security Evaluation Criteria led to the development during the 1990s of the harmonized Common Criteria encapsulated in ISO Standard 15408 volumes 1-3 The Common Criteria CC are recognized by at least 20 countries including the U S and evaluation of a product against the Common Criteria is required now for use in most DoD programs U The CC intend for an organization for example an industry standards group or an organization interested in acquiring trusted platforms to publish a Protection Profile A Protection Profile is a set of security functions drawn from ISO 15408 volume 2--combined with a set of required assurance mechanisms drawn from ISO 15408 volume 3 It represents the set of requirements that a category of IT products must meet to be useful and secure For example there is a Protection Profile covering Multilevel Operating Systems in Environments Requiring Medium Robustness This would be for any operating system that is to be used in multilevel secure operations in environments where threats are non-trivial but not severe must meet the requirements contained in that protection profile Customers attempting to deploy systems in those environments should not use systems that have not been successfully evaluated against that Protection Profile U The CC evaluation scheme does allow for the evaluation of products even when there is no established Protection Profile The vendor publishes a Security Target which is a description of the security properties and capabilities of the product and the product is evaluated against that Security Target Potential customers can then review the Security Target to determine if the product is useful in their solutions UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-88 UNCLASSIFIED FOR OFFICIAL USE ONLY 5952 5953 5954 5955 5956 5957 5958 5959 5960 5961 5962 5963 5964 5965 5966 5967 5968 5969 5970 5971 5972 5973 5974 5975 5976 5977 5978 5979 5980 5981 5982 5983 5984 5985 5986 5987 5988 5989 5990 5991 U The functional and assurance mechanisms covered in ISO 15408 are largely independent However some dependencies are known to exist Some of these exist because it is not possible to implement one function without another one e g mandatory access controls cannot be enforced unless data objects are appropriately tagged labeled Others exist because the approximately 30 years of experience in this area indicates that they provide equivalent and compatible security In ISO 15408-2 dependencies among the functional requirements are identified and Protection Profiles that include a given requirement must also include all requirements on which the initial one depends U For the convenience of users the assurance mechanisms in ISO 15408-3 have been grouped in a set of seven levels referred to as Evaluated Assurance Level EAL --1 the lowest through EAL-7 the highest The intent is that each EAL-value describes a system that is usable in a specific type of environment EAL-1 products tend to be appropriate in environments in which there is little to no threat EAL-7 products are designed to stand up to the most rigorous threat environments known 2 3 3 3 1 2 U Components U FOUO A trusted platform consists of hardware software and the guidance and procedures that go into using it A trusted platform may be a COTS product as most GIG components are expected to be or it may be custom-designed device U FOUO Security policy enforcement can be apportioned among the components of a trusted platform in any way the developer wishes Typically in a commercial trusted operating system little to no enforcement is assigned to the hardware all of the explicit enforcement functions are put into software The hardware is merely relied upon to operate correctly i e to operate in accordance with its specifications without having any ways in which the software policy enforcement can be avoided or prevented For other solutions--including most Governmentprovided Information Assurance assets--the hardware is explicitly assigned security policy enforcement responsibilities such as cryptography tamper resistance etc U FOUO Trusted platforms must also include guidance procedures for their assumed environments For example most commercial products do not offer strong tamper resistance They are assumed to operate in environments in which modification or replacement of the hardware is prevented by physical and procedural security means Operating a trusted platform outside of its assumed environment tends to negate the basis for trust in the system Thus guidance procedures must be clear 2 3 3 3 1 3 U Minimal Requirements U FOUO The requirements for specific trusted platforms to be used in the GIG will vary according the specific functions roles and security policies of those platforms However there is a set of functions that must be supported in all cases for a platform to be considered trusted This set includes o U FOUO Identification and authentication of users subjects and objects Different users of the system must be identified and authenticated Other parts of the system--e g processes running as subjects information objects contained within it--must be UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-89 UNCLASSIFIED FOR OFFICIAL USE ONLY identified and if appropriate authenticated It is important that the identification and authentication mechanisms cannot be subverted or bypassed by attackers The strength of authentication mechanisms used for a specific platform will vary according to its uses For example for some platforms user ids and robust passwords will be sufficient for others biometrics or hardware tokens will be required The strength of authentication mechanism required will generally be specified in the Protection Profile If there is no Protection Profile covering this platform the system engineering or requirements group will have to determine an appropriate level 5992 5993 5994 5995 5996 5997 5998 5999 6000 o U FOUO An ability to securely initiate i e boot the trusted platform It must be possible to boot the system into a known secure state This includes mechanisms that will verify the integrity of the system and its components during the boot process to detect modification tampering For example the trusted platform may need to verify serial numbers or private keys assigned to hardware modules to ensure that they have not been removed or replaced although strategies must exist to replace defective modules with new replacement or upgraded modules Similarly it may be appropriate to digitally sign boot code such as Basic Input-Output System BIOS code to ensure that it has not been modified When using modification-detection routines as part of the secure initialization process it is necessary to ensure that the detection routines themselves cannot easily be defeated As noted though it is still also necessary to allow for required upgrades as well as the replacement of failed modules o U FOUO Partitioning The trusted platform must have the ability to support different processes with different privileges Those processes and the resources they access must be physically or logically partitioned so that one process cannot interfere with or learn information about another process in violation of the security policy Partitioning of the system supports MLS and or MILS operation It can be implemented using a virtual machine architecture in which processes operating at one level are given access to virtual resources rather than the platform's physical resources such as disk space network interfaces etc Partitioning usually requires that the platform have the ability to save process state and to sanitize internal memory It also requires that communications among processes operating at different security levels be controlled--whether simultaneously or at different times since covert channels to leak information often exist in the ways processes interact o U FOUO Access control The trusted platform must have the ability to support an access control policy This policy determines what subjects may access what objects in what contexts and in what modes In traditional MLS operation this policy is label-based and follows the lattice model of security originally described by Bell and LaPadula In MILS operation typically all subjects can access all objects in the virtual machine that represents a single security level but the virtual machine manager tightly controls accesses that cross or go beyond a virtual machine In other operations the policy can be based on integrity models non-interference models or other models In addition discretionary access control policies in which object owners determine access rights can also be enforced 6001 6002 6003 6004 6005 6006 6007 6008 6009 6010 6011 6012 6013 6014 6015 6016 6017 6018 6019 6020 6021 6022 6023 6024 6025 6026 6027 6028 6029 6030 6031 6032 6033 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-90 UNCLASSIFIED FOR OFFICIAL USE ONLY 6034 6035 6036 6037 6038 6039 6040 6041 6042 6043 6044 6045 6046 6047 6048 6049 6050 6051 6052 6053 6054 6055 6056 6057 6058 6059 6060 6061 6062 6063 6064 6065 6066 6067 6068 o U FOUO Auditing The trusted platform must have the ability to track security relevant events that occur on the platform These events will depend on the specific platform environment applications and security policy to be enforced See Section 2 7 of the Technology Roadmap for a description of Audit Management and Section 2 6 of the Technology Roadmap for a description of Computer Network Defense which is closely related to audit and which all trusted platforms must support 2 3 3 3 1 4 U Implementing Trusted Platforms U FOUO There are a number of techniques that can be used to implement the functions of trusted platforms and to provide the assurance levels necessary to achieve the confidence that a trusted platform cannot be subverted These techniques run from stronger policy enforcement mechanisms to implementation and testing techniques that increase confidence that bugs have been found We will address these techniques in this section 2 3 3 3 1 4 1 U Functions U FOUO Trusted platforms must identify and authenticate all users and subjects that access the system before allowing them to take any other security-relevant actions The identification and authentication mechanisms chosen must be of appropriate strength--given the security requirements for the platform and the security mechanisms and assurances implemented for the rest of the system Identification and authentication is discussed in detail in Section 2 1 of this document U FOUO Trusted platforms must generally implement some form of access control This could include one or more of Rule-based or mandatory access control discretionary access control role-based access control or other forms In the future it may be Risk-Adaptable Access Control RAdAC discussed in Section 2 2 U Rule-based or mandatory access control is based on labels or metadata tags associated with subjects and objects It is non-discretionary in that access to an object can only be granted to a subject if the tags associated with the subject and object match according to the established rules Data owners originators cannot change this Typically these access controls are used to implement classification-based access controls e g to ensure that TOP SECRET data objects are only accessed by those with TOP SECRET clearances U FOUO Discretionary access controls allow data object owners to make decisions about whether access is granted to a subject Discretionary access controls provide a flexible mechanism but they are vulnerable to attacks such as Trojan horses in which a program acting as the data owner grant access without the owner's knowledge or approval U FOUO Access controls are discussed in detail in Section 2 2 of the GIG IA Capability Technology Roadmap UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-91 UNCLASSIFIED FOR OFFICIAL USE ONLY 6069 6070 6071 6072 6073 6074 6075 2 3 3 3 1 4 2 U Assurance U FOUO More difficult than implementing functional mechanisms is achieving some level of assurance that is some level of confidence that the trusted platform will actually enforce its security policy and not be vulnerable to attack A number of mechanisms can be used to accomplish assurance some of which are more effective than others U In the Common Criteria ISO 15408-3 assurance mechanisms are divided into seven classes 6076 o U Class ACM Configuration management 6077 o U Class ADO Delivery and operation 6078 o U Class ADV Development 6079 o U Class AGD Guidance documents 6080 o U Class ALC Life cycle support 6081 o U Class ATE Tests 6082 o U Class AVA Vulnerability assessment 6083 6084 6085 6086 6087 6088 6089 6090 6091 6092 6093 6094 6095 6096 6097 6098 6099 6100 6101 6102 U Each of these classes has a number of mechanisms within it Configuration management includes configuration automation scope and management Delivery and operation includes requirements for secure delivery installation day-to-day operation recovery and platform life cycle support Platform developers are required to provide guidance documents for users and operators administrators that describe the intended environment and how to use configure and manage a trusted platform to meet its goals U FOUO Life cycle support mechanisms include requirements for development environment security and for flaw remediation Security of the development environment deals with the likelihood of malicious code or hardware being inserted into a trusted platform during its design and implementation Flaw remediation deals with how a developer addresses security flaws once they are known This includes reporting the flaw to customers developing fixes for it testing those fixes to ensure that they do fix the problem but do not cause additional security issues themselves and distributing the fixes to customers U Testing includes both functional testing e g making sure that a trusted platform meets all of its requirements and independent penetration testing in which a Red Team attempts to attack a platform in an operational-type environment to look for security flaws that the development team did not contemplate This independent testing is expanded in a vulnerability assessment in which a developer and or an independent Red Team analyze a trusted platform and attempt to identify all remaining flaws and vulnerabilities so that informed choices can be made about whether to accept the vulnerabilities or to modify the system or environment to mask them UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-92 UNCLASSIFIED FOR OFFICIAL USE ONLY 6103 6104 6105 6106 U FOUO That leaves the largest and most complex class of assurance mechanisms which are the development mechanisms These are the mechanisms that address how the system is to be designed and implemented They include o U The functional specification of the trusted platform and its interfaces This can be done in an informal style e g written in natural language a formal mathematical way or some combination o U The high-level design of the trusted platform This describes the platform in terms of major subsystems o U The completeness of the implementation representation that is how accurately the completed trusted platform is represented by its documentation o U FOUO The structure and correctness of the internals of the trusted platform This includes requirements for structure and modularity to minimize the number and size of the components that must actually be trusted and allow for full analysis of them There are also requirements for reducing or eliminating circular dependencies and for minimizing non-security-critical code and hardware in security-critical modules The goal is to make the trusted parts of the trusted component as small and simple as possible This leads to components that will be less likely to have buffer overflows incomplete implementations etc o U The low-level design which describes the trusted platform in terms of its component modules their interfaces and dependencies At this level the design of the trusted platform is much more complete and much more representative of what will actually be fielded than is the high-level design described above o U A demonstration of correspondence between the different levels of documentation e g showing that the high-level design and low-level design are consistent with one another and no gaps or major new areas exist in either document o U Security policy modeling The purpose of this mechanism is to develop a model of the security policy to be enforced by the trusted platform and then to demonstrate that that model is actually enforced by the platform specification 6107 6108 6109 6110 6111 6112 6113 6114 6115 6116 6117 6118 6119 6120 6121 6122 6123 6124 6125 6126 6127 6128 6129 6130 6131 6132 6133 6134 6135 6136 6137 6138 6139 U FOUO Together these mechanisms can be used to show that a trusted platform has been built with an acceptable level of confidence that it does not contain security vulnerabilities such as buffer overflows incomplete or ineffective implementations or undocumented features that can be used to defeat security 2 3 3 3 2 U Usage Considerations U FOUO Trusted platforms have been around for more than 20 years However they have enjoyed essentially no success in the general computing field and very little success in specialpurpose processing Largely the reasons for this have been the significant cost of these platforms and their user-unfriendliness UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-93 UNCLASSIFIED FOR OFFICIAL USE ONLY 6140 6141 6142 6143 6144 6145 6146 6147 6148 6149 6150 6151 6152 6153 6154 6155 6156 6157 6158 6159 6160 6161 6162 6163 6164 6165 6166 6167 6168 6169 6170 6171 6172 6173 6174 6175 6176 U FOUO It costs a tremendous amount of money to develop a strongly-secure trusted platform--typically many millions of dollars And there is not now nor has there ever been a significant market for them The market has typically been expressed in terms of thousands of units at best Thus amortizing development costs has resulted in the charge to customers for these devices being many thousands of dollars per copy Faced with this most potential customers have chosen to try to find alternative solutions and new customers have stayed away entirely U FOUO Also because of security restrictions and other design choices trusted platforms generally present markedly different interfaces to users than do more general purpose systems Users quickly become frustrated at slow interfaces limited networking and being unable to do what they are used to do on their home or office computers Even though U S Government policy required the use of a low-level trusted platform for all computers purchased after 1992 they have never caught on and user unhappiness is a major reason why U FOUO With advances in research results and the move away from pure MLS to MILS and other simpler solutions there is a better chance for trusted platforms now than there has been in the past However it will be a challenge for some time 2 3 3 3 2 1 U Implementation Issues U FOUO The biggest implementation issues with trusted platforms are the cost to build and evaluate them and the difficulty in providing an acceptable user interface When used in many environments trusted platforms prevent users from doing things in the way they have always done them often for sound security reasons and thus users will look for ways to circumvent the trusted platform or will choose other platforms entirely 2 3 3 3 2 2 U Advantages U The advantage of a trusted platform is that it allows a single device to be used to handle a variety of different processing needs across security domains As the GIG causes security domains to be brought together into COIs it will be important for some components to have a high level of trust With a trusted component a user can connect to unclassified sites and SECRET sites and TOP SECRET sites with the same device This will lead to better information sharing and a clearer picture of the situation With MLS capability this information can then be shared across users having the same device With a MILS solution this sharing will be more limited but it will still be a substantial improvement over what exists today 2 3 3 3 2 3 U Risks Threats Attacks U FOUO No trusted platform is perfect because we as a community do not have the technology to implement systems without bugs All trusted platforms are subject to some security attacks Some will exploit bugs in the design or implementation others will go around the security policy i e exploit system features that the trusted component was explicitly designed not to protect UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-94 UNCLASSIFIED FOR OFFICIAL USE ONLY 6177 6178 6179 6180 6181 6182 6183 6184 6185 6186 6187 6188 6189 6190 6191 6192 6193 6194 6195 6196 6197 6198 6199 U FOUO The biggest risk in the GIG is that a trusted platform will be relied upon too much GIG security will always require defense-in-depth Trusted platforms will have their roles and they can provide great advantages But they should never be used in environments outside those described in their documentation and they should not be relied upon to provide perfect protection against attacks 2 3 3 3 3 U Maturity Level U FOUO As noted above trusted platforms have been around for more than 20 years For some categories of products e g firewalls gateways special purpose IA components they are mature technology and can be used in the 2006-2008 GIG For other categories of products e g devices to connect to multiple levels of wireless networks general purpose desktop computers significant research is needed in the areas of software engineering high-assurance computing network security and system evaluation In addition much work is needed for all types of platforms in the areas of system performance user friendliness and cost-effective security U FOUO For those categories of products for which the technology is well adapted e g firewalls and gateways trusted platforms are Mature TRLs 7 - 9 There are products which can be purchased and used today In fact there are products that are being used within the DoD today U FOUO For other types of products significant research is needed The technology readiness group is near the boundary of Emerging TRLs 4- 6 and Early TRLs 1 - 3 2 3 3 3 4 U Standards U Validated non-U S Government Protection Profiles on trusted platforms per http niap nist gov cc-scheme pp index html o U Trusted Computing Group TCG Personal Computer PC Specific Trusted Building Block TBB Protection Profile and TCG PC Specific TBB with Maintenance Protection Profile o U Trusted Computing Platform Alliance Trusted Platform Module PP 6200 6201 6202 6203 6204 6205 6206 6207 U The primary standard for Trusted Platforms is the Common Criteria ISO 15408 volumes 13 These documents are used as the basis for evaluation in the U S and approximately 20 other countries U FOUO For other non-COTS devices there are specific standards internal to NSA that are applied to high-assurance devices UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-95 UNCLASSIFIED FOR OFFICIAL USE ONLY 6208 6209 6210 6211 6212 6213 6214 6215 6216 6217 6218 6219 6220 6221 6222 6223 6224 6225 6226 6227 6228 6229 6230 6231 6232 6233 6234 6235 6236 6237 6238 6239 6240 6241 6242 6243 6244 6245 2 3 3 3 5 U Cost Limitations U FOUO As noted above trusted platforms tend to be very costly to develop and costly to use Development costs are attributed to the fact that it at least initially costs a lot of money to build security into a product Typical commercial best practices cannot be used so the development system has to be changed In addition evaluation of a product costs money and time Given that the market for these trusted platforms has traditionally been very small the development costs have to be amortized over this relatively small base and thus the cost to users tends to be high U FOUO There is a perceived cost to the users in running a trusted platform in the GIG environment as well This cost is due to the fact that for security reasons the trusted platform often does not allow the users to do things the same way they've always done them 2 3 3 3 6 U Dependencies U As noted above trusted platforms are dependent on a number of the other enablers Identification and Authentication Policy-Based Access Control Network Defense and Situational Awareness and Management of IA Mechanisms and Assets 2 3 3 3 7 U Alternatives U FOUO The alternative to using trusted platforms is to restrict the GIG to having each device be used for a single classification level or domain of information and users However this defeats the GIG's vision of information sharing it prevents RAdAC from being implemented it drives up costs and in general it will prevent the GIG from meeting its mission U FOUO Within the field of trusted platforms there are a variety of possible alternatives-- traditional Multi-level security Multiple Independent Levels of Security various other security policies to be supported It is likely that each of these alternatives will be useful for some set of scenarios and thus that there will be a wide variety of trusted platforms deployed in the GIG in the future 2 3 3 3 8 U Complementary Techniques U FOUO Trusted platforms can be deployed along with cross-domain solutions such as a firewall and gateways to provide cost-effective solution for the GIG Trusted platforms can also be used with other IA components to strengthen security e g a trusted platform along with a QoP-capable router provides better resource allocation for the GIG that resists attacks better than routers alone 2 3 3 3 9 U References U ISO 15408-1 Information technology -- Security techniques -- Evaluation criteria for IT security -- Part 1 Introduction and general model 1999 U ISO 15408-2 Information technology -- Security techniques -- Evaluation criteria for IT security -- Part 2 Security functional requirements 1999 U ISO 15408-3 Information technology -- Security techniques -- Evaluation criteria for IT security -- Part 3 Security assurance requirements 1999 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-96 UNCLASSIFIED FOR OFFICIAL USE ONLY 6246 6247 6248 6249 6250 U Johnson R and D Wagner Finding User Kernel Pointer Bugs with Type Inference Proc 13th USENIX Security Symposium pp 119-133 San Diego CA August 2004 U Static Disassembly of Obfuscated Binaries by Kruegel C W Robertson F Valeur and G Vigna Proc 13th USENIX Security Symposium pp 255 - 270 San Diego CA August 2004 6252 U Protection Profile for Multilevel Operating System in Environments Requiring Medium Robustness Version 1 22 NIAP May 23 2001 Available at http niap nist gov cc- 6253 scheme pp PP_MLOSPP-MR_V1 22 html 6254 6255 U Protection Profile for Single-level Operating Systems in Environments Requiring Medium Robustness Version 1 22 NIAP May 23 2001 Available at http niap nist gov cc- 6256 scheme pp PP_SLOSPP-MR_V1 22 html 6257 U Controlled Access Protection Profile Version 1 d NIAP October 8 1999 Available at 6258 http niap nist gov cc-scheme pp PP_CAPP_V1 d html 6259 U Labeled Security Protection Profile Version 1 d NIAP October 8 1999 Available at 6260 http niap nist gov cc-scheme pp PP_LSPP_V1 b html 6261 U Copilot - a Coprocessor-based Kernel Runtime Integrity Monitor Petroni N T Fraser J Molina and W Arbaugh Proc 13th USENIX Security Symposium pp 179 - 193 San Diego CA August 2004 6251 6262 6263 6264 6265 6266 U Design and Implementation of a TCG-based Integrity Measurement Architecture ' Sailer R X Zhang T Jaeger and L van Doorn in Proc 13th USENIX Security Symposium pp 223 - 238 San Diego CA August 2004 6268 U TCSEC -Department of Defense Trusted Computer System Evaluation Criteria DoD Standard 5200 28-STD obsolete December 1985 Available at 6269 http www radium ncsc mil tpep library rainbow 5200 28-STD html 6267 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-97 UNCLASSIFIED FOR OFFICIAL USE ONLY 6270 2 3 3 4 U Trusted Applications 6271 2 3 3 4 1 U Technical Detail 6272 2 3 3 4 1 1 U Definition U For the purposes of this Technology Roadmap a trusted application is an application that is relied upon while performing its functions to enforce a specific security policy The security policy may be as simple as not being malicious or it may involve simultaneously processing and separating information from several domains e g at multiple classification levels 6273 6274 6275 6276 6277 6278 6279 6280 6281 6282 6283 6284 6285 6286 6287 6288 6289 6290 6291 6292 6293 6294 6295 6296 6297 6298 6299 6300 6301 6302 6303 U An application is simply a program with a specific task or use That is a database management system may be an application or a web server or a browser or an e-mail program An operating system or other generic program without a specific task to perform is not an application Trusted operating systems are addressed in section 2 3 3 2 of the GIG IA Capability Technology Roadmap U At a minimum a trusted application is not and cannot be subverted by malicious logic and it does not harm other components of the GIG--including the platform s on which it is hosted Depending on its specific security policy a trusted application may also have other responsibilities such as the separation of classified information U There are different definitions of trusted applications available in the literature Some of them vary only in syntax others in semantics For example some definitions assume that a trusted application is one that simultaneously processes information at multiple level of security i e the trust is conferred because of the way the application was designed and operates Other definitions assume that a trusted application is one that a user has accepted and agrees to let run on a computer without restrictions i e the trust is conferred because the user has accepted the application based on whatever evidence exists U Yet another definition involves the ability of a trusted application to do harm That is a trusted application is one that by its design and implementation could subvert the security of the GIG if it unintentionally or maliciously attempts to violate the security policy of its host platform That is the application is trusted because it has to be it isn't confined by a platform e g an operating system in such a way that the damage it can cause is constrained An untrusted application by contrast is one that is constrained by a trusted platform Section 2 3 3 2 of this document so that it cannot directly impact the security of the GIG by either malicious use by an attacker or simply by error in its own implementation and operation 8 U The resolution of these conflicting ideas is to use the definition cited above That is a trusted application is one that is assigned a security policy and is relied upon to enforce that security policy 8 U FOUO Note that where availability is concerned this means that a trusted application cannot prevent other applications or the system from meeting its security requirements Any application can fail to provide availability for itself simply by failing to work UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-98 UNCLASSIFIED FOR OFFICIAL USE ONLY 6304 6305 6306 6307 6308 6309 6310 6311 6312 6313 6314 6315 6316 6317 6318 6319 6320 6321 6322 6323 6324 6325 6326 6327 6328 6329 6330 6331 6332 6333 6334 6335 6336 6337 2 3 3 4 1 2 U Security Policies U As noted above a trusted application may have any of a variety of security policies In the most extreme cases a trusted application such as a trusted database management system see TDI for more details may have a significant security policy such as maintaining the separation of information at different classification levels while at the same time allowing accesses by users with different clearance levels At the other end of the spectrum a trusted application may have a security policy of doing no harm That is the application is trusted to execute and perform its task without carrying or being vulnerable to viruses worms or other malicious logic and without being able to cause denial of service attacks on its host component or on other GIG components 9 2 3 3 4 1 3 U Host Platform U FOUO A trusted application runs on top of a host platform This host platform consists of hardware and software e g an operating system that provides support for the application Enforcement of the application's security policy depends directly on the host platform The host platform provides basic facilities e g storage processing access to printers and networks that the application requires to enforce its security policy The host platform can also be used as a vector for attacking a trusted application e g an attacker can modify the processor to ensure that encryption routines are not called when requested or are called with pre-determined keys and initialization vectors to prevent the proper encryption of data U FOUO Because of this there must be an appropriate match between the security policy assigned to the trusted application and the capabilities of the host platform on which the application executes For example it is generally NOT acceptable to run an application providing multilevel security on a host platform that does not support strong process separation and access control--it is too easy for the application to be subverted 2 3 3 4 1 4 U Requirements for Trusted Applications U The specific requirements that are to be imposed on any trusted application depend on both what the application is supposed to accomplish and what its security policy is Regardless of those factors though a set of minimum requirements can be established for all trusted applications These requirements provide a basis for establishing some level of confidence that the application will enforce its security policy U These requirements are levied upon the execution environment in which the application runs e g the operating system and hardware on which a program runs as well as on the application itself Peinado et al PEINADO list the following properties that must be possessed by the application and its execution environment o 6338 6339 6340 U No interference The execution environment must provide a program that executes in it with the same underlying machine interface every time the program executes The program must be isolated from external interference A necessary condition is that a 6 U FOUO Note that a trusted application is not trusted to work correctly Program correctness - working correctly without error under all input conditions - is not a function of Information Assurance as addressed here A trusted application may still hang or fail to complete it may still calculate an incorrect answer or provide incorrect outputs for specific data UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-99 UNCLASSIFIED FOR OFFICIAL USE ONLY deterministic sequential program that does not access devices or persistent state should always reach the same result irrespective of other programs that might have executed earlier or at the same time on the same machine 6341 6342 6343 6344 o U No observation The computations and data of a program should not be observable by other entities except for data the program chooses to reveal e g through IPC o U Trusted paths A program should be able to receive data from a local input device e g keyboard mouse such that only the program and the user of the input device share the data Data integrity must be assured A similar requirement applies to local output devices such as video o U Persistent storage A program should be able to store data e g cryptographic keys persistently so that the integrity and the confidentiality of the data are ensured o U Communication A program should be able to exchange data with another program such that the integrity and the confidentiality of the data are ensured o U Local authentication A local user should be able to determine the identity of a program o U Remote authentication A program should be able to authenticate itself to a remote entity For example a corporate network administrator should be able to verify that all machines on his network are running the latest security patches and virus checker files 6345 6346 6347 6348 6349 6350 6351 6352 6353 6354 6355 6356 6357 6358 6359 6360 6361 6362 6363 6364 6365 6366 6367 6368 6369 6370 6371 6372 6373 6374 6375 2 3 3 4 1 5 U Implementing Trusted Applications U There are a number of factors that go into the implementation of a trusted application These include how the application fits into the overall architecture of the system and how it is supported the development process for the trusted application and evaluation of the trusted application 2 3 3 4 1 6 U Architecture U FOUO As noted above trusted applications must rely on their host platforms to provide some level of security At a minimum the application must rely on the host platform to prevent a direct attack on and subversion of the application's security policy Therefore implementers of trusted applications must first decide on what platforms the application is to be hosted Then they must decide how to use the security features and security policy enforcement provided by the host platform U FOUO Most application developers want their software to be able run on a variety of hardware platforms That maximizes the return on the investment of application development However from a security standpoint that creates a complex situation since the application developer must decide which characteristics of the family of host platforms are to be supported and clearly state these UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-100 UNCLASSIFIED FOR OFFICIAL USE ONLY 6376 6377 6378 6379 6380 6381 6382 6383 6384 6385 6386 6387 6388 6389 6390 6391 6392 6393 6394 6395 6396 6397 6398 6399 6400 6401 6402 6403 6404 6405 6406 6407 6408 6409 U FOUO For example an application developer writing a trusted application to run on a server operating system can require that the server and its environment provide identification and authentication of users tamper-resistance and a certain level of functionality Then any server and environment that provide those features would be an acceptable host for the application U FOUO Or the developer can write the application to require its own identification and authentication service and not rely on an underlying server operating system to provide that feature This can mean that the application could run on a wider variety of platforms but at the potential negative of being less friendly to the user because it would require a separate log-in step U FOUO Some applications will be written for use on special purpose devices such as NSAcertified Type 1 encryption devices These applications can be tailored for the capabilities of the device to make use of all the features provided by that host platform U FOUO Once a platform or set of platforms has been selected the developer must next decide on what features of the platform--and specifically what security policy features--to rely on to protect the application For example an application running on an Multi-Level Security MLS or Multiple Independent Levels of Security MILS platform may operate at one level or it may support multiple security levels itself As another example an application may make use of a platform's strong identification and authentication service by accepting the user identity preferred by the host platform or it may choose to require its own identification and authentication process U FOUO Once all these decisions are made the developer of the trusted application will know what is the security policy of the application what parts of the host platform will be used and therefore what the requirements are for the application itself The developer can then build to those requirements 2 3 3 4 1 7 U Development U FOUO A trusted application implements a security policy even if that security policy is as simple as one that does not contain malicious code The application must therefore be developed in such a way as to provide some level of assurance that the application does indeed enforce its security policy U FOUO The specific development environment and developmental requirements chosen by the developer will be a function of the target assurance level selected by the developer Typically the assurance level will be one of the seven Evaluated Assurance Levels EAL defined in Volume 3 of the Common Criteria ISO15408 10 In this case the development process must be consistent with the requirements defined for that EAL 10 U FOUO This is not required the assurance level of an application can be whatever level is selected as appropriate for the target environment However the U S Government approved standard for assurance levels consists of the seven EALs defined in Volume 3 of ISO 15408 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-101 UNCLASSIFIED FOR OFFICIAL USE ONLY 6410 6411 6412 6413 6414 6415 6416 2 3 3 4 1 8 U Evaluation U FOUO Many commercial products support the notion of a trusted application However in most cases a trusted application is simply one that the user decides to trust Sometimes the user is told that there is an organization that digitally signed the application so there is some level of confidence that it came from a particular commercially-reliable organization11 There are known weaknesses in systems that rely on digitally signing code to assure its benign properties and this mechanism by itself is insufficient for the GIG 6424 U FOUO In short for GIG users there is generally no reason for the user to believe that any particular application will enforce its security policy or will not contain malicious logic The way to improve this situation is to have security-critical applications be evaluated The Common Evaluation Methodology CEM defined under the NIAP should be used as the baseline Protection profiles should be defined for any common applications in the way that Dprof and Wprof are being defined for database management systems and web servers respectively If an application is sufficiently unique to make a protection profile not worthwhile then an equivalent evaluation should be done based on a security target established for that application 6425 2 3 3 4 2 U Usage Considerations 6426 2 3 3 4 2 1 U Implementation Issues U FOUO The major implementation issues have been described above They are 6417 6418 6419 6420 6421 6422 6423 6427 6428 o U FOUO Determining the security policy to be enforced by the application 6429 o U FOUO Determining the set of host platforms on which the application is to be executed o U FOUO Determining the security policies properties enforced by those platforms and deciding which of them will be used by the applications o U FOUO Finally determining the requirements to be met by the application itself to enforce the selected security policy in the assumed environment 6430 6431 6432 6433 6434 6435 6436 6437 6438 6439 6440 6441 6442 6443 U FOUO The development environment must reflect the chosen assurance level for the application If required an independent evaluation of the implemented application must be performed to achieve the required confidence that it enforces its security policy 2 3 3 4 2 2 U Advantages U FOUO The advantage of a trusted application over a generic untrusted application is that GIG users and designers have an established level of confidence the assurance level that the trusted application enforces its security policy in its presumed environment This allows users and security officers to better understand the total risks involved in operating the GIG and also improves the security of the GIG 11 U The worth of such a signature if any in the commercial environment is that there is some organization that can be sued if the application turns out to damage the user's environment UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-102 UNCLASSIFIED FOR OFFICIAL USE ONLY 6444 6445 6446 6447 6448 6449 6450 6451 6452 6453 6454 6455 6456 6457 6458 6459 6460 6461 6462 6463 6464 6465 6466 6467 6468 6469 6470 6471 6472 6473 6474 6475 6476 6477 6478 6479 6480 6481 U FOUO A trusted application that enforces a complex security policy such as support for MLS or MILS can allow enhanced operations for certain GIG users For example an MLS email system can allow a user to communicate via e-mail with multiple communities operating at different classification levels simultaneously eliminating the need for multiple e-mail devices and connections 2 3 3 4 2 3 U Risks Threats Attacks U FOUO Attacks against trusted applications can come either directly against the application itself or through the underlying host platform This is why the application developer must consider the intended host platform and the totality of the system in designing and implementing the application U FOUO An example of an attack against the application itself is feeding the application bad data Early web servers did not filter data passed to them by clients and it was often possible to provide a shell script program in the data field of a web form and thus have the program executed on the web server Thus it was necessary for web server implementers to filter all data provided by a client to ensure that no malicious logic got executed on the server's host computer Application developers must consider similar attacks against their own applications and defend against them appropriately U FOUO An example of an attack against an application through the host platform is one in which an attacker places a keystroke logger on a computer to capture all keystrokes typed into an application This attack can potentially recover passwords PINs needed to unlock and use private keys and other sensitive material without the application itself ever being aware of this Application developers must be aware of the types of host platforms on which their applications will run and the potential attacks that can occur through those host platforms They must make decisions about which types of attacks to defend against and which types of attacks to simply accept The application's documentation must make clear the decisions made by developers and the resultant risks to application users 2 3 3 4 3 U Maturity Level U The maturity level of trusted applications varies according to the type of application and host platform Trusted applications that enforce simple security policies e g within a single security level have existed for several years Standards and guidelines for developing trusted applications such as web servers multi-level e-mail and multi-level database management systems DBMS exist now or are in development Some implementations of applications that comply with those standards and guidelines are in various stages of development U FOUO However there is much work to do in the general field of trusted applications Applications that work across security domains or levels that enforce dynamic access control policies such as RAdAC and that work across a range of general-purpose host platforms while communicating across a variety of networks require significant amounts of research and development UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-103 UNCLASSIFIED FOR OFFICIAL USE ONLY 6482 6483 6484 6485 6486 6487 6488 6489 6490 6491 6492 6493 6494 6495 6496 6497 6498 6499 6500 6501 6502 6503 6504 6505 6506 6507 6508 6509 6510 6511 6512 6513 U FOUO In terms of timelines the set of trusted applications that are available will increase gradually over time Simple trusted applications exist today and there will be a few more by 2008 Self-protecting trusted applications and support for some more complex security policies will exist by 2012 Full support for complex security policies on a variety of host platforms will not exist until the 2016-2020 timeframe U FOUO The technology readiness level group assigned for trusted applications is Emerging TRLs 4 - 6 This is an accurate reflection of the overall status of the area As noted above some parts of this field are already well understood and trusted applications exist Other areas require significant research and development 2 3 3 4 4 U Standards U Applicable standards for trusted applications are Protection Profiles developed against ISO 15408 the Common Criteria Because of the different security requirements security policies and functional requirements of different applications it is not possible to have a generic Trusted Application Protection Profile Rather a different Protection Profile will need to be developed for each type of application It may be necessary to have multiple Protection Profiles for some types of applications depending on the possible security policies that can be assigned for that application U At the time of this writing there were no U S Government validated Protection Profiles for trusted applications There are two draft profiles currently being validated one for database management systems DBProf and one for web servers WSProf 2 3 3 4 5 U Cost Limitations U FOUO The costs of trusted applications are associated with the processes that must be followed particularly the development and evaluation processes Trusted applications have the potential of being very expensive particularly if custom development processes must be followed in order to achieve acceptable assurance levels A goal is to improve the software development process so that standard commercial best practices are sufficient to develop high assurance trusted applications U FOUO If trusted applications must be evaluated the costs of the evaluation are also a concern A robust efficient evaluation process must be developed 2 3 3 4 6 U Dependencies U Successful development of robust trusted applications with complex security policies depends on the completion or establishment of 6514 o U FOUO Dynamic access control policies 6515 o U FOUO Standards for application development and evaluation 6516 o U FOUO Understanding of the relationship between host platform security policies and trusted application security policies o U FOUO Establishment of techniques and uniform requirements for self-protecting 6517 6518 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-104 UNCLASSIFIED FOR OFFICIAL USE ONLY 6519 6520 6521 6522 6523 6524 6525 6526 6527 6528 6529 6530 6531 applications 2 3 3 4 7 U Alternatives U FOUO The only real alternative to trusted applications is to regard all applications as untrusted and rely upon the host platform to provide protection Depending on the need to share information within a COI untrusted applications constrained by host platforms may not provide sufficient functionality to accomplish a mission 2 3 3 4 8 U Complementary Techniques U FOUO Trusted applications work more efficiently with trusted platforms as that enhances the uses for trusted applications e g MLS e-mail programs on MLS or MILS platforms provide greater functionality than MLS e-mail programs on single-level platforms In addition there is greater overall confidence in the security provided by a trusted application running on a trusted platform than there is in a trusted application running on an untrusted platform because there is less likelihood of an attack on the application coming through the host platform 6535 2 3 3 4 9 U References U DBProf - National Information Assurance Partnership U S Government Protection Profile Database Management Systems for Basic Robustness Environments Version 0 24 15 December 2003 Available at http www niap nist gov pp draft_pps pp_draft_dbms_br_v0 24 pdf 6536 U ISO 15408 - a three volume set consisting of 6537 U ISO 15408-1 Information technology -- Security techniques -- Evaluation criteria for IT security -- Part 1 Introduction and general model 1999 6532 6533 6534 6538 6539 6540 6541 6542 U ISO 15408-2 Information technology -- Security techniques -- Evaluation criteria for IT security -- Part 2 Security functional requirements 1999 U ISO 15408-3 Information technology -- Security techniques -- Evaluation criteria for IT security -- Part 3 Security assurance requirements 1999 6545 U PEINADO - Peinado Marcus Yuqun Chen Paul England and John Manferdelli NGSCB A Trusted Open System Microsoft White Paper Microsoft Corporation Redmond WA available at http research microsoft com yuqunc papers ngscb pdf 6546 U Shirey R Internet Security Glossary RFC 2828 May 2000 Available at 6547 http www ietf org rfc rfc2828 txt 6548 U TDI - National Computer Security Center Trusted Database Management System Interpretation of the Trusted Computer System Evaluation Criteria NCSC-TG-021 April 1991 Available at http www radium ncsc mil tpep library rainbow NCSC-TG-021 html 6543 6544 6549 6550 6552 U WSProf - National Information Assurance Partnership U S Government Protection Profile Web Server for Basic Robustness Environments Version 0 41 1 August 2003 Available at 6553 http www niap nist gov pp draft_pps pp_draft_websrv_br_v0 41 pdf 6551 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-105 UNCLASSIFIED FOR OFFICIAL USE ONLY 6554 6555 6556 6557 6558 6559 6560 6561 6562 6563 6564 6565 6566 6567 6568 6569 6570 6571 6572 6573 6574 6575 6576 2 3 3 5 U Cross Domain Solution Technologies U FOUO The demands of modern warfare require that deployed forces must tightly synchronize activities in real-time within Joint and international Combined Force environments Such synchronization necessitates an assured sharing environment where information travels seamlessly across space time security and releasability domains so that the right information gets to the right warfighters in a time and place that maximizes operational effectiveness The operational need for cross-domain information flow has been recognized for decades However the advent of high-speed information systems their supporting networks and the subsequent reliance of U S and multinational forces on these standardized high-performance technologies emphasizes an urgent need for assured cross-domain solutions if organizations are to keep pace with doctrinal and operational shifts toward network-centric warfare U FOUO A cross-domain solution CDS is an information assurance solution that provides the ability to manually or automatically access or transfer data between two or more differing security domains CJCSI 6211 01b These solutions should enable the secure transfer of information across differing security domains to sustain and maximize operational effectiveness while supporting GIG security objectives This document recognizes that while the interconnection of information systems of different security domains within and at the periphery of the GIG may be necessary to meet essential mission requirements such connections pose significant security concerns and shall be used only to meet compelling operational requirements not operational convenience DoD Instruction 8540 aa DRAFT 2 3 3 5 1 U Technical Detail U FOUO The broad definition of CDS given in CJCSI 6211 01b manifests itself in legacy systems as two distinct sets of technologies as shown in Figure 2 3-22 Network A Top Secret CDS Guard Network B Secret Multi-Level Workstation Guard Network C Unclassified This figure is U FOUO 6577 6578 Figure 2 3-22 U Legacy Manifestation of Cross-Domain Solutions UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-106 UNCLASSIFIED FOR OFFICIAL USE ONLY 6579 6580 6581 6582 6583 6584 6585 6586 6587 6588 6589 6590 6591 U FOUO The first set of technologies falls within the category of controlled interfaces or guards These technologies enable the flow of information between security domains The second set of technologies deal with accessing multiple domains from a single node workstation or server As technology matures within each GIG IA increment the distinction between these two sets of technologies will blur substantially U FOUO A CDS that is used for the transfer of information could be a device or a group of devices that mediate controlled transfers of information across security boundaries e g between security domain A and security domain B In this usage a CDS is trusted to allow sharing of data across boundaries and enforces a defined security policy CDS take into account the following characteristics type of data flow direction of data flow e g high to low low to high human or automated review connection protocol number of connections as shown in Figure 2 3-23 Some services of a CDS include filtering dirty word search integrity checks sanitization downgrading and virus scanning Low Side Content High Side Content Filtering Process Higher Classification Lower Classification Connections between different security levels must fulfill three Requirements - - - Provide users with the information they need while Securing classified data from access by unauthorized persons and Protecting networks from intended unintended corruption by 'malicious' or hidden code and denial of service attacks This figure is U 6592 6593 Figure 2 3-23 U Controlled Interface Example UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-107 UNCLASSIFIED FOR OFFICIAL USE ONLY 6594 6595 6596 6597 6598 6599 6600 6601 6602 6603 U FOUO Current CDS technologies that deal with simultaneously accessing information from multiple domains from a single location typically fall within two categories based on functionality The first category includes information systems that internally separate multiple single levels MSL of security Two dominant architectures supporting MSL technologies include systems where separation is maintained locally within an edge platform e g thick client architectures such as NetTop and systems where separation is performed remotely at a server and clients lacking local storage access to each domain as allowed by the server e g thin client architectures such as Multi-Level Thin Client MLTC These two MSL architectures shown in Figure 2 3-24 are complementary and address information access requirements of different operational environments Domain A Domain B Thick Clients Domain C This figure is U FOUO Thin Clients 6604 6605 6606 6607 6608 6609 6610 6611 6612 6613 6614 6615 6616 6617 6618 6619 6620 6621 6622 Figure 2 3-24 U Two MSL Architectures U FOUO The second category of information-access CDS includes information systems that can manage multiple levels of security MLS simultaneously allowing for example cut-andpaste between windows of a MLS workstation An MLS database for example could allow users in different security domains to access information in the same database up to their respective clearance levels versus accessing information in two distinct replicated databases one database image within each security domain 2 3 3 5 2 U Usage Considerations U FOUO Traditional MLS architectures meet many of the requirements of CDS and have been used successfully in limited contexts in the past The main factors limiting broader acceptance and deployment of MLS solutions historically have been cost and certification and accreditation C A issues with respect to mainstream operating systems and COTS applications in widespread use throughout the DoD e g Windows NT Microsoft Office While certain systems e g Wang XTS-300 Trusted Computer System have been approved by NSA for MLS processing in particular contexts such systems have historically not supported a broad enough variety of COTS applications and DoD-specific applications to form a viable basis for developing a complete CDS capability An example of an MLS solution deployed today is OSIS Evolutionary Development OED UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-108 UNCLASSIFIED FOR OFFICIAL USE ONLY 6623 6624 6625 6626 6627 6628 6629 6630 6631 6632 6633 6634 6635 6636 6637 6638 6639 6640 6641 6642 6643 6644 6645 6646 6647 6648 6649 6650 6651 6652 6653 6654 6655 6656 6657 6658 6659 6660 6661 6662 U FOUO OED has an impressive accreditation and usage record in the DoD However there still remain issues that affect its applicability as a general MLS capability In brief the issues relate to vendor support for the underlying operating system support for commercial off-theshelf COTS applications e g MS Office the ability of serial links used to scale in large environments the need to operate the system in a Sensitive Compartmented Information Facility SCIF with only TS-cleared personnel and the need to run customized versions of command and control applications U FOUO The absence of fully general MLS solutions deployable on a mass scale has led to the proliferation of MSL technologies With the exception of guard components MSL solutions are more technically tractable and are often more straightforward to certify and accredit than general purpose MLS technologies Examples of such solutions deployed today include Coalition Operational Wide Area Networks COWANs and more recently Combined Enterprise Regional Information Exchange System CENTRIXS Additional examples of systems using a MSL architecture are MLTC and Network on a Desktop NetTop U FOUO Experience has shown that MSL architectures have proven unsatisfactory in many settings MSL often reinforces the dependence on duplicated infrastructures--one for each security level Duplicate infrastructure exacerbates the multiple sign-on problem the warfighter must logon to each infrastructure separately rather than using an SSO login and often leads to increased Space Weight and Power SWaP SWaP is particularly acute in many constrained warfighting environments e g ships submarines aircraft ground vehicles as well as the hauling capacity of individual troops While certain approaches e g MLTC and Keyboard Video Mouse KVM switches have partially ameliorated the duplicate hardware issue a number of additional drawbacks remain in MSL U FOUO At the most basic level MSL tends to impede the efficient and timely dissemination of information The warfighter is hampered with sometimes awkward frequently insufficient and at times even inappropriate workarounds The warfighter must manually switch between disparate security domains and their associated separate databases and networks in order to accomplish the assigned mission Correlating information between domains is challenging and may result in a warfighter having to resort to various methods such as rekeying of data sneaker net and hard drive swapping to ferry information between segregated networks Such procedures introduce risks and delays U FOUO Such inefficiencies and risks manifest themselves in many ways from the merely inconvenient to the potentially serious The result is that MSL drawbacks extend across many areas Operational shortcomings include situational awareness timeliness and accuracy situational awareness confusion data under-classification data over-classification information inaccessibility online searching difficulties and timeliness of setup for ad-doc coalitions MSL has a number of technical shortcomings including guard proliferation breaking end-to-end security assumptions lack of need-to-know enforcement identity maintenance and correlation difficulties collaboration difficulties timely setup for ad-hoc coalitions and proliferation of network interconnections UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-109 UNCLASSIFIED FOR OFFICIAL USE ONLY 6663 6664 6665 6666 6667 6668 6669 6670 6671 6672 6673 6674 6675 6676 6677 6678 6679 6680 6681 6682 6683 6684 6685 6686 6687 6688 6689 6690 6691 6692 6693 6694 2 3 3 5 2 1 U Implementation Issues U FOUO CDSs are software hardware implementations of networked IT The variability and complexity of IT systems for practical purposes result in solutions that have an infinite number of possible configurations Resources at all levels do not reasonably exist to adequately test and evaluate all possible configurations of CDSs and their component devices For this reason configuration of CDSs must be strictly controlled and enforced Any configuration change outside of that specified could dramatically affect one or more of the three assessment areas mentioned earlier In addition CDSs are designed for specific purposes and to handle specific data requirements Any changes in operational concept or data encoding will most often defeat the security provided by the CDS U FOUO Beyond configuration control and maintenance there are fundamental issues that must be addressed when considering the use of CDS within an environment that aims for end-toend security Of principle concern is the following A primary function of CDS is to examine content and this instantiates numerous conflicts with technologies aimed at protecting confidentiality and integrity e g FNBDT SSL TLS IPsec and HAIPE 2 3 3 5 2 2 U Advantages U FOUO Until the GIG 2020 Vision is achieved multiple security domains will exist CDS is essential to allow information sharing among GIG entities during this transition period CDS will remain a necessary component of interoperability within multinational forces whose technology procurement schedules are not dictated by the GIG acquisition timelines 2 3 3 5 2 3 U Risks Threats Attacks U FOUO Any use of a CDS entails an acceptance of risk Risks exist for both the inadvertent release of restricted data as well as the risk of malicious attack For community-operated networks the risk assumed by a CDS is imposed on all network operations and is not restricted to the specific system requiring the CDS All CDSs represent some level of risk and a CDS should not be contemplated except under compelling operational requirements In considering a CDS for use the specific and community risks must both be assessed before any accreditation decision is made U FOUO The risk of a CDS is comprised of more than just the connection technology It must encompass the data application environment and risk posture of the connecting enclave as well The three assessment areas required for any CDS are o U FOUO Connection Confidence - An assessment of how confident the solution will behave as specified and is resistant to exploitation o U FOUO Data Potential - An assessment of the volatility of the data formats types allowed by the connection and their potential to cause harm in the operational environment o U FOUO Partner Type - An assessment of how likely the connection system or its administrator would support sponsor an attack 6695 6696 6697 6698 6699 6700 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-110 UNCLASSIFIED FOR OFFICIAL USE ONLY 6701 6702 6703 6704 6705 6706 6707 6708 6709 6710 6711 6712 6713 6714 6715 6716 6717 6718 6719 6720 6721 6722 6723 6724 6725 6726 6727 6728 6729 6730 6731 6732 6733 6734 U FOUO It is important that cross-domain solutions be understood to be holes intentionally placed within a more strict security environment for the purpose of improved information sharing Current CDS technologies provide no ability to mitigate filtering or disclosure errors 2 3 3 5 3 U Maturity U FOUO This section describes CDS that currently exist new cross-domain solutions being considered for near term development and systems that will require research and the use of future technologies 2 3 3 5 3 1 U Current Technologies and Solutions U FOUO Currently most operational cross-domain solutions fall into one of four technology areas These areas are electronic mail e-mail fixed formatted data file transfer and desktop reduction The lack of maturity of underlying IA controls causes these technologies to be considered Emerging TRLs 5 - 7 even though many of these technologies have been demonstrated in an operational environment U FOUO E-mail cross-domain solutions scan ASCII-formatted e-mail for dirty words as messages traverse from high-side e g SIPRNet Mail Transfer Agents MTAs to low-side e g NIPRNet MTAs helping prevent the disclosure of classified information For low-to-high data flows e-mail solutions check e-mail for malicious code As an additional mitigation senders and recipients can be restricted to a list of those permitted to pass messages through a particular e-mail solution E-mail attachments are allowed to traverse security boundaries in some cases but the file types are limited The majority of e-mail solutions consist of the Defense Information Infrastructure DII Guard U FOUO Fixed format cross domain solutions transmit ASCII data that conforms to predefined format requirements such as field length allowed characters numerical ranges The strict formatting requirements applied to data submitted for traversal of the security boundary act as a mitigation of the concerns with unintended release and malicious content The two main solutions that meet the needs of this category are Defense Information Systems Agency's DISA Command and Control Guard C2G and the Radiant Mercury RM U FOUO File transfer solutions allow data files to be transmitted across the boundaries of their original security level The files allowed to pass through the solution currently are only those considered low-risk data This is due to the complexities of many file formats Therefore most solutions only allow the passage of plain ASCII text documents and image files Additionally high-to-low flows require human review prior to release to the low side Currently the Imagery Support Server Environment ISSE Guard and the Trusted Gateway Solution TGS are the two solutions used most frequently for this type of data transfer UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-111 UNCLASSIFIED FOR OFFICIAL USE ONLY 6735 6736 6737 6738 6739 6740 6741 6742 6743 6744 6745 6746 6747 6748 6749 6750 6751 6752 6753 6754 6755 6756 6757 6758 6759 6760 6761 6762 6763 6764 6765 6766 6767 6768 6769 6770 6771 6772 6773 6774 U FOUO Desktop Reduction is a valid concern in business today The need to have access to multiple networks of different security domains in one location is a necessity in many environments The problem faced here is the user now has multiple desktop computers using up his her desk space In the cases of small office space or aboard a ship space is at a premium The idea of desktop reduction is to free physical workspace and decrease the footprint of the computers In the example of a KVM switch the user only requires one monitor one keyboard and one mouse In other solutions presented the user may only require one desktop computer and one monitor to access these multiple networks 2 3 3 5 3 2 U New Cross-Domain Solutions Being Considered for Near-Term Development U FOUO Many technologies fit into this category including chat file transfer high risk data Browse Down and Content-Based Information Security CBIS These technologies are considered Early Emerging TRLs 3 - 4 U FOUO Chat is a technology most people are now familiar with Many commercial Instant Messengers can be downloaded free today from the Internet Chat gives the user the ability to communicate with co-workers and friends in real-time by sending text In the cross-domain world Chat would allow a user to send text across security domains in near-real-time allowing some latency for filtering U FOUO In the world of Cross-Domain file transfer has always been a big issue Although accredited solutions exist to transfer fixed file formats there are many files prohibited from being passed through these solutions e g executable files documents with macros The technology exists currently to filter some of these higher risk data types One of the larger pieces of the puzzle lies in filtering Microsoft Office documents since they are so widely used Microsoft Office documents are considered to be high risk due to all of the hidden information and executable contents macros which can be stored in them With the right solution in place business could carry on relatively seamlessly between security domains U FOUO Browse Down is a technology used to browse a lower security domain from a higher security domain network One example of this would be to surf the Internet while attached to your classified network at the office This would alleviate the need to purchase more hardware for the user's workspace and pull a network feed to his her desk U FOUO CBIS is the direction many in the Cross-Domain community are going CBIS can provide controlled access to assets based on the attributes associated with them These attributes will include a security classification as well as a need-to-know attribute CBIS is policy driven which dictates a specific role to a user After using strong Identification and Authentication I A mechanisms to help enforce the access control a user is only permitted to access files which his her role allows them to see Although some of this technology exists today it is relatively in its infancy When this technology has matured central repositories will be able to hold information from multiple security domains and allow CBIS to drive the policy It is anticipated that the key Assured Information Sharing technologies developed by CBIS will be incorporated into other cross domain solutions UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-112 UNCLASSIFIED FOR OFFICIAL USE ONLY 6775 6776 6777 6778 6779 6780 6781 6782 6783 6784 6785 6786 6787 6788 6789 6790 6791 6792 6793 6794 6795 6796 6797 6798 6799 6800 6801 6802 6803 6804 6805 6806 6807 6808 6809 6810 6811 6812 2 3 3 5 3 3 U Future Technology and Research Needed U FOUO In general for any mission-essential IT services within a system security domain a requirement will exist for that IT service to be supported across systems Today key IT services are e-mail sharing files collaboration and web browsing In the future key IT services are expected to include XML-based Web Services VoIP and others In addition the 2020 Vision is for a single system that can support as many security domains as needed Given the diversity of these requirements for CDSs to date research and development has provided solutions to only a small portion of the requirements and for those requirements that can be satisfied with CDSs today the overall administration of the CDSs is very labor intensive Several areas for research and development exist that would target making existing CDSs more enterprise-enabled and netcentric The objective is to have near-term return on investment by enhancing the collaboration capabilities supported by CDS bringing existing CDSs into compliance with standards and necessary assurance levels and making their administration less labor intensive U FOUO Research and development is also needed to address cross-domain security issues for particular capabilities operating within an environment supporting end-to-end security For example research and development is needed to address the cross-domain security issues with VoIP within an environment supported by HAIPE Likewise this applies to Web Services and for collaboration capabilities such as virtual white boarding shared applications remote desktop control audio video conferencing etc This research and development will address gaps in our knowledge of how to architect cross-domain capabilities into the GIG vision U FOUO As the GIG evolves towards the 2020 Vision CDSs as we often see them today devices at the system boundary will continue to evolve and exist primarily to control the flow of information between the GIG and non-GIG systems such as the Internet coalition networks owned by multiple nations national networks owned by another nation and possibly other U S Government agencies Of course CDSs controlling information passing into and from the GIG will need to be GIG-compliant and net-centric themselves U FOUO Achieving the 2020 Vision of a single system capable of handling all types of DoD information will require that virtually all components within the GIG incorporate to some extent the techniques and technologies first developed and deployed at the boundaries in CDSs U FOUO For example as we pursue research and development to establish a capability to examine Microsoft Office files for executable and hidden content that capability will likely first appear in a CDS Initial capabilities such as this are often complex and costly making them unwieldy for initial deployment on every desktop Instead these complex and costly capabilities will appear in centralized locations that are already--basically--complex and costly where application of the capability checking can be assured and where the benefit of the capability has the largest payoff As the capability matures it would migrate from the CDSs to the desktops themselves To achieve the 2020 Vision a capability such as in this example will likely be a key requirement for protecting the GIG's confidentiality integrity and availability UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-113 UNCLASSIFIED FOR OFFICIAL USE ONLY 6813 6814 6815 6816 6817 6818 6819 6820 6821 6822 U FOUO Another example would be the ability to discern the meaning of a document from its content While this capability is costly and complex it will likely be used in a CDS to detect and prevent inappropriate information from being released disclosed As the capability matures it can migrate to the desktop so that in 2020 a person preparing a document for a given recipient will receive a flag notice if the tool determines from the content of the document that it would be inappropriate for that intended recipient These are examples of how techniques and technologies originally implemented in CDSs can mature and then migrate from the boundary of the GIG into components within the GIG and thus are critical enablers to achieving the GIG 2020 Vision 2 3 3 5 4 U Standards U FOUO Standards for addressing Cross Domain requirements listed in Table 2 3-12 Table 2 3-12 U CDS Standards 6823 This table is U FOUO Name Description Applicability CJCSI 6211 02B Defense Information System Network DISN Policy Responsibilities and Procedures DCID6 3 Protecting Sensitive Compartmented Information within Information Systems This Instruction applies to the Joint Staff Combatant Commands Services Defense Agencies DoD Field Activities and Joint Activities It addresses Cross Domain requirements and the policy responsibilities and procedures for resolving Cross Domain issues Cross Domain connections shall be in accordance with DoD Directive 8500 1 Information Assurance and DoD Instruction 8500 2 Information Assurance Implementation Procedures within DoD Instruction 5200 40 DoD Information Technology Security Certification and Accreditation Process including a risk assessment by the Cross Domain Technical Advisory Board and approval by the DISN Security Accreditation Working Group will be followed This is a mandate for the Intelligence Community IC It is not applicable within the DoD unless a DoD system is connected to an IC system The Policy portion of this Directive establishes security policy and procedures for storing processing and communicating classified intelligence information in information systems ISs It lists policies plus roles and responsibilities The Manual portion of this Directive provides policy guidance and requirements for ensuring adequate protection of intelligence information It includes a section on Controlled Interfaces which are used for interconnected ISs including those of different security domains UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-114 UNCLASSIFIED FOR OFFICIAL USE ONLY This table is U FOUO Name DRAFT DODI 8540 aa 6824 6825 6826 6827 6828 6829 6830 6831 6832 6833 6834 6835 Description Applicability Interconnection and Data Transfer between Security Domains This Instruction will establish the DoD policy responsibilities and procedures for Cross Domain interconnections and the engineering installation certification accreditation and maintenance of such interconnections Upon publication it will apply to the Office of the Secretary of Defense Military Departments Chairman Joint Chiefs of Staff Combatant Commands Inspector General of the DoD Defense Agencies and DoD Field Activities It applies to all DoD information systems It includes Cross Domain Connection Request Procedures a Cross Domain Data Transfer Generic Framework and Scenario and Controlled Interface Characteristics This table is U FOUO 2 3 3 5 5 U Cost Limitations U FOUO Cross domain solutions are Government Off-The-Shelf GOTS products because they require higher assurance levels than available commercially 2 3 3 5 6 U Dependencies U FOUO Advancement of CDS technologies is heavily dependent upon the development and management of trusted platforms and trusted applications The success of CDS technology in enhancing operational effectiveness depends substantially on the involvement of Programs of Record in developing collaboration tools as well as command and control applications that are CDS aware The ability of CDS to enhance force protection capabilities avoidance of blue-onblue engagements and rapid dissemination of blue force indications and warnings depends heavily on our ability to put CDS-aware capabilities directly in the hands cockpits and workspaces of our warfighters UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-115 UNCLASSIFIED FOR OFFICIAL USE ONLY 6836 2 3 3 6 U Non-Repudiation 6837 2 3 3 6 1 U Technical Detail 6838 2 3 3 6 1 1 U What is Non-Repudiation U FOUO Non-repudiation is a service used to protect against an entity that attempts to falsely deny such as falsely denying generating a message or falsely denying receipt of information Strictly speaking technical non-repudiation mechanisms cannot actually prevent an entity from denying participating in an action or communication Instead they provide evidence that can be used to refute the repudiation claim That is the goal of a non-repudiation service is to provide a presumption that the entity performed the action in question and force the entity to provide strong evidence that it did not 6839 6840 6841 6842 6843 6844 6845 6846 6847 6848 6849 6850 6851 6852 6853 6854 6855 U An example is in order Suppose that Alice and Bob are in business Bob presents a purchase request purported to be from Alice and asserts that Alice thus owes him money However Bob could well be forging the request himself or it could have come from another entity entirely It could have actually come from Alice who now wants to disclaim it as she does not wish to pay the money owed A non-repudiation service would allow Bob to go to a neutral third party--such as a court--and convince it that Alice really did send the purchase request Conversely it would provide Alice strong proof that she did not send the purchase request U As defined in the International Standards Organization's Open Systems Interconnection Reference Model ISO OSI 7498 part 2 there are two basic types of non-repudiation service o U Non-repudiation with proof of origin A security service that provides the recipient of data with evidence that can be retained and that proves the origin of the data and thus protects the recipient against any subsequent attempt by the originator to falsely deny sending the data This service can be viewed as a stronger version of a data origin authentication service because it can verify identity to a third party o U Non-repudiation with proof of receipt A security service that provides the originator of data with evidence that can be retained and that proves the data was received as addressed This thus protects the originator against a subsequent attempt by the recipient to falsely deny receiving the data 6856 6857 6858 6859 6860 6861 6862 6863 6864 6865 6866 6867 6868 6869 6870 6871 6872 6873 6874 U FOUO These two services both deal with network communications that is the sending and receipt of a message In the GIG the concept of non-repudiation must be generalized to address a variety of other actions such as over-riding security policies granting access to classified information to entities without appropriate clearance etc U Non-repudiation has both technical and non-technical components The technical measures involved in a non-repudiation service include o U Authentication of the identity or identities associated with a transaction or transmission The authentication MUST be such that with a very high degree of confidence only one entity can provide the correct authentication information Typically this is done by the use of a PKI where each entity is assigned a private key to use for authentication digital signature and this key is not determinable by any attacker--given UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-116 UNCLASSIFIED FOR OFFICIAL USE ONLY assumed efforts 6875 6876 o U Integrity of the information Once an entity has taken some action--sent or received a message taken part in a transaction--it must not be possible for any attacker to modify the contents records of that transaction Typically this is accomplished using digital signatures--the entity signs the message transaction record and any modification to that signature or record is detectable o U Time Stamping One of the problems with signature-based systems is that backdating of records events is possible Suppose that Alice has a private key used for digital signatures If Alice's key is compromised for whatever reason e g she loses the token on which it is stored along with the PIN to that token an attacker Mal who now knows the private key can create various records and assign to them whatever time Mal desires Mal can create signed records that are dated before the compromise occurred--even years earlier if desired To protect against this a third-party time stamping service can be used to indicate that a record did exist no later than a given time Any records presented without time stamps are not considered to be protected by the non-repudiation service 6877 6878 6879 6880 6881 6882 6883 6884 6885 6886 6887 6888 6889 6890 6891 6892 6893 6894 6895 6896 U Notarization Even stronger than a time-stamping service is a digital notarization service With this service an entire transaction is certified and recorded by a neutral third party This provides a stronger chain of evidence for the transaction U As noted there are both technical and non-technical components of a non-repudiation service and no technical service can ever prevent an entity from attempting to deny or repudiate an action Some of the grounds for denial or repudiation could include o U Compromise of the key If the authentication service is provided by means of a PKI Alice can claim that her key was compromised e g stolen and she did not know it Thus she is not responsible for the transaction o U Weakness of the PKI Alice can attempt to claim that her private key was known to attackers due to procedural or technical weaknesses in the PKI itself For example the cryptography was not strong enough and thus an attacker figured out her private key or the key purportedly issued to her was actually given to another entity etc o U Intent Alice can claim that the transaction in question was not the one in which she intended to participate For example a worm program modified the data what she saw on her computer screen is not the same as what is in the message Or an attacker broke into her computer and used her private key to sign a message without her knowledge Or that she did not understand the nature content of the transaction she merely clicked OK when presented with a confusing license agreement on her screen 6897 6898 6899 6900 6901 6902 6903 6904 6905 6906 6907 6908 6909 6910 6911 6912 6913 6914 U All of these are within the legal scope of non-repudiation but are outside the technical scope To date there is essentially no case law that exists to guide system designers evaluators in determining what would happen in each of these situations and what they should do to defend against them Thus any non-repudiation service deployed in the GIG should be regarded as providing technical non-repudiation only and not regarded as providing any basis for the resolution of a legal dispute UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-117 UNCLASSIFIED FOR OFFICIAL USE ONLY 6915 6916 6917 6918 6919 6920 6921 6922 6923 6924 6925 6926 6927 6928 6929 6930 6931 6932 6933 6934 6935 6936 6937 6938 6939 6940 6941 6942 6943 6944 6945 6946 6947 6948 6949 6950 6951 6952 2 3 3 6 1 2 U Providing Non-Repudiation U FOUO In the GIG non-repudiation is required in conjunction with the TPPU model The non-repudiation service will be applicable to the source and receipt of posted data U FOUO Trust of GIG data is associated with the source of the data particularly since a large number of users may post data of varying confidence Thus any user of the data must reliably know the source of the data in order to be able to use it effectively Where proof of source may be needed non-repudiation should be applied to the data U FOUO Traditional application level non-repudiation services should also be available outside the scope of the TPPU model Certain security critical events will require authorization by a third party Non-repudiation evidence of the source or the authorizer of the events will be useful for the investigation of security incidents GIG security policy will identify certain events as security critical For example an access that violates traditional mandatory access control may be identified as a security critical event that requires authorization by a third party U FOUO There are three steps in the non-repudiation service 1 a request for the service either implicit or explicit 2 the creation and storage of the non-repudiation evidence and 3 the retrieval of the evidence either to assess its acceptability for future non-repudiation or to actually refute a repudiation claim Requests for service are typically handled in the specific application requiring non-repudiation U FOUO We will now address the technology requirements for the components involved in creation and storage of non-repudiation evidence 2 3 3 6 1 2 1 U Authentication U A fundamental requirement for non-repudiation is to be able to authenticate the entity involved in the transaction Authentication helps to ensure that the entity involved is the one expected to be involved U FOUO As noted above a major requirement to achieve non-repudiation is that the authentication process is very strong If an attacker can successfully authenticate as another entity then non-repudiation cannot be provided For this reason non-repudiation services are typically based on public-key infrastructures Authentication is based on possession of a token containing a private key as well as knowledge of the PIN associated with that token or with one or more specific biometric properties used to unlock the token Authentication using passwords is not acceptable for non-repudiation systems as they are too weak and easily defeated For example if Bob wishes to repudiate a transaction he could simply post his password in a public location and thus show a strong possibility that it was not he involved in the transaction U FOUO For the threshold 2008 GIG instantiation any application requiring a nonrepudiation service must require authentication based on a token such as the DoD Common Access Card CAC and with a PIN or biometric property required in association with the token As this is already available the threshold GIG should be able to meet its authentication requirements for non-repudiation UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-118 UNCLASSIFIED FOR OFFICIAL USE ONLY 6953 6954 6955 6956 6957 6958 6959 6960 6961 6962 6963 6964 6965 6966 6967 6968 6969 6970 6971 6972 6973 6974 6975 6976 6977 6978 6979 6980 6981 6982 6983 6984 6985 6986 6987 6988 6989 6990 6991 6992 U FOUO Future iterations of the GIG will require stronger versions of the token For example the DoD should advance to a Class 5 PKI for tokens to be used for non-repudiation in the objective GIG See section 2 7 for a description of the issues related to the DoD PKI 2 3 3 6 1 2 2 U Integrity U FOUO Once a transaction has occurred or a message has been sent or received the record of that transaction or message must be preserved In order for a non-repudiation service to be provided it must not be possible to modify the transaction from the time it is created without that modification being detectable For example if Alice creates a message saying Pay Bob $100 00 it must not be possible for anyone including Alice or Bob to change the message to Pay Bob $1 0000 or Pay Bob $10000 or Pay Fred $100 00 without the change being detectable U FOUO This protection against undetected modification is referred to as an integrity service Integrity is a mandatory requirement for non-repudiation to be provided U FOUO Integrity can be provided through a number of different mechanisms One common mechanism is through a digital signature The record transaction message is hashed and then the hash is digitally signed Anyone using only publicly available information e g the public signing key and the hashing signature algorithms used can verify that the purported record has not been changed by validating the digital signature on it If the hash value is different the record has been changed and must not be regarded as valid If the digital signature cannot be verified the association of the record with the purported sender must not be regarded as valid U FOUO A second way to provide integrity is to use Message Authentication Codes MACs and specifically Hashed Message Authentication Codes HMACs In an HMAC a shared secret such as an AES symmetric key is known by both Alice and Bob but no one else The shared secret is added to the record and then the entire quantity is hashed The integrity of the message can be validated by anyone who knows the shared secret simply re-calculate the hash given the purported record If it validates the record was created by someone who knows the shared secret if not the record has been modified and must not be regarded as valid U FOUO Both of these methods have potential weaknesses In the digital signature method if the private signature key is compromised anyone can create a new record saying whatever the attacker wants hash and sign it and it will be accepted as legitimate by anyone validating the record Possession of a signed record in that case indicates that the record has not been changed since it was generated but it does not prove anything about who generated the record or when nor indeed show that Alice or Bob had anything to do with the record U FOUO The HMAC method is vulnerable to compromise of the shared secret i e the symmetric key If Mal knows the shared AES key used by Alice and Bob Mal can create whatever records he wants This prevents anyone from making valid statements about whether Alice or Bob is responsible for a record U FOUO In addition both methods are vulnerable to weaknesses in or attacks against the hash algorithm used If it is possible to invert a hash i e given a hash value find a valid message that results in that hash value then an attacker could create or modify records undetectably UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-119 UNCLASSIFIED FOR OFFICIAL USE ONLY 6993 6994 6995 6996 6997 6998 6999 7000 7001 7002 7003 7004 7005 7006 7007 7008 7009 7010 7011 7012 7013 7014 7015 7016 7017 7018 7019 7020 7021 7022 7023 7024 7025 7026 7027 7028 7029 7030 7031 7032 2 3 3 6 1 2 3 U Time-Stamping U FOUO As noted above non-repudiation services are vulnerable to after-the-fact attacks such as the compromise of a private signature key An attacker Mal who learns Alice's private signature key can create records and then back-date them Mal can for example create records indicating Alice promised to pay him money several years ago U FOUO This attack is particularly worrisome in the context of non-repudiation in situations in which Alice may want to repudiate a record That is Alice may promise to pay Bob a large sum of money but then want to back out of the obligation Alice may even try to deliberately disclose her private signature key By showing that the key was compromised she can then cast doubt as to whether she was the real originator of the record and thus may be able to avoid her obligation U FOUO To combat this attack a system can employ trusted time-stamp and notary services These services support the non-repudiation service by supplying proof of when information was signed In a trusted time-stamp service a neutral but trusted third party creates a record of when some specific record existed That is the time-stamping service certifies e g through a digital signature of its own that a record R of Alice's actions existed at time T Later on if there is a question about the validity of some action this record can be consulted For example if Alice's private key is compromised and a record R' is produced that is dated before time T but there is no time-stamp of R' from the time-stamping service R' will be rejected as invalid However if Alice tries to repudiate her original record R by showing that her private key was compromised but the time-stamped record existed before the compromise then the validity of the record would be upheld U FOUO In order to provide a time-stamping service a number of items are needed First the time-stamping service needs access to a clock whose accuracy is accepted by all parties That is it should not be possible to manipulate the clock to deliberately set the time ahead or back Similarly the clock drift must be acceptably small The acceptable drift will depend on specific applications--in some cases millisecond accuracy will be required in others it will acceptable if only the day is correct U FOUO Second the time-stamping service must have a very strong digital signature capability Typically this would be a more secure digital signature capability e g longer private key length more tamper-resistant signing module higher-assurance procedures than regular system users U FOUO Third there must be a way to securely store and retrieve time-stamped records Even if the records cannot be manipulated without detection no useful service has been provided if they cannot be found and used when needed U Some work on time-stamping standards and requirements has been done For example the IETF has developed RFC 3161 Internet X 509 Public Key Infrastructure Time-Stamp Protocol TSP The European Technical Standards Institute ETSI has also developed a number of standards relating to time-stamping for example see ETSI ES 201 733 Electronic Signature Formats UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-120 UNCLASSIFIED FOR OFFICIAL USE ONLY 7033 7034 7035 7036 7037 7038 7039 7040 7041 7042 7043 7044 7045 7046 7047 7048 7049 7050 7051 7052 7053 7054 7055 7056 7057 7058 7059 7060 7061 7062 7063 7064 7065 7066 U FOUO The basic technical requirements of time-stamping can be met with current technology such as PKI-based digital signatures Improving the service requires a stronger PKI such as a future higher-assurance version of the DoD PKI Other improvements in timestamping all rely on stronger procedures and personnel security 2 3 3 6 1 2 4 U Notarization U Time-stamping provides third party evidence that a particular record existed at a specific time A stronger service is digital notarization Notarization adds to the time-stamping service by generating and preserving authenticating evidence such as digital signatures associated X 509 certificates and related certificate validation data e g a validation path or an On-Line Certificate Status Protocol transcript The authentication evidence for a record may itself be signed time-stamped and stored for future use U FOUO Notarization thus shows the complete state of the system--to the extent that it was knowable--when a specific record was generated Notarization not only shows that the record existed at time T but also that at time T the certificates used were not compromised or revoked and that the purported user had been successfully authenticated Any other relevant system state can also be captured U FOUO As with time-stamping a number of items are needed for a notarization service to be provided First it requires time-stamping Second the notarization service must have a very strong digital signature capability Typically this would be a more secure digital signature capability e g longer private key length more tamper-resistant signing module higherassurance procedures than regular system users Third the notarization service needs reliable access to current system information e g certificates Certificate Revocation Lists or OCSP responses authentication information Finally there must be a way to securely store and retrieve notarized records 2 3 3 6 2 U Usage Considerations U FOUO The decision to deploy a non-repudiation service and what type of service to deploy will be influenced by a number of factors These include the costs of service deployment including system and connectivity costs as well as costs in terms of the number of people required to install and maintain the service and the performance costs involved in the actual operations and the benefits gained by deploying the non-repudiation service 2 3 3 6 2 1 U Implementation Issues U FOUO There are a number of implementation issues that must be considered when deploying a non-repudiation service These directly affect the cost staffing levels and level of security required UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-121 UNCLASSIFIED FOR OFFICIAL USE ONLY 7067 7068 7069 7070 7071 7072 7073 7074 7075 7076 7077 7078 7079 7080 7081 7082 7083 7084 7085 7086 7087 7088 7089 7090 7091 7092 7093 7094 7095 7096 7097 7098 7099 7100 7101 7102 7103 7104 7105 U FOUO First the appropriate level of authentication must be selected A non-repudiation service depends completely on the correct authentication of each entity e g each user group process If the authentication system selected is weak e g user-identifier and passwords then it will be relatively easy to defeat the non-repudiation service An attacker can simply guess a user's password or a user attempting to repudiate an action can simply post his password on a public repository Stronger authentication systems such as those based on one-time passwords hardware tokens or biometrics provide better security for a non-repudiation system but are more costly to implement Authentication systems are described in detail in Section 2 1 of this document U FOUO Another issue impacting non-repudiation is key management Whether symmetric cryptography or public-key approaches are chosen there must be some way to securely generate the keys shared secrets distribute them to the proper users revoke them when necessary and in general manage these important data items Key Management is described in detail in Section 2 7 of the Roadmap U FOUO Appropriate time-stamp and notarization services must be deployed if required Access to sufficiently accurate clocks must be secured and servers providing the time stamp and notarization functions must be deployed Sufficient access e g 24 7 uptime with a minimum response time of X or whatever other metric is required to these services must be provided This will create support configuration and maintenance issues U FOUO Records storage and retrieval must be provided The purpose of a non-repudiation service is to be able to prove to a third party if required that an entity did or did not participate in some event Depending on exactly what parameters are chosen the records must be stored for some period of time with access available within a given level of time when required and strong security to protect the records from modification or deletion U FOUO The decisions made for each of these issues have implications in the number of people needed to operate the system the trust and skill level that are required by those people the degree of access and backup required for the systems that implement the function and other management aspects All of these impact the cost of implementing a non-repudiation service and the strength that that service provides 2 3 3 6 2 2 U Advantages U The biggest single advantage to a non-repudiation service is that if implemented properly it can provide a strong level of accountability for individual actions It will be extremely difficult for an entity to falsely deny participation in some event e g there will be strong records that Bob did access particular data or sent a message or received a message 2 3 3 6 2 3 U Risks Threats Attacks U FOUO There are two primary failure modes of a non-repudiation service One is that an entity can successfully repudiate participation in an event in which that entity really did participate The other is that an entity can be wrongly blamed for participating in an even in which that entity did not participate UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-122 UNCLASSIFIED FOR OFFICIAL USE ONLY 7106 7107 7108 U FOUO The risks to the non-repudiation service that would allow either of these failure modes to occur have largely been discussed above They include o U FOUO Compromise of a private key or shared secret allowing attackers to forge or modify records o U FOUO Failure of authentication mechanisms allowing an attacker to successfully assume an identity o U FOUO Failure of the integrity mechanism allowing undetected modifications to records after they have been created o U FOUO Failure of the personnel or procedural security mechanisms allowing attackers access to the system or causing records to not be available for examination when required o U FOUO Insufficient recording time-stamping or notarization services allowing an entity to successfully repudiate an action by for example deliberately compromising a private key or shared secret 7109 7110 7111 7112 7113 7114 7115 7116 7117 7118 7119 7120 7121 7122 7123 7124 7125 7126 7127 7128 7129 7130 7131 7132 7133 7134 7135 7136 7137 7138 7139 7140 7141 7142 U FOUO The biggest risk to a non-repudiation service at this time is that it will be deemed not sufficient by legal authorities when it is required This can only be solved by working through a number of cases and developing a body of case law that shows clearly what is sufficient and what is not sufficient for a true non-repudiation service 2 3 3 6 3 U Maturity Level U FOUO As noted above the technical requirements for a robust non-repudiation service can be met today The issues involved in setting up such a service are mostly legal There is no legal precedent for what is minimally required or acceptable and very little indication from the legal community as to what is acceptable For example the American Bar Association's Information Security Committee has declined to set standards or make recommendations on what is acceptable under U S laws for non-repudiation systems Technical people such as system and application developers are making their best guesses as to requirements However under U S laws any entity can always attempt to deny or repudiate any action and then it becomes a matter for the courts to determine whether the technical measures provided were adequate to prevent a successful false denial Once a body of case law has been established it may well be possible to set more concrete technical standards U FOUO Non-repudiation technology is considered to be Mature TRLs 7 - 9 As noted above the technical solutions are known although individual technical protections could be strengthened The major developments needed are in the process and legal arenas 2 3 3 6 4 U Standards U The standards that address the technical measures required to provide a non-repudiation service include the ISO's 3-part standard 13888 and the European Technical Standards Institute's Electronic Signature Formats work Specific references are listed in Table 2 3-13 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-123 UNCLASSIFIED FOR OFFICIAL USE ONLY Table 2 3-13 U Non-Repudiation Standards 7143 This table is U Name ETSI ES 201 733 ISO 13888-1 ISO 13888-2 ISO 13888-3 7144 7145 7146 7147 7148 7149 7150 7151 7152 7153 7154 7155 7156 7157 7158 7159 7160 7161 7162 7163 7164 7165 7166 7167 Description European Technical Standards Institute Electronic Signature Formats 2000 Available at http webapp etsi org exchangefolder es_201733v010103p pdf International Standards Organization IT security techniques -- Non-repudiation -- Part 1 General 2004 International Standards Organization Information technology -- Security techniques -- Non-repudiation -- Part 2 Mechanisms using symmetric techniques 1998 International Standards Organization Information technology -- Security techniques -- Non-repudiation -- Part 3 Mechanisms using asymmetric techniques 1997 This table is U 2 3 3 6 5 U Cost Limitations U FOUO As noted in the Implementation Issues section above the costs of a non-repudiation system are largely driven by the choices made in how strong the system is to be Costs can be quite large if real-time access to stored records from several years ago is required and if solutions are chosen that require highly-trusted system operators with a very high skill level Other cost factors include the strength of the authentication system and the key management solution required U FOUO The single biggest limitation of a non-repudiation system is that an entity can always attempt to deny having done something and the legal system may or may not accept the evidence provided by the non-repudiation system 2 3 3 6 6 U Dependencies U As noted above a non-repudiation service depends on the proper implementation of a user authentication service a data integrity service and a time-stamping or digital notary service In addition non-repudiation depends on system access controls and system integrity and on the proper enforcement of system procedures and processes to prevent modification or deletion of records 2 3 3 6 7 U Alternatives U There are some alternatives into how a non-repudiation service can be provided It can be based on digital signatures from a PKI It can make use of MACs and HMACs It can use timestamping or digital notary services The strength and robustness of the service needed will determine which choices are needed U If what is desired is a way of proving to a neutral third party that one or more record is valid or that an entity did or did not participate in a transaction there is no alternative to a nonrepudiation service UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-124 UNCLASSIFIED FOR OFFICIAL USE ONLY 7168 7169 7170 7171 7172 7173 7174 7175 7176 7177 7178 7179 7180 7181 7182 7183 7184 7185 7186 7187 7188 2 3 3 6 8 U Complementary Techniques U FOUO Non-repudiation systems can be used in combination with existing authentication and accountability systems to provide a stronger level of user accountability Where the technical measures provided by a non-repudiation service are deemed to be insufficient they can be combined with stronger procedural requirements of personnel security requirements to provide a system of the necessary strength 2 3 3 6 9 U References U ETSI ES 201 733 European Technical Standards Institute Electronic Signature Formats 2000 Available at http webapp etsi org exchangefolder es_201733v010103p pdf U ISO OSI 7498-2 International Standards Organization Information processing systems -Open Systems Interconnection -- Basic Reference Model -- Part 2 Security Architecture 1989 U ISO 13888-1 International Standards Organization IT security techniques -- Nonrepudiation -- Part 1 General 2004 U ISO 13888-2 International Standards Organization Information technology -- Security techniques -- Non-repudiation -- Part 2 Mechanisms using symmetric techniques 1998 U ISO 13888-3 International Standards Organization Information technology -- Security techniques -- Non-repudiation -- Part 3 Mechanisms using asymmetric techniques 1997 U RFC 2104 Krawczyk H M Bellare and R Canetti HMAC Keyed-Hashing for Message Authentication February 1997 Available at http www ietf org rfc rfc2104 txt U RFC 3126 Pinkas D J Ross and N Pope Electronic Signature Formats for long term electronic signatures September 2001 Available at http www ietf org rfc rfc3126 txt 7190 U RFC 3161 Adams C P Cain D Pinkas and R Zuccherato Internet X 509 Public Key Infrastructure Time-Stamp Protocol TSP August 2001 Available at 7191 http www ietf org rfc rfc3161 txt 7189 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-125 UNCLASSIFIED FOR OFFICIAL USE ONLY 7192 7193 7194 7195 7196 2 3 4 U Protection of User Information Gap Analysis U FOUO Table 2 3-14 is a matrix listing basic requirements for secure voice compared with the secure voice-related technologies described in previous sections Their adequacy of the technologies to meet the 2008 attributes is shown Some of the IA attributes do not have RCD capabilities mapped to them because they are below the detail specified in the RCD Table 2 3-14 U FOUO Secure Voice Technology Gap Analysis 7197 This Table is U FOUO Technology Category FNBDT Interop Gateways N A Authentication N A Data Integrity N A Anti-replay protection Bit-error Tolerance Traffic Flow Security Dynamic Routing QoS PoS Support N A IA Attributes Enabler attributes Type 1 Enduser to End-user Confidentiality Dynamic IP Addresses ResourceConstrained Implementation Black Media Gateway Capability FNBDT Voice over IP VoIP Call Control N A IP Encryption Required Capability attribute from RCD IAAU3 IAAU4 IACNF1-IACNF5 IACNF7 IACNF17 IANCM1 IANCM11 IANCM12 IAAU25 IANCM8 IANCM9 IANCM14 IAINT1 IAINT3 IANCM3 IANCM7 IANCM13 IACNF8 IANCM2 N A N A N A N A N A N A N A N A N A N A N A N A N A UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-126 IAAV1 IAAV2 IANCM4 IANCM5 IARC01-IARC03 IARC05 UNCLASSIFIED FOR OFFICIAL USE ONLY This Table is U FOUO Technology Category Interop Gateways N A FNBDT Voice over IP N A VoIP Call Control N A IP Encryption Clear-to-Secure Transition Mobile Environment Support Electronic Rekey Required Capability attribute from RCD N A N A IAKCM1 IAKCM3IAKCM6 IAKCM15 IAKCM16 IAKCM18 IAKCM23 IAKCM32 IAKCM35 IAKCM38 IAKCM39 IAKCM41 IAKCM43 IAKCM45 IAKCM47 IAKCM48 IAKCM50 IAKCM53 IA Attribute Crypto Sync Maintenance Denial of Service Protection Multipoint Operation Key Management IA At tri FNBDT N A N A IAKCM44 This Table is U FOUO UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-127 UNCLASSIFIED FOR OFFICIAL USE ONLY 7198 7199 7200 7201 Table 2 3-15 reflects the gap analysis for the non-real-time application layer technologies i e traditional layered application security session security and web services security The mapping of RCD attributes to the IA Attributes will be provided in a future release Table 2 3-15 U FOUO Gap Analysis for Non-real-time Application Layer Technologies This Table is U FOUO Technology Categories Tradition al Layered Applicatio n Security Session Security Web Services Security Required Capability attribute from RCD Confidentiality Integrity IA Attributes Authentication Labeling Access Control Persistent Security Standards Mature Products Available Technology Deployed This Table is U FOUO 7202 7203 7204 7205 7206 7207 7208 7209 7210 7211 The gaps identified in Table 2 3-16 are based upon an investigation of warfighter requirements The assumption is that CDS technologies are to be used to meet compelling operational requirements These requirements are categorized according to warfighter objectives warfighter protection and environment security physical operational etc The technological capabilities available to meet these requirements were categorized by interdomain transfer i e guards multiple domain access via clients and servers and software applications voice collaboration command and control situational awareness etc with multiple-domain capabilities Supporting technologies e g trusted platforms not specifically applied to CDS will be discussed in their respective enabler descriptions UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-128 UNCLASSIFIED FOR OFFICIAL USE ONLY Table 2 3-16 U FOUO CDS Technology Gap Assessment 7212 This Table is U FOUO Technologies MultipleDomain Servers and Clients Warfighter Objectives Warfighter Protection Guards and Controlled Interfaces CDS-Aware Applications Coordination Planning Task Dissemination Intel Assessment Indications and Warnings Combat ID RCD Capability IAAV4 IAAV8 IACNF16 IAAV4 IAAV8 IACNF16 IAAV4 IAAV8 IACNF16 IAAV4 IAAV8 IACNF16 IAAM8 IAAV4 IAAV8 IACNF16 IAAM8 IAAV4 IAAV8 IACNF16 IAAUD9 IAAV4 IAAV15 IAAV17 IACND8 IACND20 IACM11 IAIAC11 IAIAC12 IAPOL1 IAAM6 IAAM7 IAAM8 IACND9 IACNF15 IAIAC12 IAKCM15 IAKCM29 IAKCM33 IAKCM34 IAKCM53 IAPOL1 IARC05 IAAC4 IAAC5 IAAC6 IAAM4 IAAM11 IAAM12 IAAU12 IAAUD1 IAAUD2 IAAUD3 IAAUD7 IAAUD9 IACM1 IACM5 IACM11 IACND10 IACND12 IACNF1 IACNF2 IACNF3 IACNF4 IACNF5 IACNF7 IACNF11 IACNF12 IACNF13 IACNF16 IACNF17 IAFM1 IAFM2 IAFM3 IAFM4 IAIAC3 IAIAC7 IAIL1 IAIL3 IAIL4 IAIL6 IAIL13 IAIL15 IAIL19 IAIL20 IAINT1 IAINT2 IAINT4 IAIR1 IAIR3 IAKCM29 IAKCM36 IAKCM30 IANMP5 IANRP1 IANRP2 IANRP3 IAPOL1 IAPOL3 IARC02 IARC03 IARC04 IAUAM8 IAAV17 IAPOL1 Warfighter Constrained Resources Environment Cognitive Workload Dynamic Participation Security Environment Remote Support This Table is U FOUO UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-129 UNCLASSIFIED FOR OFFICIAL USE ONLY 7213 7214 7215 7216 7217 7218 7219 7220 7221 7222 2 3 5 U Protection of User Information Recommendations and Technology Timelines U FOUO The following gaps have been identified in the Protection of User Information Enabler Without these the benefits to be gained by this Enabler cannot be fully satisfied 2 3 5 1 U Data-in-Transit U The technology gaps for Data-in-Transit have been categorized as the following types-- Standards Technology and Infrastructure 2 3 5 1 1 U Standards U The following gap areas have been identified in standards associated with Secure Voice applications o U Standards for providing end-to-end QoS for IP systems specifically mechanisms for allowing QoS information to traverse red black boundaries o U FOUO HAIPE standard updates to support dynamic routing in a multi-homed environment QoS dynamic black IP addresses mobility end-system implementations resource-constrained implementations and low-bandwidth high BER environments o U Standards for providing interoperability between Secure Voice over IP systems and Voice over Secure IP systems o U FOUO Standards defining a common interoperable implementation of FNBDT over IP networks including call control gateway operation and user media details o U FOUO Standards defining FNBDT multipoint operation conferencing net broadcast applications o U FOUO Standards defining additional voice coders for FNBDT systems on specific GIG sub-networks o U FOUO Standards defining implementation and enforcement methods for applying Quality of Protection mechanisms to secure voice data o U FOUO Standards allowing Priority Service for authorized voice users 7223 7224 7225 7226 7227 7228 7229 7230 7231 7232 7233 7234 7235 7236 7237 7238 7239 7240 2 3 5 1 2 U Technology U FOUO The following gap areas have been identified in technologies associated with Secure Voice applications 7241 o U FOUO Secure VoIP-enabled gateways 7242 o U FOUO Secure multipoint voice operation conferencing net broadcast applications 7243 7244 7245 U FOUO Specific areas related to trusted applications requiring research include o U FOUO Linkage between a security policy enforced by the trusted application and the security policy enforced by the host platform This is the composition problem which has UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-130 UNCLASSIFIED FOR OFFICIAL USE ONLY been researched off and on without satisfactory results for at least 20 years A side issue to be examined is what happens when the trusted application is implemented on a variety of host platforms and those platforms must communicate and interoperate 7246 7247 7248 7249 o U FOUO Support for complex security policies such as dynamic access control policies like RAdAC o U FOUO Construction of self-protecting applications that can guard themselves against attacks coming through the host platform e g against attacks using disk storage or input devices o U FOUO Work is needed for all types of trusted platforms in the areas of system performance user friendliness and cost-effective security 7250 7251 7252 7253 7254 7255 7256 7257 7258 7259 7260 7261 7262 7263 7264 7265 7266 7267 7268 7269 7270 7271 7272 7273 7274 7275 7276 7277 U FOUO In terms of strengthening the non-repudiation service some technical steps can be taken As noted above potential technical vulnerabilities include compromise of private signature keys or shared secrets inversion of hashing algorithms and inability to securely store and or retrieve records These vulnerabilities can be narrowed through use of a stronger PKI such as a higher-assurance DoD PKI They can be narrowed through more controls on shared secrets and more robust storage retrieval systems Time-stamping and notarization systems can be made more secure against attack e g through the use of trusted operating systems and or firewalls U FOUO Stronger proof of intent is a research area As noted above Alice can claim that she was not adequately presented with all the material she signed or that the information she was presented on her screen did not match what was signed or that her private key was used without her knowledge and consent e g by a Trojan horse program operating on her computer Defending against these claims will require much stronger computer systems These systems must be secure against Trojan horses and other malware being present on the system Software must be more reliable and secure to prevent modifications being made between presenting the material to Alice on her screen and it actually being signed within the system Determining reliably that Alice was presented with the proper material and did understand it requires significant research breakthroughs in the area of computer-human interfaces 2 3 5 1 3 U Infrastructure U FOUO The following gap areas have been identified in infrastructure associated with Secure Voice applications o U FOUO Secure VoIP-enabled gateways UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-131 UNCLASSIFIED FOR OFFICIAL USE ONLY Technology 2004 2006 2008 2010 2012 2014 2016 2018 2020 FNBDT over IP Specification Specification FNBDT Multipoint Capability Implementation New vocoder specification Interoperable VoIP signaling gateways Media gateways support clear-secure transition Priority of Service standards Custom secure VoIP terminals System High VoIP Enclaves Multi-Level voice Traffic on a Common Network VoIP PBXs replace Analog PBX HAIPE version 2 0 Specification Approved HAIPE for end clients HAIPE support for QoS Products Specification Implementation Specification Implementation VoIP call control specification convergence Secure VoIP call control Specification Implementation QoS Specification Convergence Trusted call manager call control proxy server platforms Web Security WebDAV Strong Client Authentication SSL TLS 7278 Increased Use of Certificates Web Services Security This Figure is U FOUO 7279 Figure 2 3-25 U Technology Timeline for Protection of User Information Date in Transit 7280 2 3 5 2 U Cross Domain Solutions U Recommendations for CDS technologies are as follows 7281 7282 o U FOUO Develop trusted platforms that enable users who are not cleared to the highest level of data contained in the platform to use the platform to the level that they are cleared for o U FOUO Develop trusted CDS workstations that allow warfighters to use applications they are accustomed to e g for word processing collaboration situational awareness and planning o U FOUO Develop trusted platforms allowing multiple domain access that can function under the resource constraints of the warfighters e g space weight and power constraints of infantry while supporting critical functionalities e g combat ID secure voice o U FOUO Enhance the functionality of data protection technologies to support information flows between security domains o U FOUO Immediately developed technologies to support cross-domain real-time flows such as voice communications and collaboration among coalition partners 7283 7284 7285 7286 7287 7288 7289 7290 7291 7292 7293 7294 7295 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-132 UNCLASSIFIED FOR OFFICIAL USE ONLY 7296 o U FOUO Created standards for cross-domain technologies that focus on the reality of jointness of warfighter operations o U FOUO Develop common CDS capabilities adequately deploy these Joint solutions and sufficiently train warfighters in the use of these technologies in realistic environments 7297 7298 7299 7300 Technology 2004 2006 2008 2010 2012 2014 2016 2018 2020 Browsing Query Cross Domain Collaboration Suite no end-to-end network protection limited deployment secure end-to-end Cross Domain Voice limited deployment secure end-to-end wide deployment High Risk Attachments Integrated multi-level database Cross Domain Databases Privilege Management ID Management etc Infrastructure Services Cross Domain Failure Mitigation and Containment Wide Spread Use Initial Deployment Dynamic Participant in Cross Domain Flows Access rights expansion from initial configuration Access rights restriction from initial configuration Cross Domain Combat ID Special Purpose Trusted Platforms Multi-Purpose Trusted Platforms Simple Trusted Applications Self Protecting Trusted Applications Trusted Applications Support for Complex Security Policies This Figure is U FOUO 7301 Figure 2 3-26 U Technology Timeline for Protection of User Information Cross Domain Solutions 7302 7303 7304 7305 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 3-133 UNCLASSIFIED FOR OFFICIAL USE ONLY 7306 7307 7308 7309 7310 7311 7312 7313 7314 7315 7316 7317 7318 7319 7320 7321 7322 7323 7324 7325 7326 7327 7328 7329 7330 7331 7332 7333 7334 7335 7336 7337 7338 7339 7340 7341 7342 7343 7344 7345 2 4 U DYNAMIC POLICY MANAGEMENT U FOUO Dynamic Policy Management is the establishment of digital policies for enforcing how GIG assets are managed utilized and protected This includes policies for access control Quality of Protection QoP Quality of Service QoS transport audit computer network defense and policies covering the hardware and software associated with GIG assets GIG assets include all resources within the enterprise including physical devices e g routers servers workstations security components software e g services applications processes firmware bandwidth information and connectivity As this list of assets shows Policy Management is more than just information access It also includes performance management both transport and network management and control enforcement of QoP QoS resource allocation connectivity and prioritization within the transport and enforcement of access to enterprise services which are all critical to GIG availability and end-to-end data-in-transit protections U FOUO Digital policy is the set of rules with which all actions of these assets must comply To achieve enterprise wide end-to-end GIG policy management the policies defining the rules for use of information communications transport management and control functions and service access must be integrated into a cohesive global policy A full range of delegation of authority for policy creation and management including intermediary policies e g departmental domain and local e g mission COI will still reside below the global level U FOUO In addition the GIG must be able to support the policies of non-GIG partners e g Intelligence Community Industry Department of Homeland Security State Department Allied nations NATO who have GIG access This would include establishment of an agreed approach through perhaps an assured information sharing policy for risk measurement risk management and risk acceptance The policy with non-GIG entities would specify things such as U S access and handling rights for allied-restricted data Reciprocally GIG policies must address the access to GIG assets by these partners U FOUO The dynamic aspect of policy management allows for the rapid adjustment of these rules in response to crisis situations that require either a reduction of privileges and accesses or increased latitude These adjustments will change the criteria used to determine how resources are allocated to users and how access control decisions are made U FOUO The GIG must not only support adjustments to policy but also conditional policies The policy for accessing a GIG asset will specify different access rules based upon the conditions that apply to this set of information For example the conditions for Warfighter information may be based upon DEFCON levels and the location of the user while the conditions for business-to-business processes may be based upon the conditions of contracting e g pre-request for proposal RFP coordination RFP release contract award Under each condition a different set of access rules would apply A policy accounts for the various conditions that affect access to that GIG asset The set of conditions are not expected to be global instead policies will specify behavior for the conditions that apply U FOUO Dynamic Policy Management allows the flexibility needed for the right data at the right place at the right time UNCLASSIFIED FOR OFFICIAL USE ONLY 2 4-1 UNCLASSIFIED FOR OFFICIAL USE ONLY 7346 7347 7348 2 4 1 U GIG Benefits due to Dynamic Policy Management U FOUO The IA constructs used to support Dynamic Policy Management provide the following services to the GIG 7349 o U FOUO Create and manage the set of rules that govern all GIG actions 7350 o U FOUO Provide synchronization among enterprise-wide and local policies 7351 o U FOUO Translate and distribute push or pull the digital policy to devices enforcing policy o U FOUO React to situational awareness conditions by changing the behavior of devices 7352 7353 7354 7355 7356 7357 7358 7359 7360 7361 7362 7363 7364 7365 7366 7367 7368 7369 7370 7371 2 4 2 U Dynamic Policy Management Description U FOUO Dynamic Policy Management requires a framework to address policy management from the point of policy creation to policy installation in end devices Included in this framework must also be the ability to dynamically update the policy in response to changing enterprise conditions Figure 2 4-1 provides an architectural framework for discussing the functions and data flows required to perform dynamic policy management at the enterprise-level within the GIG U FOUO Dynamic Policy Management begins with a pre-engineering phase in which the enterprise security policy is validated before entering into the enterprise Pre-engineering of the policy is critical to ensure that policy changes do not have an adverse effect on enterprise performance or security Typically predictive planning through network modeling and simulation tools is used to assess the impact of candidate policy changes on operational risk network loads and network application interactions and to ensure security requirements for asset usage are not violated Local mission-specific policies will undergo similar pre-engineering activities Prior to deployment these candidate policy changes should be advertised to and negotiated with the appropriate approval body The approval body will verify that no additional issues outside of those tested in this phase are applicable to the new policy UNCLASSIFIED FOR OFFICIAL USE ONLY 2 4-2 UNCLASSIFIED FOR OFFICIAL USE ONLY Policy Pre-Engineering Network Modeling Valid Policy Policy Input Point Logical Language Policy Policy Request Policy Repository Policy Request Deconflicted Policy Policy Decision Point Decision Request Response Push Device Specific Commands Config Files Pull Policy Enforcement Point This Figure is U Current Config Error or Event Traffic 7372 7373 Figure 2 4-1 U Notional Architectural Framework for Dynamic Policy Management 7374 U FOUO Validated and approved global and local security policies enter the GIG enterprise at a policy input point The entity entering the policy must be identified and authenticated at the input point The input point must also determine if the entity has the proper authorizations privileges to enter policy Procedures will define how an entity is granted the right to create enter modify policy These privileges to enter modify policy will be tightly controlled to ensure that false policies cannot enter the GIG enterprise The identity of the entity that entered modified the policy will be cryptographically bound to the policy so source and pedigree authentication can be performed The entered policies are coded in a logical language for transfer to a policy repository The policy is also sent to the policy repository in a human readable format so that users can read the policy and better understand its impacts 7375 7376 7377 7378 7379 7380 7381 7382 7383 7384 7385 7386 7387 7388 7389 7390 7391 7392 U FOUO The policy repository performs the main policy configuration management functions in the GIG All GIG policies are securely stored at the policy repository It also performs policy deconfliction to resolve any conflicts between the enterprise-wide policy local missionspecific COI policies and the policies of non-GIG entities e g coalition partners allies civil Homeland Security HLS that have access to the GIG There are specific functions performed or responses provided at a given GIG asset that may be controlled by local users and their mission-specific policies i e COI policies All other functions must be performed in accordance with the rules dictated by enterprise-wide policy This hierarchy of policies is enforced at the policy repository UNCLASSIFIED FOR OFFICIAL USE ONLY 2 4-3 UNCLASSIFIED FOR OFFICIAL USE ONLY 7393 7394 7395 7396 7397 7398 7399 7400 7401 7402 U FOUO Policy deconfliction includes the identification of policy conflicts and a resolution capability that supports automated or human adjudication between multiple policies targeted for the same device suite These deconfliction and synchronization steps are essential to avoid vulnerabilities that could be introduced by incompatible policies The policy repository will generate a log of detected policy conflicts and the resolution outcome so that the policy input point operator can see in English how the new deconflicted policy differs from the original U FOUO The deconflicted policy is provided to a policy decision point PDP The policy decision point is a logical entity that has a centralized role in making policy decisions for itself or for other network elements that request such decisions The PDP performs the following functions which are further described in the following paragraphs 7403 o U FOUO Translates policy into device specific configuration commands 7404 o U FOUO Distributes Synchronizes policy configuration commands to affected policy enforcement points o U FOUO Services policy requests from the policy enforcement points 7405 7406 7407 7408 7409 7410 7411 7412 7413 7414 7415 7416 7417 7418 7419 7420 7421 7422 7423 7424 7425 U FOUO The PDP takes the policy rules stored in the policy repository and translates from the device-independent schema to device-specific configuration commands for the specific network devices to which the policy applies These configuration commands program the network device to recognize the policy conditions and when met perform the policy action U FOUO The PDP also services policy requests from the policy enforcement points If a policy enforcement point does not know what to do when presented with a particular situation or set of conditions it will make a policy request to the PDP asking for guidance The PDP can then either make a decision or send the request further up the policy chain for resolution U FOUO Policy distribution may take place as a result of the creation of a new policy or may be the result of a change in policy The goal is to minimize changes in policies by defining different behaviors based upon different operational or mission conditions within a single policy As the conditions change different behaviors are enforced However dynamic changes must still be supported for situations that require new behavior not anticipated in the original digital policy U FOUO Before the policy can be pushed to the end devices the policy's base logic must be interpreted and transformed into the specific commands understood by each targeted recipient It is envisioned that this process be automated for the GIG These commands must have the right level of policy enforcement granularity for the targeted recipients policy enforcement function i e the policy controlling user information access may require a more dynamic and finer grained policy than a policy controlling connectivity within the Black Core UNCLASSIFIED FOR OFFICIAL USE ONLY 2 4-4 UNCLASSIFIED FOR OFFICIAL USE ONLY 7426 7427 7428 7429 7430 7431 7432 7433 7434 7435 7436 7437 7438 7439 7440 7441 7442 7443 7444 7445 7446 7447 7448 7449 7450 7451 7452 7453 7454 7455 7456 7457 U FOUO This translation function supports the use of commercially available products such as Policy Enforcement Points PEP Usually these commands take the form of configuration files After the files are created and validated the policy is distributed using a push or pull model The push model would be used for policy changes that must take effect immediately because new behavior is needed under a particular condition The pull model can be used in cases in which a policy change is scheduled to take effect at a particular time but is not critical to current operations The targeted device pulls the updated policy from the policy decision point Ensuring the devices receive or retrieve the updated policies in a synchronized manner is a critical aspect of policy distribution U FOUO A PEP is a GIG asset with the responsibility of conforming to and enforcing the GIG rules e g which entities can access which resources what functions can entities perform PEPs will be able to react and implement one or more policy rules based on an input trigger that denotes a change in condition These conditions will signify operational conditions or mission environment changes Because the digital policies encode different behavior under different conditions the PEP will implement the new rules without requiring redistribution of policy configuration information from a central source The trigger could be automated or manual such as an operator command If the policy rules to implement are ambiguous e g multiple conditions exist concurrently intervention may be necessary to resolve the ambiguity U FOUO The actual enforcement function is addressed in the Policy-Based Access Control IA System Enabler Section 2 2 The policy management functions performed at the PEP includes policy receipt by push or pull policy storage and policy error or event handling When errors or events are detected the PEP identifies these conditions to the policy repository for resolution Examples of errors or events are receipt of a configuration file that a device does not know how to use receipt of a corrupted configuration file or inability to pull a policy from a decision point at the specified time or under the specified condition U FOUO Throughout the dynamic policy management architectural framework is the need for security services and mechanisms to protect the policy throughout its life cycle From the point of creation to installation in the policy enforcement point every GIG entity handling digital security policies must maintain the integrity of policy information for policy-at-rest and policyin-transit throughout the management infrastructure In addition GIG assets must maintain integrity of the source of origin for policy throughout the management infrastructure Confidentiality protection must be provided if the policy resident at the GIG asset requires it 7466 U FOUO Security Services must be applied to actions within Dynamic Policy Management Every entity sending or receiving policy information must be identified and authenticated In addition their privileges to send receive and modify policy as well as to send error or event messages to the policy repository must be validated The integrity of the policies being promulgated must also be validated each time they are distributed and used Other pervasive security services include the logging of all policy management transactions and the assured availability of the management infrastructure As a critical aspect to maintain the security posture of the GIG the availability of policy input repository decision and enforcement points is vital to nearly all GIG functions 7467 U FOUO In summary the policy life cycle includes 7458 7459 7460 7461 7462 7463 7464 7465 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 4-5 UNCLASSIFIED FOR OFFICIAL USE ONLY o U FOUO A pre-engineering phase in which the security policy is validated before being used 7470 o U FOUO A policy creation phase where policies enter the GIG enterprise 7471 o U FOUO Policy deconfliction to resolve the conflicts between all the policies 7472 o U FOUO Policy distribution targeting which GIG assets should receive the digital policy and translating the base logic of the policy into device specific commands o U FOUO An installation phase in which policy is installed or replaces existing policy in end devices o U FOUO Security services and mechanisms are used to authenticate and protect the integrity availability and confidentiality of the policy throughout its life cycle 7468 7469 7473 7474 7475 7476 7477 7478 7479 7480 2 4 3 U Dynamic Policy Management Technologies U FOUO The following technology areas support the Dynamic Policy Management Enabler o U Development of Policies 7481 o U Centralized vs Distributed 7482 o U Elements of the policies o o 7483 7484 o 7485 7486 o U Access Control U FOUO Trust Anchors U FOUO Policy Languages U Distribution of Policies 7487 o U Standard Protocols 7488 o U Security Issues 7489 o o 7490 7491 7492 U Policy Architectures U Policy Directories 2 4 3 1 U FOUO Development of Policies U The development of policy includes the following three sub-sections 7493 o U Centralized vs distributed 7494 o U Elements of the policies 7495 o U Policy languages UNCLASSIFIED FOR OFFICIAL USE ONLY 2 4-6 UNCLASSIFIED FOR OFFICIAL USE ONLY 7496 2 4 3 1 1 U Centralized vs Distributed 7497 2 4 3 1 1 1 U Technical Detail U Centralized Policy Control Several commercial products perform centralized policy management This technology provides a centralized control of network configuration including policy creation maintenance and protection A server is used to define and store the network policies and then distribute the policies out to the remote policy enforcement points with little or no user intervention 7498 7499 7500 7501 7502 7512 U Distributed Policy Control Distributed policy control focuses on large dynamic networks with no central administrative control These are independent Internet domains with dynamic topology and state information In a multi-domain network a number of individuals or service providers interact in a collaborative environment to provide certain services organized according to a set of rules and policies that define how their resources can be shared among them A distributed policy system has no centrally controlled enforcement of the policies Consequently there is no guarantee that policies will be followed as they are prescribed members of a network may fail to--or choose not to--comply with the rules If there is no way of practical physical enforcement of policies then it would be useful to have a normative control mechanism for their soft enforcement sanctions or penalties 7513 2 4 3 1 1 2 U Usage Considerations 7514 2 4 3 1 1 2 1 U Implementation Issues U FOUO Current centralized policy management products are mostly product specific For example the Network-1 Security Solutions CyberwallPLUS product is used to configure firewalls The McAfee R ePolicy Orchestrator R ePO TM product is used to define policies for virus activity desktop firewall policy and spam and content-filtering policies The Pedestal Software's SecurityExpressions product is used to configure Microsoft application policies 7503 7504 7505 7506 7507 7508 7509 7510 7511 7515 7516 7517 7518 7519 7520 7521 7522 7523 7524 7525 7526 7527 7528 7529 7530 7531 7532 U FOUO For decentralized policy management there are implementation issues with the synchronization of a common GIG policy amongst independent network administration systems How do you enforce that all distributed network systems are working from the current GIG policy 2 4 3 1 1 2 2 U Advantages U FOUO Centralized policy controlled systems can be configured so that local users cannot change the policy configurations at the end network devices They can also verify current policy usage through compliance reports This insures that the network is using the correct policy This synchronization of policy is very important to GIG stability and overall security 2 4 3 1 1 2 3 U Risks Threats Attacks U FOUO Centralized policy management requires strong identification authentication and confidentiality protection at the policy server An attack at the centralized policy server could effect all policy enforcement points in the system UNCLASSIFIED FOR OFFICIAL USE ONLY 2 4-7 UNCLASSIFIED FOR OFFICIAL USE ONLY 7533 7534 2 4 3 1 1 3 U Maturity U Examples of centralized policy control products includes the following 7535 o U Network-1 Security Solutions CyberwallPLUS firewall software 7536 o U McAfee R ePolicy Orchestrator R ePO TM 7537 o U Pedestal Software's SecurityExpressions 7538 7539 7540 U FOUO The various sub-technologies of the centralized vs distributed policy control technology area can be generally assigned Technology Readiness Level groups of Early Emerging or Mature 7541 o U FOUO Centralized Policy Management--Emerging TRLs 4- 6 7542 o U FOUO Distributed Policy Management--Early possibly low Emerging TRLs 2 - 4 7543 7544 7545 7546 7547 7548 2 4 3 1 1 4 U Cost Limitations U When comparing centralized vs distributed policy management the centralized approach has less overhead cost Performing the policy creation verification and distribution at a centralized site requires less personnel than a distributed approach where there could be multiple groups of people performing similar tasks 7550 2 4 3 1 1 5 U References U http www esecurityplanet com prodser article php 1431251 7551 U http www networkassociates com us products mcafee mgmt_solutions epo htm 7552 U http infosecuritymag techtarget com 2002 feb testcenter shtml 7553 U http trantor imit kth se vinnova DPBM html 7554 U http www cs wisc edu condor doc ncoleman_tr1481 pdf 7555 7556 2 4 3 1 2 U Elements of the Policies U Two technologies are discussed in this section access control and trust anchors 7557 2 4 3 1 2 1 U Access Control 7558 2 4 3 1 2 1 1 U Technical Detail U FOUO Access control policies consist of a set of rules imposed on all users and devices in the network These rules generally rely on a comparison of the sensitivity of a resource and the possession of corresponding attributes for users or devices attempting to access the resource These rule-based policies can be used by the GIG to enforce access control and other policies 7549 7559 7560 7561 7562 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 4-8 UNCLASSIFIED FOR OFFICIAL USE ONLY 7563 7564 7565 7566 7567 U FOUO Some Public Key Infrastructure PKI programs such as Defense Message System DMS use rule-based policies mostly for access control The GIG includes policies for access control quality of protection quality of service transport audit computer network defense and policies covering the hardware and software associated with GIG assets As these policies grow in complexity so do the number of rules and the deconfliction of these rules 7572 U FOUO These rule-based policies are first entered at the Policy Input Point PIP in an easily recognizable human readable format The PIP serves as a console for an authorized user to create new policies and edit existing policies After the policy is created or updated the PIP performs a translation to a base logic format that is sent to the Policy Repository See section 2 4 2 for more details on PIP 7573 2 4 3 1 2 1 2 U Usage Considerations 7574 2 4 3 1 2 1 2 1 U Implementation Issues U FOUO The GIG will have many rule-based policies There will be enterprise-wide policies local mission-specific COI policies and the policies of non-GIG entities e g coalition partners allies civil HLS Deconfliction of all these policies must take place before a policy is posted for distribution And these rule-based policies will need to be deconflicted each time a new or update policy is introduced 7568 7569 7570 7571 7575 7576 7577 7578 7579 7580 7581 7582 7583 7584 7585 7586 7587 7588 7589 7590 7591 7592 7593 7594 7595 7596 7597 U FOUO There are few deconfliction tools available today to perform this task The KAoS policy service and Rei product have some policy confliction resolution capabilities but these tools will need to be further developed for the GIG program Initial versions of deconfliction tools may require operator intervention to settle conflicts between policies As the deconfliction tools mature this process will become more automated 2 4 3 1 2 1 2 2 U Advantages U FOUO Rule-based policies can be easily expanded to define additional policy by adding new rules This does cause more complicated attributes but with mapping each attribute category to a bit value a very detailed user attribute can be stored in a small package 2 4 3 1 2 1 2 3 U Risks Threats Attacks U FOUO One risk to rule-based policies is in keeping a new policy synchronized amongst the users and devices When new policies are created with additional rules the existing user device attributes may not cover these rules properly and they will need to be updated Automated distribution of policy and electronic updates of users and device attributes are required to keep rule-based policy information synchronized and working properly 2 4 3 1 2 1 3 U Maturity U FOUO Basic rule-based policies are very mature in the PKI world The DMS has been using the Security Policy Information File SPIF with v3 X 509 certificates for five years UNCLASSIFIED FOR OFFICIAL USE ONLY 2 4-9 UNCLASSIFIED FOR OFFICIAL USE ONLY 7598 7599 7600 7601 7602 7603 7604 7605 7606 7607 7608 7609 7610 7611 7612 7613 7614 7615 7616 7617 7618 7619 7620 7621 7622 7623 7624 7625 U FOUO DMS uses the SPIF as a configurable access control mechanism SPIFs contain the information needed to create and interpret security labels Each v3 signature certificate references the SPIF defining the security policy under which the certificate is issued The SPIF is used to interpret Partition Rule Based Access Control PRBAC parameters contained in the X 509 certificate and the object security label The SPIF is directly linked to a security policy When a security policy is changed i e the classifications or security categories are redefined the SPIF associated with that policy must also be changed U FOUO SPIFs are generated and signed by a root authority i e trust anchor and pushed to sub-authorities by a physical distribution path The sub-authorities re-sign the SPIF and post the signed SPIF to the directory The SPIF is also distributed to lower level authorities within the sub-authority's domain Local policy dictates whether end users receive SPIFs through distribution or retrieve them from the directory U FOUO There is enough flexibility in the SPIF to create a fairly complex implementation Since there are no syntactic constraints on the uniqueness of displayable strings for security classifications and security categories it is possible for independent classifications or categories to be assigned the same representation To limit this complexity SPIF implementers shall ensure that all human readable displayable or external representations of security classifications and security categories are unique within a SPIF implementation U FOUO When two security policy domains cross-certify there is the possibility that two or more external policy sensitivities might be mapped to a single local policy sensitivity This many-to-one sensitivity mapping must be carefully managed to prevent unwanted changes in sensitivities when sending data across policy domain boundaries For example a security policy in Domain 2 may be implemented so that both Sensitivity A and Sensitivity B originating in Domain 1 will be mapped to Sensitivity X in Domain 2 The possibility of sensitivities changing when mapped between policy domains must be carefully considered when the two Security Policy Authorities develop equivalencies between their respective security policies U FOUO The various sub-technologies of the access control technology area can be generally assigned Technology Readiness Level groups of Early Emerging and Mature 7626 o U FOUO Rule based access control--Mature TRLs 6 - 9 7627 o U FOUO Adaptive access control--Early TRLs 1 - 3 7628 o U FOUO Deconfliction of policy--Early TRLs 1 - 3 7629 2 4 3 1 2 1 4 U Standards Table 2 4-1 U Access Control Standards 7630 This Table is U Standard SDN 801 Description SDN 801 addresses concepts tools and mechanisms for implementation of access control AC SDN 801 should be used to gain both a global understanding of MISSI access control and as a guide for implementing access control features in MISSI-compliant components SDN 801 is designed to advance from general concepts that introduce access control to more UNCLASSIFIED FOR OFFICIAL USE ONLY 2 4-10 UNCLASSIFIED FOR OFFICIAL USE ONLY This Table is U Standard ANSI INCITS 359-2004 XACML 1 0 7631 7632 7633 7634 7635 7636 7637 7638 7639 7640 7641 7642 7643 7644 7645 7646 Description detailed information on access control tools mechanisms and processes as they apply to realworld communication systems This standard describes Role Based Access Control RBAC features that have achieved acceptance in the commercial marketplace It includes a reference model and functional specifications for the RBAC features defined in the reference model RBAC has become the predominant model for advanced access control because it reduces the complexity and cost of security administration in large networked applications Many information technology vendors have incorporated RBAC into their product line and the technology is finding applications in areas ranging from health care to defense in addition to the mainstream commerce systems for which it was designed The National Institute of Standards and Technology NIST initiated the development of the standard via the INCITS fast track process XACML is an XML-based language or schema designed specifically for creating policies and automating their use to control access to disparate devices and applications on a network This Table is U 2 4 3 1 2 1 5 U Cost Limitations U GIG dynamic policy management performs policy deconfliction to resolve the conflicts between the enterprise-wide policy local mission-specific COI policies and the policies of nonGIG entities There are limitations on how well current access control methods can support this deconfliction process 2 4 3 1 2 1 6 U Alternatives U XACML is an OASIS standard Organization for the Advancement of Structured Information Standards that describes both a policy language and an access control decision request response language both written in XML The policy language is used to describe general access control requirements and has standard extension points for defining new functions data types combining logic etc The request response language lets you form a query to ask whether or not a given action should be allowed and then interpret the result This resulting response always includes an answer about whether the request should be allowed using one of four values Permit Deny Indeterminate an error occurred or some required value was missing so a decision cannot be made or Not Applicable the request can't be answered by this service 7649 2 4 3 1 2 1 7 U References U FORTEZZA R Security Management Infrastructure SMI Concept of Operation CONOP for CipherNET R 3000 CAW 5 0 7650 U SDN 801 ACCESS CONTROL CONCEPT AND MECHANISMS 7651 U http www oasis-open org committees download php 2713 Brief_Introduction_to_XACML html 7647 7648 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 4-11 UNCLASSIFIED FOR OFFICIAL USE ONLY 7652 2 4 3 1 2 2 U FOUO Trust Anchors 7653 2 4 3 1 2 2 1 U Technical Detail U FOUO The purpose of a trust anchor is to serve as a baseline for the validation of some entity action The trust anchor is something that has been accepted through out-of-band means as being valid and reliable For example it can be a public key or certificate corresponding to a private key Without this baseline there is no sound way of validating anything else 7654 7655 7656 7657 7658 7659 7660 7661 7662 7663 7664 7665 7666 7667 7668 7669 7670 7671 7672 7673 7674 7675 7676 7677 7678 7679 7680 7681 7682 7683 7684 7685 7686 7687 U FOUO In some systems the trusted anchor is called a trusted root or root authority The trusted root or root authority is the point at which trust begins in a PKI system The root authority is the certification authority that certifies the existence and quality of other certification authorities in the particular PKI that you wish to use The business and Internet communities are not waiting for some over-arching system to be put into place by governments or agencies They are seizing opportunities as they arise--putting in place systems that they trust and selecting their own root authorities U FOUO The initial loading of a trust anchor in the system MUST be by a trusted out of band means If you receive a trust anchor over the network--how do you know it's good You have no trust anchor to use to validate the new one so you either take a chance that you're being spoofed and accept it and open yourself up to lots of attacks or you refuse to accept it because you can't validate it That is why it is so important that the initial loading of a trust anchor comes from a highly trusted source U FOUO With respect to dynamic policy management how does the policy input point know to trust the person requesting to create or edit GIG policies How does the policy enforcement point verify the policy configuration file received from the policy decision point The answer to these questions starts with the trust anchor U FOUO Once the initial loading of a trust anchor has been accomplished it can be updated or transferred securely over the net See RFC 3157 for details of the Securely Available Credentials SACRED protocol which can be used to securely transfer credentials U FOUO The trust anchor and the personnel managing the trust anchor are the heart of the trust in PKI and other authentication-based systems The consequences of compromise to a trust anchor by malicious intent inadvertent errors or system failures can be severe Hence this trust anchor must be diligently protected Such protection can be provided by placing all cryptographic key management and encryption decryption functions into a trusted tamper-proof hardware device rather than residing in software on a host computer U FOUO Trust anchors operate under a set of rules or policies that describe both the physical and electronic protection of the trust anchor information Failing to follow these rules and policies could cause the revocation or compromise of the trust anchor affecting all authorities users and devices whose authentication path is based on that trust anchor UNCLASSIFIED FOR OFFICIAL USE ONLY 2 4-12 UNCLASSIFIED FOR OFFICIAL USE ONLY 7688 2 4 3 1 2 2 2 U Usage Considerations 7689 2 4 3 1 2 2 2 1 U Implementation Issues U FOUO The main implementation issue with trust anchors is the initial delivery of the trust anchor information If you receive a trust anchor over the network--how do you know it's good It is very important that the initial loading of a trust anchor comes from a highly trusted source 7690 7691 7692 7693 7694 7695 7696 7697 7698 7699 7700 7701 7702 7703 7704 7705 7706 7707 7708 7709 2 4 3 1 2 2 2 2 U Advantages U FOUO Trust anchors provide a fairly simple and straightforward method of verifying authentication paths for users devices and organizations With the help of compromise lists and revocation lists the trust anchor provides the information needed to determine if a message or data is from a valid source 2 4 3 1 2 2 2 3 U Risks Threats Attacks U FOUO Trust anchors must be protected from both physical and electronic attacks due to the implications of a revocation or compromise Trust anchors should be stored in well-protected locked areas Multi-person access to the physical location will reduce the risk of attacks Multiperson access to the workstation or system containing the trust anchor would further reduce attacks Personnel operating the trust anchors should be highly trusted individuals 2 4 3 1 2 2 3 U Maturity U FOUO PKI systems have been using trust anchors for over ten years The trust anchor in a PKI system is usually called the root authority Some PKI systems also support cross certificates which allow certificate path validation between users under different trust anchors U FOUO The various sub-technologies of the trust anchor technology area can be generally assigned Technology Readiness Level groups of Early Emerging and Mature 7710 o U FOUO PKI root authority--Mature TRLs 6 - 9 7711 o U FOUO Cross registration between trust anchors--Emerging TRLs 4 - 6 7712 o U FOUO Trust anchor initial load and updates--Emerging TRLs 4 - 6 7713 2 4 3 1 2 2 4 U Standards Table 2 4-2 U Trust Anchor Standards 7714 This Table is U Standard RFC 3157 Description This document identifies a set of requirements for credential mobility Using SACRED protocols users will be able to securely move their credentials between different locations different Internet devices and different storage media as needed This Table is U UNCLASSIFIED FOR OFFICIAL USE ONLY 2 4-13 UNCLASSIFIED FOR OFFICIAL USE ONLY 7717 2 4 3 1 2 2 5 U References U FORTEZZA R Security Management Infrastructure SMI Concept of Operation CONOP for CipherNET R 3000 CAW 5 0 7718 2 4 3 1 3 U Policy Languages 7719 2 4 3 1 3 1 U Technical Detail U FOUO Policy Languages are used to define policy statements that can be used by networking hardware such as routers firewalls and guards These policy statements can be used for routing access control and QoS purposes 7715 7716 7720 7721 7722 7723 7724 7725 7726 7727 7728 7729 7730 7731 7732 7733 7734 7735 7736 7737 7738 7739 7740 7741 7742 7743 7744 7745 7746 U FOUO Several policy languages exist which may be appropriate for application in the GIG Routing Policy Specification Language Path-based Policy Language Security Policy Specification Language KeyNote and Extensible Access Control Markup Language XACML But most of these languages were designed for one thing such as generate routing tables QoS using differentiated service code points access control using access control lists ACLs etc U FOUO GIG requires dynamic policy management that handles all the required GIG policies including access control RAdAC QoP QoS transport audit computer network defense and policies covering the hardware and software associated with GIG assets To do that either multiple policy languages will be needed to create the overall GIG policy or a more robust policy language needs to be developed that will support all the GIG policies Some existing policy languages such as Ponder KAoS Rei and XACML are flexible in that they allow you to define new policy within the language GIG should further research these flexible policy languages to see which would be best suited for the GIG policies 2 4 3 1 3 2 U Usage Considerations U FOUO RAdAC will need specific capabilities in its access control policy but should fold into the larger GIG dynamic policy effort Some potential technologies that could support access control policy include WS-Policy Standard Deontic Logic such as that implemented in Rei or Ponder and artificial intelligence constructs in PROLOG decision trees or fuzzy logic This section assumes that the distributed functionality e g secure update revocation currency validation and caching for off-line use is provided by the dynamic policy enabler and thus focuses only on RAdAC-specific digital policy needs U FOUO Dynamic Access Control Policy serves as an input to the RAdAC model in order to control its behavior In this usage the policy must be expressive enough to dictate some or all of the following access control characteristics 7747 o U FOUO Minimum number of required inputs to calculate risk and operational need 7748 o U FOUO Relative weighting of the various inputs for risk and operational need 7749 o U FOUO Relative weighting of risk versus operational need for the final decision 7750 o U FOUO Ability to understand in human readable terms the limiting factors LIMFAC that contributed to a failed access attempt 7751 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 4-14 UNCLASSIFIED FOR OFFICIAL USE ONLY o U FOUO Ability to express stateful access control rules e g successive failed access attempts 7754 o U FOUO Ability to express policy according to enterprise and COI roles 7755 o U FOUO Ability to negotiate two or more conflicting access control rules 7756 o U FOUO Ability to negotiate access control policy with neighboring security domains in order to define an access control boundary interface that is agreeable to both sides o U FOUO Ability to express and automatically select between multiple policies based on nationality or security domain o U FOUO Ability to express more granular or more restrictive access control policies at each successive echelon down the chain of command o U FOUO Ability to dynamically tighten or loosen access control policy based on situation INFOCON proximity to enemy forces etc o U FOUO Ability to do all of this very quickly so as not to become the system bottleneck 7752 7753 7757 7758 7759 7760 7761 7762 7763 7764 7765 7766 7767 7768 7769 7770 7771 7772 7773 7774 7775 7776 7777 7778 7779 7780 7781 7782 U FOUO In this first role influencing RAdAC behavior the policy must somehow be able to handle policy exceptions termed dispensations in some deontic languages that are able to authorize otherwise disallowed actions--but only for a limited time period and only for a welldefined set of actions U FOUO Due to national law or immutable operational policy care has to be taken to constrain where dispensations themselves are allowed and not allowed within the policy language For example dispensations may be allowed for dissemination of a classified document to a cleared User without formal access approval given compelling operational need but may never be allowed for an uncleared User Dispensations may be the most appropriate way for digital policy to annotate and reason about a commander's or supervisor's consent for a User's operational need to know a particular piece of information U FOUO Dynamic Access Control Policy also requires expressiveness for RAdAC output For instance the policy engine may recognize a specific request as having a compelling operational need but having too risky an IT Component to release the information to In this case policy should be expressive enough to conclude that an alternate path alternate Course Of Action or COA for this LIMFAC should be examined before arriving at a final access decision In this role policy must be expressive enough to dictate the following alternate COA determinations 7783 o U FOUO Alternate enterprise routing evaluation to obtain higher QoP from end to end 7784 o U FOUO Digital rights restrictions to limit the risk of disclosure or further dissemination o U FOUO Automatic sanitization through a guard or originator process prior to release 7785 7786 7787 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 4-15 UNCLASSIFIED FOR OFFICIAL USE ONLY 7788 o 7789 7790 7791 7792 7793 7794 7795 7796 7797 7798 7799 7800 7801 7802 7803 U FOUO Evaluation of nearby neighbors or superiors who might have more robust IT Components for handling the data as-is U FOUO In this second role influencing RAdAC output the policy must be tightly integrated with the policies that affect management of the IT Components This avoids situations where RAdAC allows access through a given enterprise route but then the enterprise routes the information over a different path because of other decision metrics Digital rights policy enforcement must be tightly integrated with the end user equipment portion of IT Components so that the rights embedded with the information object are strictly enforced U FOUO Finally the policy must be robust enough to meet extremely stringent false negative and false positive rates Since RAdAC would be replacing the traditional Mandatory Access Control model objectively false positives in particular cannot be tolerated for risk of information disclosure Dispensations for exception handling must be constrained in such a way that guarantees select portions of digital access control policy will comply with national law 2 4 3 1 3 2 1 U Implementation Issues U FOUO Current policy management products are mostly vendor specific There are many forms of policy languages for covering routing QoS or access control o 7810 U Routing Policy Specification Language RPSL was developed by the IETF Routing Policy System Working Group RFC 2622 and RFC 2725 RPSL allows a network operator to specify routing policies at various levels in the Internet hierarchy for example at the autonomous system level At the same time policies can be specified with sufficient detail in RPSL so that low-level router configurations can be generated from them RPSL is extensible and new routing protocols and new protocol features can be introduced at any time 7811 o 7804 7805 7806 7807 7808 7809 7812 7813 o U Tier 1 ISP in Australia designed and built Connect's RPSL-based system to manage routing policy and configure routers Problem Policy can easily get very complex and result in very complex router configuration 7820 U Ponder Policy Specification Language Ponder is a declarative object-oriented language for specifying management and security policies for distributed systems It is a role-based access control Ponder is a product of the Imperial College of Science Technology and Medicine in London England It has been developed as part of ongoing research being carried out by the group into the use of policy in distributed systems management Ponder is a general-purpose management language for specifying what actions are performed and how to allocate resources when specific events occur 7821 o 7814 7815 7816 7817 7818 7819 7822 7823 7824 7825 U The Ponder toolkit includes the following o U Ponder Compiler A Compiler framework for the Ponder policy specification language It supports the main features of the Ponder grammar It consists of a Syntax Analyzer a two-pass Semantic Analyzer and the default Java Code Generator for Obligation and Refrain Policies and XML code generator UNCLASSIFIED FOR OFFICIAL USE ONLY 2 4-16 UNCLASSIFIED FOR OFFICIAL USE ONLY o 7826 7827 7828 o 7829 7830 o 7831 7832 U Ponder Policy Editor A customizable text editor for the Ponder language written in Java It has all the basic features of a text editor and includes features that make text editing Ponder Policies easy U Ponder Management Toolkit A Management Toolkit Framework designed to allow for the addition of tools to be managed from a central management console U Ponder also has built-in tools for performing both runtime checking of policy rules and offline checking of policy rules o U The Security Assertion Markup Language SAML is a planned standard for interoperability among Web services security products SAML is developed and maintained by the Organization for the Advancement of Structures Information Standards OASIS organization's XML-Based Security Services Technical Committee SSTC SAML defines a common XML framework for exchanging security assertions between entities for the purpose of exchanging authentication and authorization information o 7845 U Extensible Access Control markup Language XACML XACML is an OASIS standard that describes both a policy language and an access control decision request response language both encoded in XML The policy language is used to describe general access control requirements It has standard extension points for defining new functions data types combining logic etc The request response language lets you form a query to ask whether or not a given action should be allowed and then interpret the result 7846 o U Parthenon Software has produced a suite of Policy products based on XACML It identifies an XML-based language that is used to describe access control requirements for online resources The intent is to allow for efficient machine parsing of arbitrarily complex security policies o U Sun's XACML was developed in Sun Microsystems Laboratories part of Sun Microsystems Inc as an open source implementation of the OASIS XACML standard and was written in the JavaTM programming language This product provides complete support for all the mandatory features of XACML as well as a number of optional features Specifically there is full support for parsing both policy and request response documents determining applicability of policies and evaluating requests against policies All of the standard attribute types functions and combining algorithms are supported and there are interfaces for adding new functionality as needed Sun is looking at adding features to connect XACML and things like SAML or Lightweight Directory Access Protocol LDAP and strong tools support o U Lagash Systems XACML NET is an implementation of the XACML specification released by OASIS in purely Net code C# that can be used by anyone in the Net developer community XACML NET is under the Mozilla public license MPL 1 1 so any software under a license compatible with MPL can use this code 7833 7834 7835 7836 7837 7838 7839 7840 7841 7842 7843 7844 7847 7848 7849 7850 7851 7852 7853 7854 7855 7856 7857 7858 7859 7860 7861 7862 7863 7864 7865 7866 o U KeyNote is a flexible trust-management system designed to work well for a variety of large- and small-scale Internet-based applications KeyNote was designed and developed in 1997 by representatives from AT T Labs Yale University and the University of UNCLASSIFIED FOR OFFICIAL USE ONLY 2 4-17 UNCLASSIFIED FOR OFFICIAL USE ONLY 7873 Pennsylvania It provides a single unified language for both local policies and credentials KeyNote policies and credentials called assertions contain predicates that describe the trusted actions permitted by the holders of specific public keys KeyNote assertions are essentially small highly structured programs A signed assertion which can be sent over an untrusted network is also called a credential assertion Credential assertions which also serve the role of certificates have the same syntax as policy assertions but are also signed by the principal delegating the trust 7874 o 7867 7868 7869 7870 7871 7872 7875 7876 U KeyNote is described in RFC-2704 It has no restrictions on its use and distribution The KeyNote Toolkit is a C language open-source reference implementation and can be obtained at http www crypto com trustmgt kn html o U Rei was developed by the eBiquity Group a research organization that consists of faculty and students from the Department of Computer Science and Electrical Engineering CSEE of UMBC Rei is a policy language based on OWL-Lite Web Ontology Language with a restricted vocabulary that allows policies to be specified as constraints over allowable and obligated actions on resources in the environment Rei also includes logic-like variables which give it the flexibility to specify relations like role value maps that are not directly possible in OWL Rei includes meta policy specifications for conflict resolution speech acts for remote policy management and policy analysis specifications like what-if analysis and use-case management--making it a suitable candidate for adaptable security in the environments under consideration The Rei engine developed in XSB extended Prolog reasons over Rei policies and domain knowledge in Resource Description Framework RDF and OWL to provide answers about the current permissions and obligations of an entity which are used to guide the entity's behavior o U The Web Services Policy Framework WS-Policy was developed by BEA Systems Inc IBM Corporation Microsoft Corporation and SAP AG The WS-Policy specification provides a general-purpose model and corresponding syntax to describe and communicate the policies of a Web service The goal of WS-Policy is to provide the mechanisms needed to enable Web Services applications to specify policy information WS-Policy by itself does not provide a negotiation solution for Web Services WS-Policy is a building block that is used in conjunction with other Web Service and applicationspecific protocols to accommodate a wide variety of policy exchange models o 7904 U Knowledgeable Agent-oriented System KAoS is a collection of component agent services compatible with several popular agent frameworks including Nomads the DARPA CoABS Grid the DARPA ALP Ultra Log Cougaar framework CORBA and Voyager The adaptability of KAoS is due in large part to its pluggable infrastructure based on Sun's Java Agent Services JAS KAoS policy services is developed by The Institute for the Interdisciplinary Study of Human Machine Cognition IHMC under NASA and DARPA sponsorship 7905 o 7877 7878 7879 7880 7881 7882 7883 7884 7885 7886 7887 7888 7889 7890 7891 7892 7893 7894 7895 7896 7897 7898 7899 7900 7901 7902 7903 7906 7907 7908 U KAoS policy services allow for the specification management conflict resolution and enforcement of policies within domains Policies are represented in DAML DARPA Agent Markup Language as ontologies The KAoS Policy Ontologies KPO distinguish between authorizations i e constraints that permit or UNCLASSIFIED FOR OFFICIAL USE ONLY 2 4-18 UNCLASSIFIED FOR OFFICIAL USE ONLY forbid some action and obligations i e constraints that require some action to be performed--or else serve to waive such a requirement Through various property restrictions in the action type a given policy can be variously scoped for example either to individual agents to agents of a given class to agents belonging to a particular group or to agents running in a given physical place or computational environment e g host VM 7909 7910 7911 7912 7913 7914 o 7915 7916 7917 7918 7919 7920 7921 7922 7923 7924 7925 o U KAoS framework supports dynamic runtime policy changes and is extensible to a variety of execution platforms that might be simultaneously running with different enforcement mechanisms Currently KAoS supports agent platforms implemented in Java and Aroma but could be adapted to work with other platforms for which policy enforcement mechanisms are written U Semantic Web Rule Language SWRL was produced as part of the DARPA DAML Program SWRL is built on top of the W3C Ontology layer OWL DL and OWL lite and a subset of RuleML a Rule Markup Language As such SWRL implements Frame Logic that unfortunately omits the Deontic Modal Operators i e 'P' it is permitted that 'O' it is obligatory that and 'F' it is forbidden that SWRL can be used as the logic layer in Berners-Lee's seven-layer model of the Semantic Web See Figure 2 4-2 below Trust Proof rules Logic Digital Signature data Ontology vocabulary data RDF rdfschema self descriptive document XML NS xmlschema Unicode URI This Figure is U 7926 7927 Figure 2 4-2 U Berners-Lee's Seven Layer Model of the Semantic Web 7928 2 4 3 1 3 2 2 U Advantages U FOUO Having one policy language would make it easier for the person managing the GIG policy to understand A single common policy language would also greatly simplify the GIG policy management components i e Policy Input Point Policy Repository and Policy Decision Points 7929 7930 7931 7932 7933 7934 U FOUO A single policy language would also simplify the translation to device specific configuration files needed at the policy enforcement points UNCLASSIFIED FOR OFFICIAL USE ONLY 2 4-19 UNCLASSIFIED FOR OFFICIAL USE ONLY 7935 7936 7937 7938 7939 7940 7941 7942 7943 7944 2 4 3 1 3 2 3 U Risks Threats Attacks U FOUO Need to verify that what is put in the language actually gets translated into the device configuration files correctly This will require verification testing prior to a new policy entering the GIG U FOUO Also need authentication and integrity protection on the messages to prevent spoofing and possibly confidentiality to protect sensitive policy data This can be either implemented directly in the policy protocol--or implemented in a lower layer protocol like IPsec or transport layer security TLS 2 4 3 1 3 3 U Maturity U FOUO Several policy languages are being used by commercial products today 7945 o U Sun's xacml http sunxacml sourceforge net 7946 o U Ponder toolkit http www-dse doc ic ac uk Research policies ponder shtml 7947 o U KeyNote toolkit http lists netfilter org pipermail netfilter 1999October 002634 html 7949 o U KAoS toolkit http www ihmc us research projects KAoS 7950 o U Cisco's QoS Policy Management http www cisco com warp public cc pd wr2k qoppmn o U Nortel's Optivity Suite http www nortelnetworks com products 01 optivity policy index html 7948 7951 7952 7953 7954 7955 U FOUO The various sub-technologies of the policy language technology area can be generally assigned Technology Readiness Level groups of Early Emerging and Mature 7956 o U FOUO Routing and access control languages--Mature TRLs 7 -9 7957 o U FOUO Extensible policy languages--Emerging TRLs 4 - 6 7958 o U FOUO Security incorporated into policy languages--Early TRLs 1 - 3 7959 o U FOUO Verification test of policy languages--Early TRLs 1 - 3 7960 o U FOUO Handling policy conflicts--Early TRLs 1 - 3 7961 2 4 3 1 3 4 U Standards Table 2 4-3 U Policy Language Standards 7962 This Table is U Standard Description Extensible Access Control markup Language XACML provides fine-grained control of authorized activities the effect of characteristics of the access requestor the protocol over which the request is made authorization based on classes of activities and content introspection UNCLASSIFIED FOR OFFICIAL USE ONLY 2 4-20 UNCLASSIFIED FOR OFFICIAL USE ONLY This Table is U Standard XACML Routing Policy Specification Language RPSL Rei KeyNote SDN 801 Security Assertion Markup Language SAML Ponder KAoS 7963 7964 7965 7966 7967 7968 7969 7970 7971 7972 7973 7974 7975 Description RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy Policies can be specified with sufficient detail in RPSL so that lowlevel router configurations can be generated from them RPSL is extensible new routing protocols and new protocol features can be introduced at any time A declarative policy language for describing policies over actions It is possible to write Rei policies over ontologies in other semantic web languages KeyNote provides a simple language for describing and implementing security policies trust relationships and digitally signed credentials SDN 801 provides guidance for implementing access control concepts using both public key certificates and attribute certificates SAML is an XML framework for exchanging authentication and authorization information Ponder is a language for specifying management and security policies for distributed systems KAoS policy services allow for the specification management conflict resolution and enforcement of policies within domains This Table is U 2 4 3 1 3 5 U Cost Limitations U FOUO The policy language used by GIG will need to cover all GIG policies This includes policies for access control QoP QoS transport audit computer network defense and policies covering the hardware and software associated with GIG assets 2 4 3 1 3 6 U Dependencies U FOUO Need compilers to translate the policy language into configuration files that are used by the policy enforcement points These configuration files are mostly vendor specific so a compiler would need to output many different formats U FOUO Also need testing and verification tools to test the policy language statements prior to distribution to the operational environment 2 4 3 1 3 7 U Alternatives U Generate new policy language to securely cover all the GIG policy management needs This would be an expensive and time-consuming task 7977 2 4 3 1 3 8 U References U http www parlay org about policy_management index asp 7978 U www-106 ibm com developerworks library ws-secpol 7979 U http sunxacml sourceforge net guide html 7976 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 4-21 UNCLASSIFIED FOR OFFICIAL USE ONLY 7980 U RFC 2622 7981 U http www comsoc org ni private 2001 jan stone html 7982 U http www doc ic ac uk mss Papers Ponder-Policy01V5 pdf 7983 U http www cis upenn edu keynote 7984 U http rei umbc edu 7985 U http www ihmc us research projects KAoS FinalIHMC_DEIS pdf 7986 U http www parthenoncomputing com 7987 U http sunxacml sourceforge net 7988 U http mvpos sourceforge net 7989 U http msdn microsoft com library default asp url library en-us dnglobspec html ws-policy asp 7990 U http www wiwiss fu-berlin de suhl bizer SWTSGuide KAoS KAoS_Policy_03 pdf 7991 U http www ihmc us research projects KAoS 7992 U http www daml org 2003 11 swrl rules-all html 7993 2 4 3 2 U Distribution of Policies 7994 2 4 3 2 1 U Standard Protocols 7995 2 4 3 2 1 1 U Technical Detail U FOUO Distribution of dynamic material is required to configure the policy enforcement points through the use of GIG policy files After the files are created and validated the policy is distributed using a push or pull model The push model would be used for policy changes that must take effect immediately because new behavior is needed in reaction to the current condition The pull model can be used in cases in which a policy change is scheduled to take effect at a particular time and is not critical to current operations 7996 7997 7998 7999 8000 8001 8002 8003 8004 8005 8006 8007 8008 U FOUO Policy distribution extends from the policy input point to the Policy Enforcement Points PEP PEPs are those GIG assets that enforce the GIG rules See section 2 4 2 for more information on PEP PEPs include routers firewalls guards and other networking equipment that require configuration files to enforce policy Most PEP equipment is currently configured manually by network support personnel But some policy management products are using directories to store policy configuration information and Light-weight Directory Access Protocol LDAP to distribute the configuration files UNCLASSIFIED FOR OFFICIAL USE ONLY 2 4-22 UNCLASSIFIED FOR OFFICIAL USE ONLY 8009 8010 8011 8012 8013 8014 8015 8016 8017 8018 8019 8020 8021 8022 8023 U FOUO These policy enforcement configuration files are generally vendor specific and only support routing and access control policy decisions The policy distribution point will need to know the type of PEP when distributing new policy so that the policy can be in the correct configuration format for the specific PEP U FOUO It is highly critical that the GIG program work with PEP vendors to expand PEP capabilities and possibly standardize policy enforcement configuration files to reduce policy management overhead Common Open Policy Service COPS protocol and Command Line Interface CLI commands are two enforcement configuration formats currently being used U FOUO COPS is a query and response protocol that the PDP and PEP can use to exchange policy information COPS uses the Transmission Control Protocol TCP to transfer the messages U FOUO There are other options for distributing the policy updates Administrators can send users an email with a URL where users can download the update or use a facility such as Microsoft's System Management Server SMS to automatically push the updates out to distributed end points 8026 U FOUO Another alternative is to use the CyberwallPLUS policy pull feature Each time a user logs on to the network the software checks a central policy database to ensure the user has the most current policy configuration 8027 2 4 3 2 1 2 U Usage Considerations 8028 2 4 3 2 1 2 1 U Implementation Issues U Current policy management products are mostly vendor specific Policy distribution formats must be agreeable with the network products receiving the policy information 8024 8025 8029 8030 8031 8032 8033 8034 8035 8036 8037 8038 8039 8040 8041 8042 2 4 3 2 1 2 2 U Advantages U FOUO Automating the distribution of policy information would be a significant savings over the current manual configuration of PEPs To fully take advantage of this automated distribution the integrity and authentication of the delivery must be verifiable to insure that the policy was received unchanged from a trusted source U Having a common distribution protocol would greatly simplify the distribution process to the network components 2 4 3 2 1 2 3 U Risks Threats Attacks U FOUO Policy data must be protected from the time the policy is created at the policy input point to the time the policy reaches the policy enforcement points This requires identification and authentication of the person creating new policies It also requires authentication integrity and confidentiality of the policy data as it passes through the GIG policy management system UNCLASSIFIED FOR OFFICIAL USE ONLY 2 4-23 UNCLASSIFIED FOR OFFICIAL USE ONLY 8043 2 4 3 2 1 3 U Maturity 8044 2 4 3 2 1 3 1 U DMS Example U FOUO DMS has a trusted policy distribution system with both manual and automated procedures With DMS the rule-based access control policy is held in the SPIF An External Source such as a policy making body generates the security policies used by DMS This information is delivered to a root authority in an unsigned SPIF format on a trusted physical path The root authority reviews and approves the security policy before signing the SPIF After signing an SPIF the root authority distributes it to the subordinate authorities that support the security policy defined in the SPIF The root authority can maintain multiple SPIFs but the subordinate authorities only need to receive the SPIFs for the security policy s they support 8045 8046 8047 8048 8049 8050 8051 8052 8053 8054 8055 8056 8057 8058 8059 8060 8061 8062 8063 8064 8065 U FOUO The sub-authority verifies the received SPIF has been signed by the root authority and is valid Next the sub-authority removes the root authority signature updates the issuer and date information and re-signs the SPIF The sub-authority then posts the SPIF to the directory and distributes the SPIF to the rest of the authority hierarchy U FOUO User applications and devices using the SPIF will periodically retrieve the SPIF from the directory verify the signature of the SPIF and use the SPIF for access control decisions 2 4 3 2 1 3 2 U Vendor Distribution Example U FOUO Most network component vendors e g Cisco Juniper Ciena and Nortel have configuration formats and distribution methods that are specific to their equipment Distribution methods include LDAP File Transfer Protocol FTP Telnet and Secure Server Protocol SSP U FOUO The various sub-technologies of the policy distribution technology area can be generally assigned Technology Readiness Level as follows 8066 o U FOUO Distribution protocols--Mature TRLs 7 - 9 8067 o U FOUO PEP configuration file standard--Early TRLs 1 - 3 8068 2 4 3 2 1 4 U Standards Table 2 4-4 U Distribution Standards 8069 This Table is U Standard LDAP File Transfer Protocol FTP Description LDAP is an Internet protocol used to look up information from a LDAP server or directory LDAP servers index all the data in their entries and filters may be used to select just the information you want Permissions and authentications can be set by the administrator to allow only certain people to access the LDAP database and optionally keep certain data private Reference http www ldap-directory org rfc-ldap for a list of LDAP RFCs File Transfer Protocol FTP a standard Internet protocol is the simplest way to exchange files between computers on the Internet FTP is an application protocol that uses the Internet's TCP IP protocols UNCLASSIFIED FOR OFFICIAL USE ONLY 2 4-24 UNCLASSIFIED FOR OFFICIAL USE ONLY This Table is U Standard Common Open Policy Service COPS Microsoft's SMS Telnet 8070 8071 8072 Description Reference RFC959 http www w3 org Protocols rfc959 The Common Open Policy Service COPS protocol is a simple query and response protocol that can be used to exchange policy information between a policy server PDP and its clients PEPs Reference http www networksorcery com enp protocol cops htm for a list of COPS related RFCs SMS provides a solution for change and configuration management for the Microsoft platform enabling organizations to provide relevant software and updates to users quickly and cost effectively The Telnet program allows you to connect your PC to a server on the network using a username and password You can then enter commands through the Telnet program and they will be executed as if you were entering them directly on the server console This Table is U 2 4 3 2 1 5 U Dependencies U FOUO PEP configuration formats are mostly vendor specific Creating a standard for this configuration format would require support from many network component vendors 8075 2 4 3 2 1 6 U Alternatives U FOUO For policy distribution there are many existing protocols that can be used to safely distribute the GIG policy throughout the system 8076 U FOUO GIG-developed common protocol for format of all GIG policy enforcement points 8077 2 4 3 2 1 7 U Complementary Techniques U FOUO Security features can also be applied to policy distribution if required by the GIG program Directories can be configured to limit write access to the policy information so only authorized persons can create and update GIG policy information stored in the directory 8073 8074 8078 8079 8080 8081 8082 8083 8084 8085 U FOUO Authentication and confidentiality can also be applied to the policy distribution by adding additional levels of protection to the policy data A protocol such as Secure Sockets Layer SSL allows the server and client to authenticate each other and to negotiate an encryption algorithm and cryptographic keys before the application protocol transmits or receives its first byte of data One advantage of SSL is that it is application-protocol independent 8088 2 4 3 2 1 8 U References U FORTEZZA R Security Management Infrastructure SMI Concept of Operation CONOP for CipherNET R 3000 CAW 5 0 8089 U http wp netscape com eng ssl3 ssl-toc html 8090 U http www nortelnetworks com products 01 optivity policy index html 8091 U http www parlay org about policy_management index asp 8086 8087 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 4-25 UNCLASSIFIED FOR OFFICIAL USE ONLY 8092 2 4 3 2 2 U Security Issues 8093 2 4 3 2 2 1 U Technical Detail U FOUO Policy data must be protected from the time the policy is created at the policy input point to the time the policy reaches the policy enforcement points This requires identification and authentication of the person creating new policies It also requires authentication and integrity of the policy data as it passes through the GIG policy management system 8094 8095 8096 8097 8098 8099 8100 8101 8102 8103 8104 8105 8106 U FOUO Policy data can provide great value to an attacker to know exactly what rules the infrastructure is enforcing Confidentiality may also be required if the policy data contains sensitive data Having a common configuration file format would also make it easier for an attacker to understand policy changes when they are sent to the PEPs This is another reason confidentiality should be applied to this enforcement configuration file so outside sources cannot change or see the PEP's configuration U FOUO Policy repository directories can be configured to limit the read and write access to policy information so only authorized persons can read and update GIG policy information stored in the directory 8111 U FOUO Authentication and confidentiality can also be applied to the policy distribution by adding more levels of protection to the policy data A protocol such as SSL allows the server and client to authenticate each other and to negotiate an encryption algorithm and cryptographic keys before the application protocol transmits or receives its first byte of data One advantage of SSL is that it is application-protocol independent 8112 2 4 3 2 2 2 U Usage Considerations 8113 2 4 3 2 2 2 1 U Implementation Issues U FOUO Currently none of the policy languages incorporate the security features required for secure GIG dynamic policy distribution So either a new GIG-defined protocol could be developed that includes the security features or existing security protocols e g SSL IPsec or TLS can be added to the policy distribution procedures 8107 8108 8109 8110 8114 8115 8116 8117 8118 8119 8120 8121 8122 8123 8124 8125 8126 8127 2 4 3 2 2 2 2 U Advantages U FOUO Using a COTS solution for policy distribution security provides an immediate cost and schedule advantage over a new secure policy language or policy distribution protocol 2 4 3 2 2 2 3 U Risks Threats Attacks U FOUO Having a secure policy distribution path will greatly reduce the risk of threats or attacks on the dynamic policy management system 2 4 3 2 2 3 U Maturity U FOUO Current COTS solutions e g SSL-TLS or IPsec are very well defined and available The following products are commercially available today and are candidates for GIG secure policy distribution UNCLASSIFIED FOR OFFICIAL USE ONLY 2 4-26 UNCLASSIFIED FOR OFFICIAL USE ONLY 8128 o U SSL-TLS Products 8129 o U F5 Networks Inc Firepass 8130 o U RSA Security Inc RSA BSAFE R SSL-J 8131 o U Thawte Consulting Pty Ltd Thawte SSL Web Server Certificate 8132 o U GeoTrust Inc QuickSSL R Premium 8133 o U Canfone com Web Services eSecure 128-bit SSL Hosting 8134 o U OpenConnect Systems Incorporated Secure ClientConnect 8135 o U Citrix Systems Inc Citrix MetaFrame Access Suite Secure Gateway 8136 o U Entrust Inc Entrust Authority TM Toolkits 8137 o U Ingrian Networks Inc Ingrian i225 - Secure Transaction Platforms 8138 o U VeriSign Inc Managed PKI for SSL Certificate 8139 o U Valicert Inc Valicert SecureTransport TM 8140 o U IPsec Products 8141 o U Check Point Software Technologies Ltd Checkpoint Secure Platform AI R55 8142 o U DrayTek Vigor 3300 Version 8143 o U Enterasys Networks XSR 3000 Series 8144 o U Intoto Inc iGateway 8145 o U NetScreen Technologies Inc NetScreen Security Gateway Product Group 8146 o U Novell Novell BorderManager 8147 o U Secure Computing Sidewinder G2 Firewall 8148 o U Cisco Systems Inc Cisco VPN Client 8149 o U CentricVoice CentricVoice's IPsec VPN 8150 o U Entrust Inc Entrust Authority TM Toolkits 8151 8152 U FOUO The various sub-technologies of the distribution security technology area can be generally assigned Technology Readiness Level groups of Early Emerging and Mature 8153 o U FOUO COTS SSL-TLS and IPsec products--Mature TRLs 7 - 9 8154 o U FOUO Security embedded into policy languages--Early TRLs 1 -3 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 4-27 UNCLASSIFIED FOR OFFICIAL USE ONLY 8155 2 4 3 2 2 4 U Standards Table 2 4-5 U Distribution Security Standards 8156 This Table is U Standard SSL TLS IPsec 8157 8158 8159 8160 8161 8162 8163 Description SSL is designed to make use of TCP as a communication layer to provide a reliable end-to-end secure and authenticated connection between two points over a network RFC2246 The primary goal of the Transport Layer Security TLS Protocol is to provide privacy and data integrity between two communicating applications The protocol is composed of two layers the TLS Record Protocol and the TLS Handshake Protocol At the lowest level layered on top of some reliable transport protocol e g TCP is the TLS Record Protocol The TLS Record Protocol provides connection security that provides confidentiality and integrity TLS is designed as a successor to SSL and is sometimes called SSL V3 0 RFC 2401 Internet Protocol Security generally shortened to IPsec is a framework of open standards that provides data confidentiality data integrity and data authentication between participating peers at the IP layer IPsec can be used to protect one or more data flows between IPsec peers This Table is U 2 4 3 2 2 5 U Cost Limitations U FOUO A limitation with a COTS solution is how DoD PKI or other GIG key credentials would be integrated into COTS products This assumes that GIG policy distribution would require the use of GIG keys 2 4 3 2 2 6 U Alternatives U The alternative to using COTS security solution for policy distribution would be to develop a secure policy distribution protocol for the GIG system 8165 2 4 3 2 2 7 U References U http www faqs org rfcs rfc2246 html 8166 U http www faqs org rfcs rfc2401 html 8167 U http www bitpipe com plist SSL html 8168 U http www bitpipe com plist IPSec html 8169 U http www icsalabs com html communities ipsec certification certified_products 1 0Dindex s html 8164 8170 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 4-28 UNCLASSIFIED FOR OFFICIAL USE ONLY 8171 8172 8173 8174 8175 8176 8177 8178 8179 8180 8181 8182 8183 8184 8185 8186 8187 2 4 3 3 U Policy Management Architectures U FOUO One example of a policy management architecture is described in the paper titled Distributed Multi-National Network Operation Centres by Scott Shyne AFRL David Kidson CRC and Peter George DSTO This paper describes a coalition network management architecture to use between Australia Canada and the U S A This policy-based network management system was developed to manage the coalition domain's network quality of service configuration The system consists of a domain policy integration manager policy distribution points policy enforcement points and policy delivery protocol The high level XML policy statements are used to constitute a defined course of action for coalition domains Each domain must break down the policy into configuration files for use by the network entities for policy enforcement Local policy is introduced at this level to further define domain operations U FOUO Another example is the commercial product SecureSpan by Layer 7 Technologies SecureSpan addresses web service security trust establishment enterprise policy management and dynamic policy from the Transport layer through the Application layer SecureSpan is made up of three major components SecureSpan Manager SecureSpan Gateway and SecureSpan Agent See http www layer7tech com products o U The SecureSpan Manager is a GUI-based application that enables administrators to centrally define provision monitor and audit security and integration policies for Web services o U The SecureSpan Gateway is a rack-mountable high-performance network appliance enforces policy on every Web service provisioned through the SecureSpan Manager The Gateway identifies and processes each message under the policy created for the service It shields access to internal services ensuring that only those messages that meet all security and integration policy requirements are forwarded to the destination service o U The SecureSpan Agent interfaces with client-side applications and automatically negotiates policy-specific security routing and transaction preferences with the SecureSpan Gateway 8188 8189 8190 8191 8192 8193 8194 8195 8196 8197 8200 U FOUO The policy management architecture described in Section 2 4 2 above includes a policy input point policy repository policy decision point and policy enforcement point A technology that supports the policy repository is a policy directory as described below 8201 2 4 3 3 1 U Policy Directories 8202 8205 2 4 3 3 1 1 U Technical Detail U FOUO A policy directory can be used as a repository for policies as well as device information and administrative information needed for policy distribution deconfliction synchronization and promulgation 8206 U FOUO A directory has several beneficial features that can be used in policy management 8198 8199 8203 8204 8207 8208 o U FOUO Directories can provide distributed policy management As the GIG network expands additional directories can be added to handle new or expanded domains UNCLASSIFIED FOR OFFICIAL USE ONLY 2 4-29 UNCLASSIFIED FOR OFFICIAL USE ONLY 8209 o U FOUO Directories also have the ability to shadow or replicate the policy information between policy directories This capability greatly simplifies the maintenance and management of policy information as policies change or as the network grows o U FOUO Directories can also be partitioned to limit access to sensitive data stored in the directory Partitioning can be configured so that only certain users can have write access to the policy information stored in the directory Partitioning can also be used to limit read access to only the policies that apply to a specific user or device 8210 8211 8212 8213 8214 8215 8216 2 4 3 3 1 2 U Usage Considerations 8217 2 4 3 3 1 2 1 U Implementation Issues U Nortel Networks Optivity Policy Services OPS is a software application designed to manage network QoS and network access security The Nortel OPS product uses a directory as the policy repository This directory is used to store policies device information and related administrative information required by OPS 8218 8219 8220 8221 8222 8223 8224 8225 U Netegrity's SiteMinder product and DMS also use a directory to store critical policy information used in making access control decisions 2 4 3 3 1 2 2 U Advantages U FOUO The main advantages to using a directory to store GIG policy information are o U FOUO Directories have flexible storage schemas to store all types of policy information 8228 o U FOUO Directories have defined interface protocols for access to the data 8229 o U FOUO Directories can limit read and write access to the data 8230 o U FOUO Directories have chaining capabilities that can keep information synchronized between different directories 8226 8227 8231 8232 8233 8234 8235 8236 8237 8238 8239 8240 8241 8242 8243 2 4 3 3 1 2 3 U Risks Threats Attacks U FOUO A policy directory would need to be well-protected against improper access to the data stored in the directory Directories have a binding process where they determine if a person requesting access is who they are and if they should be granted access information stored in the directory 2 4 3 3 1 3 U Maturity U FOUO Using directories for storing network and system information is very mature Strong binds and SSL tunnels to directories to make more secure interfaces to the directory data are also in use There may be additional work needed in the directory access security depending on the required level of authentication for the GIG program U FOUO The various sub-technologies of the policy directories technology area can be generally assigned Technology Readiness Level groups of Early Emerging and Mature UNCLASSIFIED FOR OFFICIAL USE ONLY 2 4-30 UNCLASSIFIED FOR OFFICIAL USE ONLY 8244 o U FOUO Directory standards--Mature TRLs 7 - 9 8245 o U FOUO Directory security--Emerging TRLs 4 - 6 8246 2 4 3 3 1 4 U Standards Table 2 4-6 U Directory Standards 8247 This Table is U Standard X 500 Finger whois domain name Description X 500 is a CCITT protocol that is designed to build a distributed global directory It offers decentralized maintenance searching capabilities single global namespace structured information framework and a standards-based directory These are very simple directory formats that are also in use This Table is U 8248 8249 8250 8251 8252 8253 2 4 3 3 1 5 U Alternatives U FOUO Using a database for the policy repository is an alternative to the directory approach The database could store all policy information and a secure interface could be written to control access to the data 2 4 3 3 1 6 U References U http www nortelnetworks com products 01 optivity policy index html 8255 U The Directory Overview of Concepts Models and Service CCITT Recommendation X 500 1988 8256 U http www netegrity com products products cfm page productsoverview 8257 2 4 4 U Dynamic Policy Management Gap Analysis U Gap analysis for the Dynamic Policy Management Enabler indicates that the main areas of future development are as follows 8254 8258 8259 8260 o U FOUO Need to further expand the extensible policy languages to cover the complete set of GIG policies Some existing policy languages such as Ponder KAoS Rei and XACML are flexible in that they allow you to define new policy within the language GIG should further research these flexible policy languages to see which would be best suited for GIG policies o U FOUO Need to develop refine network modeling and simulation tools used to assess the impact of candidate global and local policy configuration changes on operational risk network loads and network application interactions These policy management testing tools must ensure security requirements for asset usage are not violated The Ponder toolkit has some capabilities in this gap area o U FOUO Need to develop automated policy deconfliction tools The KAoS policy service and Rei product have some policy confliction resolution capabilities but these UNCLASSIFIED FOR OFFICIAL USE ONLY 8261 8262 8263 8264 8265 8266 8267 8268 8269 8270 8271 2 4-31 UNCLASSIFIED FOR OFFICIAL USE ONLY tools will need to be further developed for the GIG program Initial versions of this tool may require operator intervention to settle conflicts between policies As the deconfliction tools mature this process will become more automated 8272 8273 8274 8275 8276 8277 8278 8279 8280 8281 8282 8283 8284 8285 o U FOUO Need to develop tools or compilers to translate policy language into a device interpretable language such as a router configuration file These configuration files are generally vendor specific Standardizing the end network device configuration formats would greatly simplify this task U FOUO Technology adequacy is a means of evaluating the technologies as they currently stand This data can be used as a gap assessment between a technology's current maturity and the maturity needed for successful inclusion U FOUO The Table 2 4-7 lists the adequacy of the dynamic policy management technologies with respect to the enabler attributes discussed in the RCD Gray entries currently have no technology available and no research is underway to develop the needed technology The gray grid entries represent insufficient technology Solid black entries are adequate today UNCLASSIFIED FOR OFFICIAL USE ONLY 2 4-32 UNCLASSIFIED FOR OFFICIAL USE ONLY Table 2 4-7 U Technology Adequacy for Dynamic Policy Management 8286 This Table is U Technology categories Policy Policy Trust Distribution languages Anchor Policy Enforcement Configuration IACNF6 IACNF12 IAINT1 IAPOL6 IAIAC8 IAIAC6 IAIAC9 IACM11 IAAV20 IAPOL8 IAPOL9 IAIAC1 IAAUD7 IACNF15 IAPOL5 IAPOL7 IACM2 IACM4 IACM5 IAAV4 IAPOL1 IAPOL3 IAPOL4 IACM9 IARC08 IARC09 Secure solution Enabler Attributes Required Capability attribute from RCD Standard format Verifiable solution Policy synchronization and deconfliction This Table is U 8290 2 4 5 U Dynamic Policy Management Recommendations and Timelines U FOUO The following gaps have been identified in the Dynamic Policy Management Enabler Without these this Enabler cannot be fully satisfied The technology gaps can be of the following types--Standards Technology and Infrastructure 8291 2 4 5 1 U Standards 8287 8288 8289 8292 8293 8294 8295 o U FOUO Standards for specifying policy The policy language needs to cover all GIG policies access control quality of protection quality of service transport audit computer network defense and policies covering the hardware and software associated with GIG assets Candidate policy languages include UNCLASSIFIED FOR OFFICIAL USE ONLY 2 4-33 UNCLASSIFIED FOR OFFICIAL USE ONLY 8296 o U XACML 8297 o U Ponder 8298 o U KAoS 8299 o U Security Assertion Markup Language SAML 8300 o U Rei 8301 o U FOUO Policy deconfliction standard for how to handle policy conflicts 8302 o U FOUO Policy Distribution Standard push and pull including protection of policies at rest and in transit policy validation distribution error and exception handling o U FOUO Standard for managing authorities that can promulgate policy and delegate their authority 8303 8304 8305 8306 2 4 5 2 U Technology o U FOUO Mechanisms and performance analysis of policy specification languages and translation to device interpretable language o U FOUO Performance analysis of various methods of distributing policies pull and push approaches to support Policy Distribution Standard 8311 o U FOUO Methods for performing policy synchronization 8312 o U FOUO Tools for analyzing affects of policy and multiple policy objects on overall system 8314 o U FOUO Life cycle model for policy objects 8315 o U FOUO Application of artificial intelligence heuristics learning systems etc to policy management 8307 8308 8309 8310 8313 8316 8318 2 4 5 3 U Infrastructure U Policy management infrastructure that provides 8319 o U Single Graphical User Interface GUI for managing multiple classes of assets 8320 o U FOUO Tools for translating automated human language policies into policy base logic 8321 o U FOUO Tools for policy deconfliction 8322 o U FOUO Integrity protection for all policy storage and transfer 8323 o U FOUO Authentication services on all policy exchanges 8324 o U FOUO Logging all policy management transactions 8317 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 4-34 UNCLASSIFIED FOR OFFICIAL USE ONLY 8325 8326 8327 8328 8329 8330 8331 8332 o U FOUO Signed receipts in response to received policy information U FOUO Figure 2 4-3 contains technology timelines for the Dynamic Policy Management Enabler These are the results of research completed to date on these technologies These timelines are expected to evolve as the Reference Capability Document and the research of technologies related to these capabilities continues The timelines reflect when the technologies could be available given an optimum set of conditions e g commercial community evolution starts immediately GOTS funding is obtained staffing is available Technology topics with missing timelines indicate areas where further work is needed to identify the milestones Technology 2004 Rule-based Access Control Policy 2006 2008 2010 2012 2014 2016 2018 2020 Manual Rule-based Access Control Policy Initial Policy Conflict Exception Handling Automated Policy Deconfliction Rule-based Policy Language Defined Policy Language Policy Language Extended to other GIG Policies Policy Distribution Distribution Security using COTS Products Secure Policy Distribution Policy Directories Integrated Security with Automated Policy Distribution Policy Directories to support Policy Distribution This Figure is U FOUO 8333 8334 Figure 2 4-3 U Technology Timeline for Dynamic Policy Management 8335 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 4-35 UNCLASSIFIED FOR OFFICIAL USE ONLY 8336 8337 8338 8339 8340 8341 8342 8343 8344 8345 8346 8347 8348 8349 8350 8351 8352 8353 8354 8355 8356 8357 8358 8359 2 5 U ASSURED RESOURCE ALLOCATION U FOUO Assured Resource Allocation Enabler maintains the integrity and availability of all enterprise resources e g communication computing and core services and ensures those resources are available to GIG entities--based on operational needs GIG resources include bandwidth QoS and priority processing cycles access to GIG services the network management system routes and similar assets Management and allocation of these resources are required for the GIG to meet its operational requirements to provide services to users U FOUO This Enabler does not cover the topic of initially designing and implementing the GIG to provide sufficient resources for any end user to accomplish a mission That is more properly the responsibility of systems engineering and design U FOUO This Enabler also does not assume that all GIG users will require resource management services It assumes the capability needs to exist to deconflict shared resources and to support better-than-best effort service for users that require greater QoS or priority to meet their mission needs U FOUO Assured management and allocation includes protecting these management and allocation functions from failures or attacks It also includes ensuring that no attack or failure can put the GIG into a state where customers cannot get resources to at least the level defined in service level agreements SLA U FOUO Assured Resource Allocation must ensure the availability of computing and communications resources to both GIG infrastructure components and end users GIG and nonGIG users processes and services must not be able to exceed their authorizations and thereby deny or degrade or co-opt services of other GIG users U FOUO To meet the GIG 2020 Vision the GIG architecture must support a number of features The essential features include 8360 o U Assured Identities 8361 o U Digital Access Policy 8362 o U IA Policy-based Routing 8363 o U Operational-Based Resource Allocation 8364 o U RAdAC 8365 o U Fault Management Configuration Management Accounting Management Performance Management and Security Management FCAPS 8366 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-1 UNCLASSIFIED FOR OFFICIAL USE ONLY 8367 8368 8369 8370 8371 8372 8373 8374 8375 8376 8377 8378 U FOUO These six features are the components of assured management and control of network resources They combine to provide assurance to the GIG user that requested GIG resources will be available in a securely and equitably managed manner that considers both the nominal normal privilege status of that user in addition to when the GIG user demand privileges are increased or decreased by unique mission or environmental conditions Their notional interactions may be visualized in Figure 2 5-1 U FOUO In Figure 2 5-1 the Assured Resource Allocation Enabler acts as a gating function between GIG resources and GIG users Four of the six components--RAdAC assured identities digital access policies and operational-based resource allocation--act as gate modulators U FOUO IA Policy-based routing is a selected or controlled path within the overall path availability to the user FCAPS has a universal scope of applicability which means that it impacts all the other five architectural requirements GIG Resources Static foundational FCAPS Assured Identities Digital Access Policy Transport domain G A T I N G Dynamic situational RAdAC F U N C T I O N Operational-based Allocation IP Policy-based Routing GIG User This figure is U FOUO 8379 8380 Figure 2 5-1 U FOUO The Role and Components of Assured Resource Allocation UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-2 UNCLASSIFIED FOR OFFICIAL USE ONLY 8381 8382 8383 8384 8385 2 5 1 U GIG Benefits of Assured Resource Allocation U FOUO The Assured Resource Allocation Enabler supports continued operation of the system in the face of design failures and hostile attacks This IA system enabler ensures that there are adequate resources to manage and control the GIG and its attached systems This enabler applies when 8386 o U FOUO All data passes through only GIG-controlled systems 8387 o U FOUO Data is transmitted from one portion of the GIG to another through non-GIG controlled systems GIG management data must also move between portions of the GIG to properly manage resources o U FOUO User data passes from the GIG to end user systems through non-GIG controlled systems GIG management data must flow between the GIG and the end system to ensure proper resource management 8388 8389 8390 8391 8392 8393 8394 U FOUO Assured Resource Allocation provides the following additional benefits to the GIG o U FOUO Ensures allocation of GIG resources to meet operational needs e g priority and preemption o U FOUO Routes information based upon the specified IA policy which must account for factors such as Quality of Protection QoP for the information QoS and priority for the information o U FOUO Provides enforcement of QoP QoS and priority to ensure GIG entities do not exceed their authorizations to deny degrade service of other GIG users o U FOUO Provides network control across multiple disparate networks both within the GIG and across both GIG and non-GIG networks o U FOUO Prevents unauthorized entities from accessing management and control data of the network and network assets 8395 8396 8397 8398 8399 8400 8401 8402 8403 8404 8405 8406 8407 8408 8409 8410 8411 8412 8413 8414 8415 8416 2 5 2 U Assured Resource Allocation Description U FOUO The GIG core will have a management and allocation system consisting of two major components the routing and allocation component and the management and control component Each of the constituent transport programs of the GIG e g Global Information Grid-Bandwidth Expansion GIG-BE Transformational Satellite TSAT and Joint Tactical Radio System JTRS contains these two components This fundamental system enabler addresses the IA aspects of these components U FOUO The management and control component of the GIG is responsible for monitoring the state of each of the GIG infrastructure components e g communication computing and core services and systems This component also reacts to changes in the state e g detecting an attack and reacting to it detecting that a device has failed and taking steps to restart it or route around it UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-3 UNCLASSIFIED FOR OFFICIAL USE ONLY 8417 8418 8419 U FOUO In order to achieve the provisioning of assured management of GIG resources the following functions must be provided by the GIG o U FOUO Transfer of network control i e performance configuration across multiple disparate networks e g TSAT GIG-BE JTRS and security domains to support Operational-Based Resource Allocation o U FOUO QoS CoS integrity and authorization and priority enforcement mechanisms to ensure that prioritization and precedence requirements are met and to defend against attacks that would allow attackers to hijack or monopolize resources by improperly claiming high priority traffic privileges o U FOUO Threat-based Traffic Flow Security for network management data to prevent attackers from gaining information about the topology of the network in violation of a system security policy 8420 8421 8422 8423 8424 8425 8426 8427 8428 8429 8430 8431 8432 8433 8434 8435 8436 8437 8438 8439 8440 8441 8442 8443 8444 8445 8446 8447 8448 8449 8450 8451 8452 8453 8454 8455 U FOUO GIG management and control must function properly for the GIG resource allocation capabilities to be provided This enabler focuses on assured management that provides protection against attacks on the management and control system U FOUO These attacks could take the form of an attacker masquerading as a legitimate management node user and then modifying a component through the management interface for example shutting it down remotely To prevent this there must be controlled management and control interfaces Also only authenticated components and users should be able to modify a component or the system U FOUO In addition management and control communications should be protected from disclosure to unauthorized individuals Disclosure of this type of information reveals substantial details about the network topology and capabilities and could provide an attacker a roadmap for a successful attack U FOUO The routing and allocation component is responsible for establishing and updating information routing paths as necessary This includes the initial route establishment monitoring of the actual flow of data and the ongoing operation of the routing algorithm to modify paths for changing network conditions e g congestion failure attack U FOUO IA policy-based routing is essential The digital policy will stipulate the Quality of Protection required to assure the appropriate security protection is maintained while the data traverses the GIG This differs from standard commercial networks that use metrics based primarily on cost in their routing algorithms Routes are chosen to minimize the cost to the service provider and to the end customer of moving bits across the network Other factors such as latency or who owns the network or components are less frequently used U FOUO The intent of policy-based routing is to guarantee a minimum level of service to users This is generally measured in terms of bandwidth i e they will be able to ship X bits per second latency i e data will take no more than Y seconds to transit from point A to point B or similar measures However GIG routing will also have to factor in the security protection provided by the route and whether this protection is adequate for the QoP required by the data UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-4 UNCLASSIFIED FOR OFFICIAL USE ONLY 8456 8457 8458 8459 8460 8461 8462 8463 8464 8465 8466 8467 8468 8469 8470 8471 8472 8473 8474 8475 8476 8477 8478 8479 8480 8481 8482 8483 8484 8485 8486 8487 8488 8489 8490 U FOUO For security reasons a low-cost route through a network owned by a coalition partner will often be rejected in favor of a higher cost route through a network owned by the U S Government To meet application requirements a route with lower latency will sometimes be selected over a lower-cost route with higher latency e g a terrestrial network will be chosen over a satellite connection U FOUO Routing decisions of this type constitute IA policy-based routing The GIG must support this feature Further the policy must be changeable for dynamic responses to changing conditions and the policy must be protected to ensure an adversary cannot substitute or modify a policy to change operation of the GIG U FOUO QoS CoS encompasses designing and implementing a network and its routing infrastructure so that different types classes of data are treated differently Typically data associated with applications that require real-time delivery with low latency and high likelihood of error-free delivery can be assigned to a class that is forwarded or delivered faster than other traffic which can be delivered with classic Internet Protocol IP best efforts service Examples of data service applications which require low latency near real-time low error rates and high availability include streaming live video and real-time collaboration tool services combining live interactive voice video and whiteboarding capabilities in addition to high quality voice transmissions over IP VoIP using high rate voice coders 32 kbps and above An example of an application that can be delivered with only classic IP best-effort service is e-mail which can be delivered whenever extra resources are available typically any time within the next 5 days An intermediate data service application that does not require low error rates but only needs for the low latency and high availability specifications to be met is secure voice over the FNBDT protocol whose 2 4 kbps Mixed Excitation Linear Prediction MELP vocoder can provide good quality at up to 1% error rates Thus depending upon the specific application requirements a tailored QoS CoS should be available that meets the desired performance specifications U FOUO In order to meet these requirements the GIG must support certain QoS CoS mechanisms However there is often a clash between QoS CoS and security requirements For example QoS CoS is often implemented by having the originator indicate to the infrastructure the type of data being sent so that the core routers can treat it appropriately However doing so can result in a leak of potentially sensitive data around an encryption service and provide an excellent covert channel for attackers to use as they wish Thus research must be done to develop ways to have the GIG support QoS CoS and at the same time meet its security requirements 2 5 3 U Technologies U FOUO The following technology areas support the Assured Resource Allocation Enabler 8491 o U FOUO IA Policy-Based Routing 8492 o U FOUO Operational-Based Resource Allocation 8493 o U FOUO Integrity of Network Fault Monitoring Recovery 8494 o U FOUO Integrity of Network Management Control UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-5 UNCLASSIFIED FOR OFFICIAL USE ONLY 8498 U FOUO Since the last two technology areas Integrity of Network Fault Monitoring Recovery and Integrity of Network Management Control are functionally similar and likely to depend upon the same underlying infrastructures and secure signaling protocols they will be addressed within the same section 8499 2 5 3 1 U FOUO IA Policy-Based Routing 8500 2 5 3 1 1 U Technical Detail U FOUO Since varying levels of data sensitivity will be traversing the future GIG network routing infrastructure--from unclassified up to and beyond Top Secret--the GIG would benefit from a capability for Information Assurance policy-based routing To a certain degree MultiProtocol Label Switching MPLS can provide this attribute However MPLS is a static technique that is not amenable to adaptation and dynamic operation in order to react to changing network conditions Should the network topology change or degrade due to router malfunctions or adversarial denial of service attacks on specific routers certain predetermined MPLS-Labeled Switch Paths LSPs may become similarly broken if they traverse the affected routers 8495 8496 8497 8501 8502 8503 8504 8505 8506 8507 8508 8509 8510 8511 8512 8513 8514 U FOUO Any IA policy-based routing scheme should ideally be adaptive and intelligent enough to dynamically react to and compensate for network element outages In general IA policy-based routing can be viewed as a subset of QoS-based routing where the quality being used as a metric happens to be that of information assurance U FOUO In very simplistic terms the Figure 2 5-2 shows an elementary aspect of how IA policy-based routing can be realized This figure is U 8515 8516 Figure 2 5-2 U FOUO IA Policy-Based Routing UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-6 UNCLASSIFIED FOR OFFICIAL USE ONLY 8517 8518 8519 8520 8521 8522 8523 8524 8525 8526 8527 8528 8529 8530 8531 8532 8533 8534 U FOUO As an example suppose an organization wants to have a subset of its data traffic traffic of its HR human relations group from address range A go through Internet Service Provider ISP 1 and another subset of traffic of its Engineering group from address range B go through ISP2 It uses different ISPs due to the different sensitivity levels of the two traffic flows and to the commensurate trust put in each of the ISPs This is an example of Source-Based Transit Provider Selection--Internet service providers and other organizations can use policybased routing to route traffic originating from different sets of users through different Internet connections across the policy routers U FOUO In general terms Policy-Based Routing PBR provides a mechanism for expressing and implementing the forwarding or routing of data packets based on the policies defined by the network policy administrators It provides a more flexible mechanism for routing packets through routers complementing the existing mechanism provided by routing protocols Routers forward packets to the destination addresses based on information from static routes or dynamic routing protocols--such as Routing Information Protocol RIP Open Shortest Path First OSPF or Enhanced Interior Gateway Routing Protocol Enhanced IGRP R U FOUO Instead of routing by the destination address policy-based routing allows network administrators to determine and implement routing policies to allow or deny paths based on the following 8535 o U Identity of a particular end system 8536 o U Application 8537 o U Protocol 8538 o U Size of packets 8539 o U Security classification level of traffic data packets 8540 o U Security assurance of links router nodes 8541 8542 8543 U FOUO Policies can be defined as simply as My network will not carry traffic from the engineering department or as complex as Traffic originating within my network with the following characteristics will take path A while other traffic will take path B UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-7 UNCLASSIFIED FOR OFFICIAL USE ONLY 8544 8545 8546 8547 8548 8549 8550 8551 8552 8553 8554 8555 8556 8557 8558 8559 8560 8561 8562 8563 8564 8565 8566 8567 8568 8569 8570 8571 8572 8573 8574 8575 8576 8577 8578 8579 8580 8581 8582 8583 8584 U FOUO One of the hallmarks or characteristics of a routing protocol which enables taking into account the IA aspects of both the routing environment and the data packets that are being routed is that the protocol must be flexible This flexibility means different applications can use different paths between the same two points A mechanism that provides for this capability would include the ability to modify at runtime the routing algorithms and property metrics used to generate forwarding tables This would essentially result in routers having more than one forwarding table from which to make forwarding decisions with packets being filtered in order to decide which forwarding table to employ A routing protocol that utilizes this paradigm is the Flexible Intra-AS Routing Environment protocol FIRE developed under the auspices of Defense Advanced Research Projects Agency DARPA in 2000 FIRE is an interior gatewayrouting protocol that allows traffic to be routed based on a set of routing algorithms rather than one algorithm--such as shortest path first U FOUO Today's routing protocols create a single forwarding table for routing decisions These routing decisions are based on a single configured metric generally determined by the specifier of the routing protocol with some modest ability for operators to adjust the metrics The least cost or shortest path based on that metric is usually what is chosen as the best route U FOUO The routing protocols are a closed system--access to routing information is permitted only for participating routers This is not conducive to modern network architectures where adaptive or active networks provide applications greater freedom to specify the routing services needed Current routing protocols do not permit applications to actively participate in the routing of their data and make it difficult for researchers and more importantly network operators to devise and deploy new metrics such as those they might require for QoS routing U FOUO FIRE addresses these problems by substantially enhancing the flexibility of a routing system within an autonomous system FIRE is a link-state routing protocol like Open Shortest Path First OSPF but rather than advertising a single metric as OSPF does a FIRE router will advertise a series of property values such as security cost and bandwidth Properties can be configured by an operator or they can be a value determined at run time Multiple forwarding tables can then be generated from these properties U FOUO In addition FIRE may use path-generation algorithms other than SPF For instance a best path based on highest bandwidth is found by comparing the lowest bandwidth link of all possible paths Of the lowest bandwidth links whichever one has the highest bandwidth belongs to the highest bandwidth path Similar computations would be done if security of specific links were the deciding factor which would be the case in an IA policy-based routing environment U FOUO FIRE separates the routing algorithms from the environment within which these algorithms create forwarding tables Consequently the algorithms are treated as applets that are easily installed and replaced In this respect FIRE has an Active Networks component for expandability In general FIRE would employ a property repository or database for the links nodes in a subject autonomous system AS It would use various routing algorithms especially tailored to security attributes to produce forwarding tables Filters would then be applied to incoming packets to determine which table is appropriate to make a forwarding decision where various criteria determine the path UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-8 UNCLASSIFIED FOR OFFICIAL USE ONLY 8585 8586 8587 8588 8589 8590 8591 8592 8593 8594 U FOUO A protocol such as FIRE can be implemented because many of the traditional baseline routing protocols have extension capabilities For example OSPF and IS-IS allow definition of new state advertisement messages Thus FIRE can be viewed as a evolution of the OSPF baseline capabilities 2 5 3 1 2 U Usage Considerations U FOUO Certain portions of the GIG are likely to require baseline capabilities in support of IA policy-based routing early in the development of the GIG High Assurance Internet Protocol Encryptor HAIPE program products should provide support for routing and QoS by the 2008 timeframe In addition the JTRS Wideband Networking Waveform WNW program should provide for improved support for route selection also in the 2008 timeframe 8598 U FOUO The application of IA policy-based routing techniques may be different depending upon whether the subject portion of the GIG network is wireless as in JTRS or wired as in the GIG-BE core network Wireless networks naturally are more topologically dynamic than wired networks and as such will require more agile IA policy-based routing implementations 8599 U Wireless Applications 8600 U FOUO There has been some research in the area of IA policy-based routing in tactical wireless communications as exemplified by mobile ad hoc networks or MANETs One such study area is Security Aware Ad-hoc Routing SAR--work done by Yi Naldurg and Kravets at the University of Illinois 8595 8596 8597 8601 8602 8603 8604 8605 8606 8607 8608 8609 8610 8611 8612 8613 8614 8615 8616 8617 8618 8619 8620 U FOUO The SAR protocol operates as follows When a route of a particular security level is desired a Route REQuest RREQ message is sent out The RREQ header is encrypted with a group key known only to those nodes in the network at the same trust level who can handle the desired data security level The RREQ packet includes a field indicating the overall required route security level Those intermediate nodes which can decrypt the RREQ then reply with a Route REPly RREP message indicating that they are capable of providing a security guarantee for the path through that node Thus eventually a suitably secure end-to-end path is attained An advantage of the SAR protocol is that it also provides security to the flow of routing protocol messages themselves U FOUO SAR can also be easily incorporated into generic ad hoc routing protocols In general SAR enables the automatic discovery of secure routes in a mobile ad hoc environment Though not optimal the routes that are discovered by SAR come with quality of protection guarantees SAR's integrated security metrics allow applications to explicitly capture and enforce cooperative trust relationships SAR can be built upon a base routing protocol such as Ad hoc On demand Distance Vector AODV in which case it is known as SAODV U FOUO A notional scenario of how this SAR algorithm would operate in tactical applications using JTRS and or WIN-T technologies is depicted in Figure 2 5-3 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-9 UNCLASSIFIED FOR OFFICIAL USE ONLY Secure route through officers only Transmission range Shortest route through private Private Officer General This figure is U 8621 8622 8623 8624 8625 8626 8627 8628 8629 8630 8631 8632 8633 8634 8635 8636 8637 8638 8639 8640 8641 8642 8643 Figure 2 5-3 U FOUO Security-Aware ad-hoc Routing SAR in Tactical Wireless Application U FOUO In the above scenario even though the second General is reachable most quickly by a path through a Private the more secure path may be deemed to be only through those with officer rank The SAR protocol implemented on a tactical Mobile Ad-hoc Networks MANET would allow the discovery of the desired path with an appropriate overall integrated end-to-end security metric Future GIG wireless networks such as JTRS and WIN-T will require similar capabilities so that security attributes can be factored into routing decisions 2 5 3 1 2 1 U Implementation Issues U FOUO Depending upon the restrictions which are to be imposed upon the core GIG router network capabilities for full IA policy-based routing may be similarly restricted For example in the GIG-BE during its initial implementation phases there will be no allowance for unprotected information such as QoS levels specifications to pass from the Red side of the network to the Black side This potentially limits routing options to static ones other than routing around any immediately local router node failures that might occur within the Black Core U FOUO Fortunately the HAIPE specification as written does make allowance for HAIPE encryption devices to be configured so as to bypass certain information fields such as QoS bits IPv6 flow labels etc around the encryption process from the Red to the Black domain However though many HAIPE encryptors will have this inherent capability current IA policies tend to prohibit its use due to potential covert channel vulnerabilities This restriction on an otherwise supported feature is both a GIG-wide implementation issue and a possible limitation to fully dynamic and responsive IA policy-based routing protocols UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-10 UNCLASSIFIED FOR OFFICIAL USE ONLY 8644 8645 8646 8647 8648 8649 8650 8651 8652 8653 8654 8655 8656 8657 8658 8659 8660 8661 8662 8663 8664 8665 8666 8667 8668 8669 8670 8671 8672 8673 8674 8675 8676 8677 8678 8679 8680 8681 8682 8683 8684 8685 2 5 3 1 2 2 U Advantages U FOUO Certainly one of the advantages of a dynamic and flexible IA policy-based routing protocol as could be implemented within the constructs of the previously described FIRE routing environment is that it can be automatically adaptive to changing network conditions and topologies This is compared with static MPLS path configurations which would not be as survivable or as forgiving to network topology modifications especially those that would be seen in instances of denial of service attacks This is due to the fact that MPLS is defined and set up beforehand by the manual configuration of essentially hard-wired network paths for specific traffic classes Indeed the MPLS solution is merely an emulation of a static circuit-switched network solution within the environment of a potentially much more robust and adaptively dynamic packet-switched network fabric 2 5 3 1 2 3 U Risks Threats Attacks U FOUO One of the risks or threats that any network faces is Denial of Service DoS or Distributed Denial of Service DDoS attacks from adversaries A good defense of such attacks would include having a routing protocol or mechanism that is dynamic and proactive in that it would be tied into and integrated with the CND Computer Network Defense Situational Awareness infrastructure of the subject network There has been some research into this idea including some recent work at the University of Arizona Impact Analysis of Faults and Attacks in Large-Scale Networks by Hariri et al http dslab csie ncu edu tw 92html paper pdf Impact%20analysis%20of%20faults%20and%20attacks%20in%20lar ge-scale%20networks pdf U FOUO There is little value in an IA policy-based routing protocol if it only looks at the nominal or normal-condition status of link and nodal security attributes along with the security characteristics of traffic data packets without also having means to compensate for either already occurred or impending partial network router fabric failure due to aggressive denial of service attacks The work at Arizona develops a series of needed metrics including the Vulnerability Index VI Component Impact Factor CIF and System Impact Factor SIF Using these defined metrics it then develops a dynamic proactive QoP routing protocol capable of responding in real time to DDoS router attacks The primary goal is to maintain availability so that essential network traffic is not denied paths to required end destinations This is achieved through close observation and analysis of various router operational metrics such as router buffer utilization number of flows and router request-processing rates 2 5 3 1 3 U Maturity U FOUO Most current routing protocols are based on the policy of finding the shortest path by application of cheapest cost algorithms through the given network for purposes of overall network efficiency and reduction of messaging latency The extension of routing protocol algorithms to include the aspect or metric of path assurance security is relatively recent and thus not nearly as mature Some work in this area has been done for mobile ad hoc networks due to the obvious potential vulnerabilities of wireless networks as compared with more secure wired network infrastructures However some of the ad hoc wireless research results have been extended to the wired domain due to the realization that IA policy-based routing can benefit all networks wired or wireless UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-11 UNCLASSIFIED FOR OFFICIAL USE ONLY 8686 8687 8688 U FOUO The various sub-technologies of the Integrity of Network Management Control Monitoring Recovery technology area can be generally assigned Technology Readiness Level groups of Early Emerging and Mature 8689 o U FOUO Wireless domain flexible assured routing SAR etc --Early TRLs 1 - 3 8690 o U FOUO Security-driven routing protocols FIRE etc --Early to low Emerging TRLs 1 - 4 o U FOUO Basic MPLS-based fixed security routing--Mature TRLs 7 - 9 8691 8692 8695 2 5 3 1 4 U Standards U Draft U S Government Protection Profile on Switches and Routers http niap nist gov ccscheme index html 8696 U Routing Policy Specification Language RPSL 8697 U FOUO There are not many current standards specific to the area of policy-based routing let alone standards that are devoted to the more specific and delineated area of IA policy-based routing One standard under development within the IETF is the Routing Policy Specification Language RPSL The text of the RPSL specification as described in IETF RFC 2622 can be found at http www ietf org rfc rfc2622 txt C Alaettinoglu et al 1999 8693 8694 8698 8699 8700 8701 8710 U FOUO RPSL is merely a language for expressing and conveying routing policies The language defines a maintainer class mntner class object which is the entity that controls or maintains the objects stored in a database expressed by RPSL Requests from maintainers can be authenticated with various techniques as defined by the auth attribute of the maintainer object The exact protocols used to communicate RPSL objects is beyond the scope of RPSL as described by RFC 2622 but it is envisioned that several techniques may be used ranging from interactive query update protocols to store and forward protocols similar to email Regardless of which protocols are used it is expected that appropriate security techniques such as IPsec TLS or PGP MIME would be used 8711 U Routing Policy Specification Language next generation RPSLng 8712 U FOUO The Internet Engineering Steering Group IESG of the IETF has recently initiated work on RPSLng Routing Policy Specification Language next generation to add a new set of extensions to RPSL thus enabling the language to implement routing policies for the IPv6 and multicast address families that are currently used in the Internet Since the GIG will operate within IPv6 environments by mandate as of 2008 it is advantageous that RPSL is undergoing this timely updating process The text of the RPSLng draft can be found at http www radb net rpslng txt L Blunk et al 2004 8702 8703 8704 8705 8706 8707 8708 8709 8713 8714 8715 8716 8717 8718 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-12 UNCLASSIFIED FOR OFFICIAL USE ONLY 8725 U FOUO While the extensions described by RPSLng introduce no additional security threats it should be noted that the original RFC 2622 describing the RPSL standard included several weak or vulnerable authentication mechanisms For example among RPSL-defined mechanisms and constructs the MAIL-FROM scheme can be easily defeated by source email address spoofing Secondly the CRYPT-PW scheme is subject to dictionary attacks and password sniffing if RPSL objects are submitted by unencrypted channels such as email And finally the NONE mechanism option offers no protection for objects 8726 U Related QoS Routing Standards 8727 U FOUO There are currently several existing IETF RFCs devoted to the description of QoSbased routing mechanisms IA policy-based routing is merely a specialized subset of QoS-based routing where the governing QoS is transport security RFC 2386 A Framework for QoS-based Routing in the Internet Crawley et al 1998 describes a framework for extending the current Internet routing model of intra and interdomain routing to support QoS 8719 8720 8721 8722 8723 8724 8728 8729 8730 8731 8732 8733 8734 8735 8736 8737 8738 8739 8740 8741 8742 8743 8744 8745 U FOUO Another relevant IETF standard document is RFC 2676 QoS Routing Mechanisms and OSPF Extensions Apostolopoulos et al 1999 The GIG is expected to use routing protocols such as OSPF or the related Intermediate System to Intermediate System IS-IS protocol U FOUO As can be deduced from its name OSPF normally in its default mode would simply opt to select the shortest path route through a network without taking into consideration any other metrics such as the security or IA attributes of encountered nodes and links Fortunately both OSPF and IS-IS allow modifications of their default operation by the use of extensions such as the provision to enable definition of new LSA link state advertisement messages for updating routing tables As noted in an earlier section an example of a routing implementation environment that could allow for IA policy-based routing is BBN's FIRE Flexible Intra-AS Routing Environment which takes advantage of the extension provisions within OSPF to enable dynamic and adaptive routing capabilities Figure 2 5-4 shows how QoS policy-based routing can be implemented within the OSPF core environment 8746 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-13 UNCLASSIFIED FOR OFFICIAL USE ONLY QoS Route Table Computation QoS Route Table Precomputation Trigger Core OSPF Functions Enhanced Topology Data Base Receive and Update QoS-LSA Path Selection Management QoS Parameter Mapping Local Interface Status Monitor Build and Send QoS-LSA Link State Update Trigger OSPF with QoS Routing Extensions QoS Route Request Client Local Resource Manager This figure is U 8747 8748 Figure 2 5-4 U OSPF Implemented With QoS IA Policy-Based Routing Extensions 8749 U FOUO Observation of the above figure shows that such an adaptive and dynamic routing protocol can manage path selection based not only upon metrics such as perceived nominal security of any given links or nodes but can also factor in such qualities as availability or congestion based upon the residual bandwidth of network links Future users of the GIG will not only demand routing based upon assurance but also upon optimized availability 8750 8751 8752 8753 8754 8755 8756 8757 8758 8759 8760 8761 8762 2 5 3 1 5 U Cost Limitations U FOUO Any IA policy-based routing methodology will have inherent costs and limitations when implemented in the GIG Certainly the installed router software would be more expensive in order to support all of the options presented to a router in so far as assurance-evaluated selectable network paths Other implied costs would reside in a potential multiplicity of forwarding tables within each router rather than a single forwarding table per router Each router would select the relevant forwarding table based upon the IA policy required by the data packet in transit--with more sensitive data choosing the table that yields higher resultant end-to-end assurance levels UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-14 UNCLASSIFIED FOR OFFICIAL USE ONLY 8763 8764 8765 8766 8767 8768 8769 8770 8771 8772 8773 8774 8775 8776 8777 8778 8779 8780 8781 8782 8783 8784 8785 8786 8787 8788 8789 8790 8791 8792 8793 8794 8795 8796 8797 8798 2 5 3 1 6 U Dependencies U FOUO One dependency of the potential evolution and development of a robust enhanced IA policy-based routing protocol is that it be built upon the foundation of an extensible baseline protocol One such protocol which allows for extensibility is the OSPF protocol which is related to the IS-IS protocol both of which the GIG is likely to use U FOUO Another dependency of the development of a robust IA policy-based routing protocol for the future GIG network is that of the required foundation of a GIG standard for Quality of Protection QoP Given a QoP definition whereby specific data entities or packets are to be tagged with information metadata that marks the packets for handling and routing tailored to the sensitivity of the data contents an IA policy-based routing protocol can then use the QoP metadata to optimize the overall network security of the various traffic flow elements 2 5 3 1 7 U Alternatives U FOUO As has been already noted an alternative to a fully implemented IA policy-based routing protocol is the use of static MPLS routing Although this is not as effective and flexible or fine-grained a solution as a dynamic policy-based one it is better than having no provision at all for the protection of sensitive data classes 2 5 3 1 8 U Complementary Techniques U FOUO In addition to being seen as an alternative solution there is no reason why MPLS cannot be used in conjunction with or within the context of a larger framework of an IA policybased routing methodology 2 5 3 1 9 U References U Routing Policy Specification Language RPSL by Alaettinoglu et al http www ietf org rfc rfc2622 txt or http www faqs org rfcs rfc2622 html 1999 U QoS Routing Mechanisms and OSPF Extensions by Apostolopoulos et al http www ietf org rfc rfc2676 txt or http www faqs org rfcs rfc2676 html 1999 U A Framework for QoS-based Routing in the Internet by Crawley et al http www ietf org rfc rfc2386 txt or http www faqs org rfcs rfc2386 html 1998 U Integrating Quality of Protection into Ad Hoc Routing Protocols by Yi Naldurg Kravets http mobius cs uiuc edu publications sci02 pdf 2002 U Security-Aware Ad-Hoc Routing For Wireless Networks by Yi Naldurg Kravets http www csee umbc edu courses graduate CMSC628 spring2002 ppt poonam ppt 2002 talk at UMBC U Security Aware Ad-hoc Routing SAR by Yi Naldurg Kravets http www cs fsu edu yasinsac group slides carter5 pdf 2002 U Routing with Confidence Supporting Discretionary Routing Requirements in Policy Based Networks by Kapadia Naldurg Campbell http choices cs uiuc edu akapadia papers sec_routing pdf UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-15 UNCLASSIFIED FOR OFFICIAL USE ONLY 8800 U FIRE Flexible Intra-AS Routing Environment by Partridge et al http www cs ndsu nodak edu yizhang Presentations FIRE ppt 2000 8801 U http www ir bbn com projects fire architecture architecture html 8802 U http www ir bbn com documents techmemos 8803 U http www ir bbn com documents techmemos TM1245 pdf 8804 U http www ir bbn com documents techmemos TM1244 pdf 8805 U http www ir bbn com documents techmemos TM1265 pdf 8806 U http www ir bbn com documents articles FIREjsac-3-01 pdf 8807 U Impact Analysis of Faults and Attacks in Large-Scale Networks by Hariri et al 8808 8811 http dslab csie ncu edu tw 92html paper pdf Impact%20analysis%20of%20faults%20and%20attacks%20in%20lar ge-scale%20networks pdf also see http dslab csie ncu edu tw 92html paper ppt Impact%20analysis%20of%20faults%20and%20attacks%20in%20lar ge-scale%20networks ppt 2003 8812 U Intelligent Active Routing For Supporting QoS Demands by Tasir et al 8813 http www cntr salford ac uk telecoms_research research_activity abdul_rahman_mohamed_tasir pgnet2002 htm 8814 2002 8815 U Security Cost Routing by Eli Winjum 8816 http web unik no users mobkom presentasjoner Eli_SecurityCost_250803 ppt 2003 8817 U Policy-Based Routing http www cisco com warp public cc pd iosw tech plicy_wp htm 2002 8799 8809 8810 8818 U Configuring Policy-Based Routing 8819 http www cisco com univercd cc td doc product lan cat4000 12_1_19 config pbroute pdf 8820 U QoS Policy Constraint-Based Routing by Wei Sun http www cse ohio-state edu jain cis78899 ftp qos_routing 2000 8821 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-16 UNCLASSIFIED FOR OFFICIAL USE ONLY 8822 2 5 3 2 U FOUO Operational-Based Resource Allocation 8823 2 5 3 2 1 U Technical Detail U FOUO The technical area of operational-based resource allocation is predominantly one of the pure research realm with fairly few examples of fielded systems that employ this capability in an automated sense There are very few commercial efforts in this area--with the common response to the assurance of adequate resources being that of initial over-provisioning of computation and or transport assets so that all potential customers will be adequately served However in the defense military field there has been some research efforts dedicated most recently sponsored by a variety of DARPA programs Future customers of the GIG will expect and demand certain levels of network transport database access and computational services Each customer will have a dynamic changeable user profile that will describe the privileges that are given to that customer The future GIG Privilege Management Infrastructure PMI will necessarily work very closely with a resource allocation system tailored to customer-centric operational demands 8824 8825 8826 8827 8828 8829 8830 8831 8832 8833 8834 8835 8836 8837 8838 8839 8840 8841 8842 8843 8844 8845 8846 8847 8848 8849 8850 8851 8852 8853 8854 8855 8856 8857 U FOUO A traditional example of operational-based resource allocation is the Multi Level Precedence and Preemption MLPP mechanism that has been used for years in the context of the DoD voice telecommunications system It is desirable to have the MLPP paradigm which is nominally only for voice communications control allocation purposes extended to the packetswitching and enterprise services-based GIG environment This extends the MLPP paradigm to coverage of far more system functionality U FOUO As is implied in the MLPP acronym this paradigm allows for an a priori allocation through the precedence route of the limited resource of a telecommunications link to a customer whose rank or privileges exceed those of other potential service customers Precedence decisions are made before the link is fully established Thus this is a somewhat static and nonadaptive process In addition however the preemption process of MLPP enables an already allocated resource of a telecommunications link to be taken away from the initial customer or preempted and to be given to a customer with higher privileges and immediate requirements Hence the preemption process is more dynamic and agile than precedence Both of these capabilities--precedence and preemption--would be useful within the context of the GIG in terms of allocating data transport data storage computation and enterprise service capabilities U FOUO Current DoD Information Resources Management IRM is fairly inconsistent in its mechanisms for the allocation or re-allocation of communications and other services Each separate network service or layer has its own mechanism circuit switched voice uses the MLPP protocol satellite circuits are allocated according to the priorities defined in Chairman of the Joint Chiefs of Staff Instruction CJCSI 6250 01 and the current common user data networks have little or no priority-based assignment capabilities UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-17 UNCLASSIFIED FOR OFFICIAL USE ONLY 8858 8859 8860 8861 8862 8863 8864 8865 8866 8867 8868 U FOUO Rather than have a similarly disjoint solution in the future GIG environment--where the resources of Transformational Satellite TSAT GIG-BE routers JTRS nodes links and NCES services will all be interacting with each other--a common and integrated resource allocation solution is required This solution will be required to span across the boundaries of the various GIG systems Until now however many DoD and Intelligence Community IC networks have avoided the implementation of automatic allocation and re-allocation mechanisms by implementing community of interest COI networks that are small enough to allow for effective manual arbitration The efficiency-driven use of a common GIG infrastructure will force the DoD and IC to address this issue of enterprise-wide automatic resource allocation U FOUO Several programs under the auspices of DARPA have studied the area of dynamic and operational-based resource allocation over five years These include the following 8869 o U QUORUM Project 8870 o U Agile Information Control Environment AICE Program 8871 o U Battlefield Awareness and Data Dissemination BADD Program 8872 8873 8874 U FOUO One methodology for the automation of dynamic operational-based resource allocation developed under DARPA auspices is that of Dynamic Scalable Dependable RealTime Systems DeSiDeRaTa Figure 2 5-5 shows the basic ideas behind DeSiDeRaTa RT paths DeSiDeRaTa Architecture Allocation enactment Metrics Resource discovery Spec file Allocation analysis QoS monitor QoS diagnosis Action selection H W metrics Distributed hardware This figure is U 8875 8876 8877 8878 Figure 2 5-5 U DeSiDeRaTa Architecture for Operational-Based Resource Allocation U FOUO From the above figure it can be seen that DeSiDeRaTa is divided into three vertical groups of functions The left group deals with QoS measurement and analysis the UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-18 UNCLASSIFIED FOR OFFICIAL USE ONLY 8879 8880 8881 8882 8883 8884 8885 8886 8887 8888 8889 8890 8891 8892 8893 8894 central deals with allocation analysis and actions and the right deals with resource analysis or resource situational awareness This model could be applicable to the GIG where resource allocation and re-allocation decisions would be made by adjudication of resource requests against the applicable customer privilege profiles managed within the GIG's PMI Overall control of the DeSiDeRaTa mechanisms would be managed by using a nominal specification file which would consist of the desired and allowed customer QoS and the translatable and relevant required resources These resources would consist of GIG transport computation data storage and enterprise services access U FOUO The next generation of computing and networking is leaning heavily towards the paradigm of distributed computing and networking As distributed real-time systems--such as those that will be found within the GIG--become increasingly popular there is an increasing need of technology that can handle the resource allocation problems presented by distributed computing and networking It is from this basis that DeSiDeRaTa Resource Management has found a grasp in the research community The DeSiDeRaTa project has the goal of producing a Resource Manager that provides the following features o U Specification Language for Hardware Systems including computing resources and networks o U Specification Language for Software Systems including methods of specifying QoS requirements such as real-time scalability and dependability QoS constraints o U QoS Management for instrumentation assessment prediction negotiation and allocation of resources for real-time systems 8895 8896 8897 8898 8899 8900 8901 8902 8903 8904 8905 8906 8907 8908 8909 8910 8911 8912 8913 8914 8915 8916 8917 8918 8919 U FOUO DeSiDeRaTa technology will employ the dynamic path paradigm which is a convenient abstraction for expressing end-to-end QoS objectives of systems and for performing QoS management The DeSiDeRaTa project provides an adaptive resource management approach that is appropriate for systems such as the GIG that expect to experience large variations in workload A distributed collection of computing resources is managed by continuously computing and assessing QoS metrics and resource utilization metrics that are determined a posteriori U FOUO The DeSiDeRaTa project's specification language describes the environmentdependent and operationally-driven features of dynamic real-time systems Also provided is an abstract model that is constructed statically from the specifications and is augmented dynamically with the state of operational environment-dependent features The model is being used to develop algorithms for QoS monitoring QoS diagnosis and resource allocation analysis Experimental results show the effectiveness of the approach for specification of real-time QoS detection and diagnosis of QoS failures and restoration of acceptable QoS by re-allocation of distributed computer and network resources U FOUO Future GIG customers who are given temporary privileges for access to certain GIG resources due to operational exigencies would benefit from the dynamic real-time checking that this protocol potentially affords so that quality of service levels would be maintained and adjusted to satisfy operational requirements In this sense DeSiDeRaTa can be viewed as being simultaneously Proactive and Reactive in its methodology for the allocation and re-allocation of UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-19 UNCLASSIFIED FOR OFFICIAL USE ONLY 8920 8921 8922 8923 8924 8925 8926 8927 8928 8929 8930 8931 8932 8933 8934 8935 8936 8937 8938 8939 8940 8941 8942 resources see http www atl external lmco com overview papers 1117 pdf The DARPA Quorum project analyzed the applicability of DeSiDeRaTa for proactive and reactive resource allocation U FOUO Besides the potentially relevant DeSiDeRaTa protocol there have been other projects done under DARPA auspices in the area of dynamic requirements-driven resource allocation However as already noted this is a relatively new field with few fully mature implementations Most instantiations of resource allocation to date are manually configured as opposed to policy-driven automatic implementations which is the desired end-state of the GIG U FOUO Research done during 2001 by a team at Colorado State University CSU under the auspices and sponsorship of the DARPA AICE and BADD programs concentrated on operational-based dynamic resource allocation for classes of prioritized session and data requests in preemptive heterogeneous networks http www engr colostate edu echong pubs conf pdpta01 pdf The GIG can be viewed as such a large heterogeneous network and certain classes of data within it will be prioritized--based upon the operation of the GIG standard for precedence and preemption U FOUO The work done at CSU could potentially be relevant to the internal specifics of this GIG foundational standard CSU defined network transactions or communication requests as one of either two types Data or Session session being defined as bandwidth access over a certain timespan Furthermore network requests are assigned to a Class and a Priority level within the class For purposes of precedence analysis the request 'worth' is computed as a weighted priority that is a function of the situation war time peace time etc The CSU methodology then devises a scheduling heuristic that reorders customer service requests by maximizing the sum of weighted priorities of the highest class and then works down the class hierarchy 8946 U FOUO An important issue raised by the CSU researchers is the need for a post-preemption scheduler so that any transaction request which is preempted is not lost but is rationally rescheduled in a logically prioritized sense This rescheduling mechanism can be relevant to the development of a GIG Precedence and Preemption standard 8947 2 5 3 2 2 U Usage Considerations 8948 2 5 3 2 2 1 U Implementation Issues U FOUO Any operational-based resource allocation system in the future GIG infrastructure must have the capability for dynamic modification of customer privilege profiles within the PMI Future military commanders will not always require privileges that consistently and persistently put them at the head of the line when it comes to getting requested resources before others Only at times when unique and specific operations are underway will it be necessary for participating individuals to have their privilege status elevated When the subject operation is completed participating GIG customers shall in all likelihood have their privilege status relegated and rebaselined back to their normal levels Since this implies a dynamic privilege management infrastructure it is important that the PMI be robust and secure and that the necessary policy adjudication entities be present to authorize any temporary modifications or elevations of privileges 8943 8944 8945 8949 8950 8951 8952 8953 8954 8955 8956 8957 8958 8959 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-20 UNCLASSIFIED FOR OFFICIAL USE ONLY 8960 8961 8962 8963 8964 8965 8966 8967 8968 8969 8970 8971 U FOUO Operational-based resource allocation can be viewed as an exercise in adaptive information control across a distributed landscape As such the DARPA AICE Program has conducted a number of relevant studies The GIG landscape consists of a number of interconnected disparate networks TSAT terrestrial wired GIG-BE wireless JTRS and WIN-T etc over which resources will be allocated The transport networks themselves are also allocated resources for the transport of user communications sensor data database query results and enterprise services etc There is a need for the study of the global overall control and allocation of these disparate network resources so that the integrated services provided to the subject customer base are maximized and optimized The following figure based upon work for DARPA by S Jones and I Wang of Johns Hopkins Applied Physics Lab http www engr colostate edu echong pubs conf 00985799 pdf illustrates a partitioning of the required signaling to achieve joint resource allocation across disparate networks Commanders AICE Information Policy Management Policy Metrics Adaptive Information Control Requests Requests Response Allocation MetaNet USERS USERS Directives Status DoD Terrestrial GIG-BE JTRS Information Flows Information Flows Commercial Nets DoD Satcom TSAT Physical networks This figure is U 8972 8973 8974 8975 Figure 2 5-6 U Joint Resource Allocation Across GIG Networks U FOUO The above illustration separates the operational-based resource allocation functions into four different but interconnected layers 8976 o U FOUO Physical Network Layer 8977 o U FOUO This layer consists of the independent tactical JTRS terrestrial GIG-BE UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-21 UNCLASSIFIED FOR OFFICIAL USE ONLY satellite TSAT and wireless and commercial Internet networks that will together comprise the end-to-end user GIG fabric They will provide packet routing services and unique QoS capabilities 8978 8979 8980 8981 o U FOUO MetaNet Layer 8982 o U FOUO This layer is the system that facilitates the QoS-based routing through the integrated collection of networks Four aspects of the MetaNet layer include inserting QoS-like capabilities into existing tactical networks to enable dynamic and operationalbased re-allocation of network resources negotiating service requests as an intermediary between the user and individual networks providing end-to-end QoS solutions within a time-constraint and maintaining negotiated end-to-end QoS by dynamically re-routing or renegotiating service o U FOUO Adaptive Information Control AIC Layer 8983 8984 8985 8986 8987 8988 8989 U FOUO This layer provides global content-aware dynamic information flow control employing the services of the MetaNet layer to do so AIC layer features include partitioning of information flows among available logical channels globally optimizing allocation to achieve military users' information flow priorities precedence and preemption and re-allocating resources when necessary due to network QoS degradation 8990 8991 8992 8993 8994 8995 8996 8997 8998 8999 9000 9001 9002 9003 9004 9005 9006 9007 9008 9009 9010 9011 9012 9013 9014 9015 o U FOUO Information Policy Management IPM Layer U FOUO This layer has three primary functions providing users the capability to visualize the impacts of their information control policies relating information policy management to military operations and aiding in the synthesis of effective information control policies It is from this layer that relevant and temporary modifications to GIG customer privilege profiles will be made within the GIG privilege management infrastructure whereby users are allocated the resources sufficient to successfully conduct military operations U FOUO The ultimate objective of the DARPA AICE program is to realize information control and resource allocation in a way that is faster more efficient and more precise than is currently realized-- and in an automatic fashion as opposed to manually 2 5 3 2 2 2 U Advantages U FOUO Certainly one of the advantages of a well constructed operational-based resource allocation system within the future GIG environment is that the overall operation and congestion of the GIG can be optimized to service the most important needs at any given time and in any given theatre of operations This implies that an alternative over-provisioning solution need not be required This thus yields savings in the fielded network infrastructure transport storage and computational equipment This can especially be true in the case of wireless segments of the GIG such as mobile ad hoc networks within the JTRS and WIN-T networks where the network 'mesh' is topologically dynamic and potentially sparse UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-22 UNCLASSIFIED FOR OFFICIAL USE ONLY 9016 9017 9018 9019 9020 9021 9022 9023 9024 9025 9026 9027 9028 9029 9030 9031 9032 9033 2 5 3 2 2 3 U Risks Threats Attacks U FOUO Since resource allocation will be based upon the privileges of requesting GIG customers it is essential that both the specific resource requests and the customer privileges be secure trusted and not subject to tampering or modification by adversaries 2 5 3 2 3 U Maturity U FOUO Maturity of operational-based resource allocation technology is fairly low level especially resource allocation that is automatic as opposed to manual and human operator intensive Resource allocation traditionally has been limited to the scope of small geographic areas as opposed to the world-wide reach of the GIG network U FOUO Future warfighters in 'hot-spots' who require and deserve unique privileges to resource access will need to have special consideration in the allocation of GIG transport computation storage and database access capabilities All of these GIG resources will be distributed It is the coordination and timely delivery of these resource capabilities that will need research and study before this technology area can be said to be in any stage of maturity U FOUO The various sub-technologies of the Integrity of Network Management Control Monitoring Recovery technology area can be generally assigned Technology Readiness Level groups of Early Emerging and Mature o U FOUO MLPP in Defense Information System Network DISN voice telecommunications--Mature TRLs 7 - 9 o U FOUO Adaptive Dynamic distributed resource allocation like DeSiDeRaTa -- Emerging TRLS 4- 6 o U FOUO Operational resource allocation tied to secured adaptive PMI--Early TRLs 1 - 3 9034 9035 9036 9037 9038 9039 9040 9041 9042 9043 9044 9045 9046 2 5 3 2 4 U Standards U FOUO Since there are few commercial or industrial efforts in this technology area such as by the IETF there are not any real standards relevant to operational-based resource allocation As the technology is developed standards within the GIG community should be commensurately developed so as to assure that all participants within the GIG would be using the same protocols As a corollary to the implementation of standards for the actual mechanics of resource allocation or re-allocation a parallel supporting GIG standard will be needed for Precedence and Preemption as a subset of the overall GIG privilege management infrastructure UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-23 UNCLASSIFIED FOR OFFICIAL USE ONLY 9047 9048 9049 9050 9051 9052 9053 9054 9055 9056 9057 9058 9059 9060 9061 9062 9063 9064 9065 9066 9067 9068 9069 9070 9071 9072 9073 9074 9075 9076 9077 9078 9079 9080 9081 9082 9083 9084 2 5 3 2 5 U Cost Limitations U FOUO Any operational-based resource allocation system for the future GIG will have to be cognizant of the possibility that instantaneous local demands in any potential future theatre of operations may exceed the possible delivery capacity in terms of transport throughput etc As such methodologies and technologies that are developed must have built-in mechanisms for intelligent resource trimming and notification and also for intelligent policy-driven arbitration in cases of simultaneous demands by disparate customers for the access to the same common resources 2 5 3 2 6 U Dependencies U FOUO Successful implementation of operation-based resource allocation within the GIG will be dependent upon a number of other developments especially that of the development of a GIG-wide standard for priority and preemption capability This standard would be required to clearly define the priority status levels and classes in which all GIG customers will be assignable in addition to the mechanisms for modifications and reversions to nominal levels of user privileges 2 5 3 2 7 U Alternatives U FOUO An alternative to the necessity of developing an operational-based resource allocation capability within the future GIG is merely to have over-provisioning of required assets computational storage and transport across the future GIG While this may be a potential solution when viewing across the GIG as a whole it will probably not succeed when specific local assets are exceeded by temporarily excessive local demands as could be the case in a theatre of war As such the GIG will require an allocation system that will provide priority claims on assets for those with the highest adjudicated locally-valid privileges 2 5 3 2 8 U Complementary Techniques U FOUO Complementary or subsidiary techniques for the operational-based allocation of resources include those of the traditional MLPP techniques currently used in the circuit-switched DoD DISN voice network There are current efforts under pursuit by DISA to fully implement MLPP capabilities within the future GIG-BE router mesh fabric where voice will no longer be circuit-switched but will instead be VoIP This IP version of MLPP capabilities should be viewed as part of the future integrated overall resource allocation re-allocation infrastructure of the GIG--all driven by an underlying dynamic and secure privilege management infrastructure 2 5 3 2 9 U References U Proactive and Reactive Resource Allocation by Cross Lardieri http www atl external lmco com overview papers 1117 pdf 2000 U A MetaNet Architecture For End-To-End Quality Of Service QoS Over Disparate Networks by Jones Wang http www engr colostate edu echong pubs conf 00985799 pdf 2001 U A QoS Performance Measure Framework for Distributed Heterogeneous Networks by Kim et al http www cs nps navy mil people faculty irvine publications 2000 empdp00_QoSMSHN pdf 2000 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-24 UNCLASSIFIED FOR OFFICIAL USE ONLY 9085 9086 9087 9088 9089 9090 9091 9092 9093 9094 9095 U Applying Intent-Sensitive Policy To Automated Resource Allocation Command Communication and Most Importantly Control by Funk et al http www sift info English publications HICS_AICE-00 pdf 2000 U Dynamic Resource Allocation for Classes of Prioritized Session and Data Requests in Preemptive Heterogeneous Networks by Naik et al http www engr colostate edu echong pubs conf pdpta01 pdf 2001 U Information Value based Information Resource Management of the Defense Information Systems Network by Devens Pitt http www argreenhouse com society TacCom papers99 08_5 pdf 1999 U Secure-RM Security and Resource Management for Dynamic Real-Time Systems bu Tjaden et al Ohio University http jarok cs ohiou edu papers scc2000 pdf 2000 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-25 UNCLASSIFIED FOR OFFICIAL USE ONLY 9096 9097 9098 9099 9100 9101 9102 9103 9104 9105 9106 9107 9108 9109 9110 9111 9112 9113 9114 9115 9116 9117 9118 9119 9120 9121 2 5 3 3 U FOUO Integrity of Network Fault Monitoring Recovery and Integrity of Network Management Control 2 5 3 3 1 U Technical Detail U FOUO One of the most important IA aspects of the future GIG will be that of securely managing and controlling--both locally and remotely--the various and many network elements On top of this should portions of the GIG infrastructure become impaired due to an external attack component failure or malfunction there would be a need for robust and distributed network fault monitoring and recovery Since all of these functions rely upon a well-defined set of common sensing incoming and command outgoing message constructs a standardized protocol such as the IETF Simple Network Management Protocol SNMP would provide the required capabilities SNMP is a default standard methodology for network management and has survived numerous competing standard entrants U FOUO What is really required for successful network management control and monitoring is an entire framework built around three foundation components a data definition language as defined by an Internet-standard Structure of Management Information SMI a set of definitions of management information as delineated by an Internet-standard Management Information Base MIB and a common protocol definition SNMP The MIB database resides generally at the managed client agent and its variables define the scope range and limitations of control features which may be executed The SNMP protocol is used to convey information and commands between network managers and managed objects or agents U FOUO There are four basic operations or commands that may be executed within the SNMP protocol These are Get GetNext Set and Trap The first three commands are initiated by the manager and they act upon MIB variables at the client agent of interest The Trap message is initiated by a client agent when an error or fault occurs and it is used in order to notify the central manager that something unexpected has gone wrong The basic elements of SNMP operation are shown in Figure 2 5-7 This figure is U 9122 9123 Figure 2 5-7 U Basic Elements of SNMP Operation UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-26 UNCLASSIFIED FOR OFFICIAL USE ONLY 9124 9125 9126 9127 9128 9129 9130 U FOUO Note the security-relevant components of the Security Subsystem and Access Control Subsystem in the above figure It is these component elements that have evolved considerably during the evolution of SNMP through its SNMPv1 SNMPv2 and SNMPv3 versions U FOUO The first two versions of SNMP had no real security functionality Security was primarily introduced in the SNMPv3 implementation Both authentication and privacy capabilities were introduced by SNMPv3 as shown in Figure 2 5-8 This figure is U 9131 9132 9133 9134 9135 9136 9137 9138 9139 9140 Figure 2 5-8 U SNMPv3 Security Capabilities U FOUO The User Security Model USM describes operations of the security functions within SNMPv3 In the basic model cryptographic keys are assumed to be symmetric or private keys Authentication is accomplished by using Hashed Message Authentication Code-Message Digest Algorithm 5 HMAC-MD5 or alternatively HMAC- Secure Hash Algorithm 1 SHA-1 Encryption or message privacy is accomplished using the Digital Encryption Standard DES in the Cipher Block Chaining CBC mode The SNMPv3 message format as implemented with USM along with the application scopes of authentication and encryption is shown in Figure 2 5-9 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-27 UNCLASSIFIED FOR OFFICIAL USE ONLY This figure is U 9141 9142 9143 9144 9145 9146 9147 9148 9149 9150 9151 9152 9153 Figure 2 5-9 U SNMPv3 Message Format Security Components U FOUO The MD5 message digest algorithm or optional SHA1 indirectly provides for data origin authentication and it directly defends against data modification attacks U FOUO One of the important security features of SNMPv3 is the View-based Access Control Model VACM that it employs VACM determines whether access to a managed object or agent should be allowed To do this VACM makes use of an MIB that defines the access control policy for the subject agent--thus enabling remote configuration capabilities VACM is flexible in that its logic provides for access to be decided by a series of relevant questions concerning the access request Who Where How Why What Which Based on the answers to these questions in conjunction with the contents of policy-based access tables access is either allowed or disallowed Figure 2 5-10 shows the access control logic employed by VACM UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-28 UNCLASSIFIED FOR OFFICIAL USE ONLY This figure is U 9154 9155 9156 9157 9158 9159 9160 9161 9162 9163 9164 9165 9166 9167 9168 9169 9170 9171 9172 9173 9174 9175 Figure 2 5-10 U SNMPv3 View-based Access Control Model VACM Logic U FOUO The addition of the VACM capability within SNMPv3 should enable future GIG applications to conduct policy-based and fully access-controlled remote and distributed network management and monitoring functions As such it is a powerful construct 2 5 3 3 2 U Usage Considerations U FOUO Some components of the future GIG have already proposed using SNMPv3 in order to enable the IA of management control and monitoring functions For example the TSAT program proposes the use of SNMPv3 for network monitoring as mentioned on slide 23 of the briefing TCM IA Architecture Overview 30 June2004 by NSA's IAD TSAT IA Integrated Program Team IPT Network management and control of the TSAT network will be required to be at the MAC I level Mission Assurance Category the highest of the three defined MAC levels for a system requiring high integrity and high availability Similarly TSAT network management and control will require a confidentiality level of Sensitive or the medium of 3 possible confidentiality levels The SNMPv3 protocol is deemed adequate in satisfying network monitoring requirements U FOUO Many experts for example computer science professor Dr Richard Stanley of Worcester Polytechnic University have said that SNMPv3 is the clear long-term choice for secure network management Unfortunately SNMPv3 is still a work-in-progress even within the IETF standardization process SNMPv1 still holds 95% of the commercial market with even the intermediate SNMPv2 not yet widely deployed Upgrading to SNMPv3 is difficult and costly However it promises to provide for many GIG network management security requirements UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-29 UNCLASSIFIED FOR OFFICIAL USE ONLY 9176 9177 9178 9179 9180 9181 9182 9183 9184 9185 9186 9187 9188 9189 9190 9191 9192 9193 9194 9195 9196 9197 9198 9199 9200 9201 9202 9203 9204 9205 9206 9207 9208 9209 9210 9211 9212 9213 9214 9215 U FOUO There are actually disadvantages of SNMPv2 versus SNMPv1 in that version 2 makes matters potentially worse from a security viewpoint This is due to the fact that while both versions do not have security written into them SNMPv2 introduces the concept of distributed management which opens the management process to additional potential vulnerabilities GIG implementations should only consider SNMPv3-compliant or equivalent systems 2 5 3 3 2 1 U Implementation Issues U FOUO The addition of the security functions and their associated mechanisms to the SNMPv3 standard version has resulted in the fact that SNMPv3 is more compute-intensive than the earlier versions This has led some in the research community to compare the efficiency of full SNMPv3 implementations with SNMPv2 running over Transport Layer Security TLS TCP secure connections or alternatively over IPsec These two options effectively separate out encryption protection from within the SNMP standard itself and bring it to a wrapping transport function This only addresses the encryption privacy aspects of SNMPv3 and does not implement any of the VACM access control functionality which SNMPv3 provides us U FOUO The Office of Naval Research ONR funded Midkiff and Hia of Virginia Tech in 2001 to look at the IPsec security option to SNMPv3 encryption across backbone networks They showed that SNMPv3 could consume as much as 24% more network capacity than SNMPv2 over IPsec The disadvantage of the IPsec method is that it does not provide for fine-grained access control The advantage shown by the SNMPv2-over-IPsec solution was shown to deteriorate as the size of the application-layer payload increased Much of the inefficiency of the SNMPv3 solution is due to the Basic Encoding Rules BER used to encode SNMP application data U FOUO The NSA Laboratory for Telecommunications Science LTS funded Du and Shayman of the University of Maryland to investigate the performance comparisons of SNMPv1 over a TLS TCP base with full SNMPv3 security One issue of SNMPv1 TLS TCP is the nontrivial overhead associated with setting up a session as compared against SNMPv3 over UDP sessionless However for a long session the costs of setting up the session are amortized over a large number of messages and therefore the overhead per message decreases The final experimental results showed that SNMPv3 with full USM security functionality session times were much larger from 163% up to 433% of than the comparable SNMPv1 TLS TCP session times Thus for situations of lower data rate environments this aspect of SNMPv3 may perhaps need to be considered 2 5 3 3 2 2 U Advantages U FOUO SNMPv3 builds upon the general overall advantages of SNMP in that it solves many of the security problems of the earlier SNMPv1 and SNMPv2 versions One of the basic appeals of SNMP has been its simplicity because SNMP provides a bare-bones set of functions and thus is easy to implement install and use If applied sensibly it won't place an undue burden on the network Moreover due to its simplicity interoperability can be achieved in a relatively straightforward manner--SNMP modules from various vendors can be made to work together with minimal effort UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-30 UNCLASSIFIED FOR OFFICIAL USE ONLY 9216 9217 9218 9219 9220 9221 9222 9223 2 5 3 3 2 3 U Risks Threats Attacks U FOUO The messages which will be needed to provide for assured GIG network management control and monitoring will be subject to a variety of potential adversarial threats or attacks Hence the security constructs of an enabling protocol such as SNMPv3 must be adequate to protect against these potential malicious actions The SNMPv3 protocol's Userbased Security Model USM improved upon the earlier versions of SNMP so as to protect against the following four threats o U FOUO Modification of Information--Attempt by an unauthorized entity to alter an SNMP message in-transit issued on behalf of an authorized principal o U FOUO Masquerade--Attempt by an unauthorized entity to perform an operation by assuming the identity of an authorized entity o U FOUO Message Stream Modification--Delay or replay of messages to an extent greater than can occur in natural conditions of network service o U FOUO Disclosure--Attempt by an unauthorized entity to see the contents of SNMP message data exchanges 9224 9225 9226 9227 9228 9229 9230 9231 9232 9233 9234 9235 9236 U FOUO SNMPv2 has been shown to be vulnerable to replay attacks and resultant message stream modification due to the possibility of clock time drift between network manager and remote agent This is solved by SNMPv3--it supposedly would also be ameliorated by the adoption of a truly secure and robust Network Time Protocol NTP across the GIG Though the SNMPv3 protocol provides for protection against the above 4 threats it was decided during the development of SNMPv3 to not provide for defense against the following two threats 9237 o U FOUO Traffic Analysis TA 9238 o U FOUO Denial of Service DoS 9239 9240 9241 9242 9243 9244 9245 9246 9247 9248 9249 U FOUO At the time of SNMPv3 definition it was deemed that these two threats either required defenses that were nearly impossible to achieve or were not as significant as the others U FOUO While subject to various malicious threats or attacks--or merely to innocent network component failures--the GIG infrastructure will be subject to the potential risk that network management and control messages will be unable to reach their desired destinations This is especially true in the case of an Internet IP protocol such as SNMP that provides all its signaling in-band IB on the same IP routing infrastructure upon which normal traffic travels For example in order to conduct management and control of a particular network router the paths to that router will be necessarily operational or else the control function will not be possible This quandary has led some industry proponents to propose that perhaps backup out-of-band OOB perhaps dial-up control paths be maintained to at least the critical network elements UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-31 UNCLASSIFIED FOR OFFICIAL USE ONLY 9250 9251 9252 9253 9254 9255 9256 9257 9258 9259 9260 9261 9262 9263 9264 9265 9266 9267 9268 9269 9270 9271 9272 9273 9274 9275 9276 9277 9278 9279 9280 9281 9282 9283 9284 U FOUO While perhaps not as essential in the area of everyday network management and control these OOB techniques may become most valuable during times of network fault monitoring and recovery The possible segregation of SNMP traffic onto a physically separate management network would potentially require an entirely parallel architecture redesign e g VLANs routing BGP OSPF domains new IP addresses for configuring managers and remote agents It would also require a transition plan to ensure continued management during migration Carriers and other network service providers have used OOB for years because their businesses depend on the continuous availability of their network infrastructure The degree to which the GIG should adopt this philosophy is yet to be determined U FOUO The vulnerabilities of the original SNMPv1 protocol with virtually no provision for security functionality are such that many organizations purposely limit the use and application of SNMP The newer SNMPv3 when and if fully deployed as specified should go far to remove these concerns U FOUO Meanwhile however the vulnerabilities of deployed SNMP systems continue to be exposed An example of this is the work done in Finland during 2002 by the Oulu University Secure Programming Group OUSPG In this study more than four dozen vulnerabilities to SNMPv1 were demonstrated on commercial system implementations e g Cisco Examples of vulnerabilities include cases of seemingly innocent poor error handling when the SNMP primitive messages of Get Set or Trap were transmitted with invalid encodings or illegal internal values The results of these simple non-malicious mistakes could lead to network elements crashing locking up rebooting overwriting critical data values or even enabling unauthorized access Other uncovered vulnerabilities of SNMPv1 include the possibility of bounce attacks whereby malicious attackers could bounce their attacks off a trusted node U FOUO Risks and vulnerabilities of SNMP have been well-documented by the US Computer Emergency Readiness Team CERT and the CERT Coordination Center at Carnegie Mellon University's Software Engineering Institute CMU SEI Useful documentation available from them includes an SNMP Vulnerability FAQ frequently asked questions--at http www cert org tech_tips snmp_faq html which accompanies the illustrative CERT Advisory CA2002-03 on SNMP vulnerabilities http www cert org advisories CA-2002-03 html CERT acknowledges the foundation work of OUSPG in the uncovering of many examples of vulnerable commercial SNMP deployed implementations U FOUO Finally even with the assumption of a finalized and robustly secure SNMPv3 standard if the Request For Comments RFC are not fully and carefully implemented by the various vendors there may still be residual vulnerabilities such as those to buffer overflow exploits However this can also be true of other network management standards UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-32 UNCLASSIFIED FOR OFFICIAL USE ONLY 9285 9286 9287 9288 9289 9290 9291 9292 9293 9294 9295 9296 9297 9298 9299 9300 9301 9302 9303 2 5 3 3 3 U Maturity U FOUO SNMP has a fairly long history since its debut in the late 1980s As such it has had time to mature certainly as proved by the development of the later versions through SNMPv3 in the late 1990s This maturing process has been beneficial by solving many of the security issues left unresolved by the first version The marketplace is populated by many implementations of SNMPv1 with marketplace adoption of SNMPv2 and SNMPv3 lagging due to business inertia reasons while the standards process proceeds to improve upon SNMPv3 With the vulnerabilities of SNMPv1 having become well known pressure will mount for retrofit with SNMPv3-compliant network management systems U FOUO There are many commercial implementations of SNMP These include systems built by HP IBM Novell Sun Microsoft Compaq Empire Technologies Gordian and SimpleSoft In addition there are at least 18 commercial or academic implementations of the more advanced SNMPv3 including those by AdventNet BMC Software Cisco Halcyon IBM Multiport Corporation SimpleSoft SNMP Research UC Davis and University of Quebec Thus considering both the ongoing commercial work and the standards work within the IETF SNMPv3 should continue to evolve and improve U FOUO The various sub-technologies of the Integrity of Network Management Control Monitoring Recovery technology area can be generally assigned Technology Readiness Level groups of Early Emerging and Mature 9304 o U FOUO Basic SNMPv3 implementations--Mature 7 - 9 9305 o U FOUO Key management enhancements for SNMPv3--Early 1 - 3 9306 o U FOUO Efficient SNMPv3 with security by IPsec or SSL TLS rather than native SNMPv3 encryption --Emerging 4 - 6 9307 9308 9309 9310 9311 9312 9313 9314 2 5 3 3 4 U Standards U U S Government Protection Profile on Network Management http niap nist gov ccscheme pp index html U FOUO As far as the definition of the SNMP protocols is concerned there are a number of IETF RFCs that explain the relevant security-enabling aspects of SNMPv3 These include the following o U RFC 3414 User-based Security Model USM for version 3 of the Simple Network Management Protocol SNMPv3 o U RFC 3415 View-based Access Control Model VACM for the Simple Network Management Protocol SNMP 9315 9316 9317 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-33 UNCLASSIFIED FOR OFFICIAL USE ONLY 9318 9319 9320 9321 9322 9323 9324 9325 9326 9327 9328 9329 9330 9331 9332 9333 9334 U FOUO In addition to the IETF arena a number of different standards groups have been developing competing or alternate frameworks for network management control and monitoring These include the International Standards Organization ISO and the Open Software Foundation OSF However these alternate approaches have for various reasons not yet been successful in the commercial marketplace As such reviewing these will be delayed until the upcoming Alternatives section 2 5 3 3 5 U Cost Limitations U FOUO There are several limitations currently to the broad implementation of SNMPv3 One of these is in the area of key management The official SNMPv3 standard generically calls for initial OOB distribution of secret keys among manager and agent elements without specifying a technique Thus there is no accepted standardized initial key distribution mechanism--only an experimental Diffie-Hellman approach There is also no integration with centralized key management and authorization such as RADIUS One approach exists for Kerberos but that has been labeled experimental and Kerberos does not seem to be in wide commercial use Finally there has been only some initial work to standardize the widely desired Advanced Encryption Standard AES support as described in a 2002 IETF draft http www snmp com eso draft-blumenthal-aes-usm-04 txt 9340 U FOUO On a more positive note however very recent work during 2003-2004 has been undertaken on the SBSM Session-Based Security Model for SNMPv3 This would employ public key based I A between manager and agent elements using the SIGMA key exchange protocol using Diffie-Hellman SIGMA has several advantages including its simplicity and efficiency that it has had extensive review and is used for IKE Internet Key Exchange and it protects the identity of the session initiator 9341 U FOUO The SBSM protocol itself has a number of advantageous characteristics and features 9335 9336 9337 9338 9339 9342 o U FOUO It uses existing security infrastructures for identity authentication 9343 o U FOUO Both ends of message exchanges are authenticated 9344 o U FOUO The responder agent reveals its identity and authenticates before the initiator manager o U FOUO Separate mechanisms are used for identity authentication as compared with message authentication or encryption o U FOUO It has limited life time keys for encryption 9345 9346 9347 9348 9349 9350 9351 9352 9353 U FOUO The consequences of these features are that there is a low cost to creating new identities changing or deleting their authentication credentials Also saved encrypted messages can not be decrypted after an identity key is compromised However SBSM is a work in progress and overall SNMPv3 key management will require some maturation and standards adoption UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-34 UNCLASSIFIED FOR OFFICIAL USE ONLY 9354 9355 9356 9357 9358 9359 9360 9361 9362 9363 9364 9365 9366 9367 2 5 3 3 6 U Dependencies U FOUO The future success of SNMP-based network management systems will depend upon their full adoption of SNMPv3 security functionality and the full marketplace adoption of SNMPv3 implementations in lieu of SNMPv1 systems Finally use of SNMP within the GIG will depend upon the demonstrated robust and correct implementations by vendors of SNMPv3 so as to minimize any residual vulnerabilities 2 5 3 3 7 U Alternatives U FOUO Since SNMPv1 was originally proposed in the late 1980s several competing standards alternatives have been proposed Nonetheless for a variety of reasons SNMP continues to evolve and improve whereas the competitors have often come and gone SNMPbased network management and its associated security mechanisms continue to grow expand its scope and mature Four examples of competing alternative architecture schemes are described below o U Common Management Information Protocol CMIP comes out of the ISO The main problem with this protocol is that it is overly complex and perhaps overly ambitious Due to this complexity it can require up to 10 times the CPU power of an SNMP implementation Few commercial implementations of CMIP can be found CMIP originally was supposed to be the protocol that replaced SNMP in the late 1980s It was funded by governments and large corporations which caused many to believe that it would inevitably succeed However implementation problems delayed its widespread availability CMIP had security advantages over SNMPv1 in that it included authentication and security log mechanisms However SNMPv3 solves the security holes of SNMP Because of the fact that SNMP came out first and was much simpler to implement CMIP is used today primarily in management of public telephone networks while SNMP dominates most of the network management field o U Distributed Management Environment DME comes from the Open Software Foundation OSF originating during the 1991 timeframe from proposals submitted by 25 organizations including IBM HP Tivoli Systems etc It is a framework meant for tackling the problem of managing distributed network devices Unfortunately it is not much used commercially DME is an object-oriented environment like CMIP The main problem with DME is that it seems to over-generalize the framework This causes a problem for the business interests of competing vendors if SunNet Manager HP OpenView and IBM Netview all have the same GUI protocols etc these platforms may lose bargaining position based on unique capabilities o U Hierarchical Network Management System HNMS comes out of the Network Attached Storage NAS domain Its goal is to provide the capability to manage and monitor a very large Internet Protocol network It relies on four types of modules a server a database IO input output modules and UI user interface modules All intermodule communication is done by the Hierarchical Network Management Protocol HNMP HNMP like SNMP is built on top of UDP IP Finally four types of services are provided by HNMS system parameters setting data exchange device discovery and object management In general HNMS is more complex than SNMP and thus not as 9368 9369 9370 9371 9372 9373 9374 9375 9376 9377 9378 9379 9380 9381 9382 9383 9384 9385 9386 9387 9388 9389 9390 9391 9392 9393 9394 9395 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-35 UNCLASSIFIED FOR OFFICIAL USE ONLY successful in the marketplace 9396 9397 9398 9399 9400 9401 9402 9403 9404 9405 9406 o U Hypermedia Management Architecture HMMA comes out of the Web-Based Enterprise Management WBEM initiative of the Distributed Management Task Force DMTF whose URL can be found at http www dmtf org standards wbem It is a result of a movement to combine network management with system and desktop management WBEM is supported by Microsoft Compaq Cisco Intel HP etc The idea is to integrate existing standards into a framework combining Desktop Management Interface DMI RPC for desktops servers with SNMP for network management and doing all related Internet communication through Hypertext Transfer Protocol HTML HTTP This aggregated architecture can then be managed using any Web browser which is an advantage over plain SNMP 9407 9408 9409 9410 9411 9412 9413 9414 9415 9416 9417 9418 9419 9420 9421 9422 9423 9424 9425 9426 9427 9428 9429 9430 U However HMMA can be viewed not as a SNMP competitor but rather as the longawaited HTTP version of SNMP The HMMP Protocol has been submitted to the IETF forum and the HMMS Schema has been submitted to the DMTF forum Of all the competitors to SNMP HMMA perhaps has some chance of succeeding U FOUO If a choice has been made to employ SNMP-based network management techniques then an alternative to full SNMPv3 implementation would be to use non-native encryption outside of the SNMPv3 specified techniques such as IPsec or TCP TLS Transport Layer Security This alternative encryption choice may prove to be more efficient in terms of computation burden as compared with full SNMPv3 operation Finally as in the prior evaluations concerning out-of-band versus in-band network management the ultimate alternative to in-band SNMPv3 would be to build a dedicated physical or dial-up backup network for network management purposes And when it comes to the issue of fault management consideration of HTTP over SSL has the problem of connection-orientation which would rule it out as compared with SNMPv3 2 5 3 3 8 U Complementary Techniques U FOUO As has already been shown a complementary or alternative technique to the full implementation of SNMPv3 would be to implement SNMPv1 over IPsec or over TLS TCP due to the fact that SNMPv3 messages can require greater network capacity mainly an issue only on lower data rate networks 2 5 3 3 9 U References U RFC 3414 User-based Security Model USM for version 3 of the Simple Network Management Protocol SNMPv3 http www ietf org rfc rfc3414 txt or http www faqs org rfcs rfc3414 html by Wijnen et al December 2002 9433 U RFC 3415 View-based Access Control Model VACM for the Simple Network Management Protocol SNMP http www ietf org rfc rfc3415 txt or http www faqs org rfcs rfc3415 html by Wijnen et al December 2002 9434 U TCM IA Architecture Overview briefing 30 June 2004 by NSA's IAD TSAT IA IPT 9431 9432 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-36 UNCLASSIFIED FOR OFFICIAL USE ONLY 9435 U Understanding the SNMP Security Vulnerability 9436 http www ins com downloads seminars SNMP_Vulnerabilities_13mar02 ppt by Nicastro et al March 2002 9437 9438 U Understanding the Risks of SNMP Vulnerabilities http www lucent com livelink 255868_Whitepaper pdf by Davis et al 2002 9439 U SNMP's Real Vulnerability 9440 http www networkmagazine com shared printableArticle jhtml jsessionid OHQF54CDNR3ISQSNDBCSKHQ art icleID 8703341 May 2002 9441 9443 U Researchers Reveal Major SNMP Holes http www nwfusion com news 2002 0218snmp html February 2002 9444 U Security in Network Management 9445 http opensores thebunker net pub mirrors blackhat presentations bh-usa-97 Jeremy-snmp ppt 9446 U PROTOS Test-Suite c06-snmpv1 http www ee oulu fi research ouspg protos testing c06 snmpv1 October 2002 9442 9447 9448 9449 9450 9451 9452 9453 9454 9455 9456 9457 9458 9459 9460 9461 9462 9463 9464 U Security Comes to SNMP The New SNMPv3 Proposed Internet Standards http www cisco com warp public 759 ipj_1-3 ipj_1-3_snmpv3 html by William Stallings The Internet Protocol Journal December 1998 U CERT Advisory CA-2002-03 Multiple Vulnerabilities in Many Implementations of the Simple Network Management Protocol SNMP http www cert org advisories CA-2002-03 html February 2002 U EE579T Network Security 11 Firewalls and SNMP Spring 2004 lecture by Dr Richard Stanley of WPI Worcester Polytechnic Institute http ece wpi edu courses ee579t EE579TClass%2011C ppt U The AES Cipher Algorithm in the SNMP's User-based Security Model IETF Internet Draft by Blumenthal et al http www snmp com eso draft-blumenthal-aes-usm-04 txt October 2002 U Implementation and Performance Analysis of SNMP on a TLS TCP Base by Du et al http www umiacs umd edu docs Du ppt U Securing SNMP Across Backbone Networks by Hia et al http fiddle visc vt edu courses ece5566 lectures 21securesnmp pdf 2001 U Deploying Secure SNMP in Low Data Rate Networks by Hia et al http www irean vt edu navciiti reports secure_snmp_nov_2000 pdf 9466 U Session-based Security Model for SNMPv3 SNMPv3 SBSM http netsnmp sourceforge net sbsm SBSM ppt 9467 U http www nanog org mtg-0405 pdf hardaker pdf 9465 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-37 UNCLASSIFIED FOR OFFICIAL USE ONLY 9468 U http www net-snmp org sbsm SBSM-bof-wes ppt 9469 U http www net-snmp org sbsm 9470 U IETF drafts during 2004 9471 U http www net-snmp org sbsm draft-perkins-snmpv3-overview-00 txt 9472 U http www net-snmp org sbsm draft-hardaker-snmp-session-sm-01 txt 9473 9474 9475 9476 9477 9478 9479 9480 U SNMP Architecture Alternatives U http www2 rad com networks 1999 snmp index htm U SNMP Vulnerabilities Frequently Asked Questions FAQ U http www cert org tech_tips snmp_faq html 2 5 4 U Assured Resource Allocation Gap Analysis U Gap analysis for the Assured Resource Allocation Enabler indicates that the main areas of future development are as follows o U FOUO Need to develop SAR Security Aware ad-hoc Routing protocol capability that will work in tactical wireless GIG contexts o U FOUO More generally need to verify that flexible and security-cognizant routing protocols such as FIRE Flexible Intra-AS Routing Environment can be implemented across the GIG and that the needed security QoS parameters and associated routing table information can be passed to GIG routers across any intervening red black boundaries o U FOUO Need to develop a GIG Quality of Protection standard that will be a foundational element of the IA Policy-based Routing capability o U FOUO Need to develop a robust MLPP precedence and preemption standard for the GIG that will be well-integrated with the required foundation of a GIG PMI Privilege Management Infrastructure Operational-based resource allocation deallocation actions will demand that the associated privileges be consistently valid and universally distributed to needed policy enforcement points o U FOUO Need to flesh out the capabilities of SNMPv3 if this protocol is decided as the way to go for network signaling security as this document suggests SNMPv3 is fairly mature except for key management aspects Also need to validate that SNMPv3 will be efficient enough when widely applied throughout the GIG o U FOUO Need to develop a Protection Profile for Network Management 9481 9482 9483 9484 9485 9486 9487 9488 9489 9490 9491 9492 9493 9494 9495 9496 9497 9498 9499 9500 U FOUO Technology adequacy is a means of evaluating the technologies as they currently stand This data can be used as a gap assessment between a technology's current maturity and the maturity needed for successful inclusion in the GIG UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-38 UNCLASSIFIED FOR OFFICIAL USE ONLY 9502 U FOUO Table 2 5-1 lists the adequacy of the Assured Resource Allocation technologies with respect to the IA attributes discussed in the RCD 9503 Table 2 5-1 U Technology Adequacy for Assured Resource Allocation 9501 This Table is U Technology Category IA Policybased Routing Operation al-based Resource Allocation Integrity of Network Managemen t Control Monitoring Recovery IAAV1-IAAV4 IACNF6 IANMA2 IANMP1-IANMP5 IAAV21 IARC01 - IARC12 IAMP02 IACNF6 IACNF12 IANMA3 IANMP4 IANMP5 IARC01 - IARC12 IAAV1-IAAV4 IAAV15 IAFM1 IANMA2 Standard Enabler Attribute Secure Solution Scalable Solution Protection Profile Required Capability attribute from RCD N A N A High Assurance IACNF6 IAFM1 IANMP1-IANMP5 IAAV20 Distributed Global Reach IAAV1-IAAV4 IAAV15 IAFM1 IAFM3 IAFM4 IANMA3 IANMP1IANMP5 IAAV15 Verifiable Solution This Table is U 9504 9505 9506 9507 9508 9509 9510 9511 9512 U FOUO In summary the SNMPv3 standard is fairly mature accounting for the black cell in the matrix At the current time there is only provision for a Protection Profile dedicated to Network Management It is noted that there is a Protection Profile for Switches and Routers in general see http niap nist gov cc-scheme pp index html It is generally viewed that technology for operational-based resource allocation is less mature and therefore less adequate for the GIG than the available IA-based routing and network management technologies Various sub-technologies are available for the latter two areas but need to be integrated together and operationally validated UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-39 UNCLASSIFIED FOR OFFICIAL USE ONLY 9513 9514 9515 9516 2 5 5 U Assured Resource Allocation Recommendations and Technology Timelines U The following is a list of recommendations for advancing the technologies required for the successful implementation of this GIG enabler o U FOUO Encourage the further development of adaptive security-driven i e IA policy-based wireless routing algorithms such as SAR for inclusion in JTRS and WIN-T o U FOUO Advance the standards evolution and demonstration implementation of extensible routing protocols such as OSPF and IS-IS so that IA metrics can be fully employed in routing decisions o U FOUO Encourage the development of a GIG Precedence and Preemption standard that is closely tied with the required corollary GIG Privilege Management Infrastructure The overall GIG Precedence Preemption standard should ideally include the new GIGBE-based VoIP-evolved DISN MLPP protocol as a subset capability o U FOUO Advance as an inclusion to the GIG Precedence and Preemption standard the capability for rational post-preemption rescheduling so as to not leave GIG customers without requested services o U FOUO Support developments that will ensure that an operational-based resource allocation infrastructure will have GIG-wide i e worldwide reach in its customer adjudication process especially in the case of multiple requests and possible GIG congestion o U FOUO Push for the development of effective and scalable key management mechanisms for SNMPv3 messaging o U FOUO Continue to follow the efficiency issue impact of SNMPv3 native encryption as being about 20% slower than SNMPv2 over IPsec or SSL o U FOUO Continue to track potential competing technologies standards to SNMPv3 for network management control monitoring even though various competitors have come and gone 9517 9518 9519 9520 9521 9522 9523 9524 9525 9526 9527 9528 9529 9530 9531 9532 9533 9534 9535 9536 9537 9538 9539 9540 9541 9542 9543 9544 9545 9546 U FOUO Figure 2 5-11 contains preliminary technology timelines for this IA System Enabler These are the result of research completed to date on these technologies As the Reference Capability Document and the research of technologies related to these capabilities continues these timelines are expected to evolve The timelines reflect when the technologies could be available--given an optimum set of conditions e g commercial community evolution starts immediately GOTS funding is obtained staffing is available Technology topics with missing timelines if any indicate areas where further work is needed to identify the milestones UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-40 UNCLASSIFIED FOR OFFICIAL USE ONLY Technology 2004 Standard for Quality of Protection 2006 2008 2010 2012 2014 2016 2018 2020 Standard approved Authentication for QoS CoS IA policy-based routing implemented Exchange of routing across tunnels Red Red routing exchange IA Policy-based Routing Standard for Precedence Preemption Standard approved Operational-based resource allocation implemented Operational-based Resource Allocation Integrity of Network Fault Monitoring and Recovery Integrity of Management Control Dynamic network assessment Network fault monitoring recovery implemented Integrity of management control implemented Lifecycle Protection of Management Control This Figure is U FOUO 9547 9548 Figure 2 5-11 U Technology Timeline for Assured Resource Allocation 9549 9550 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 5-41 UNCLASSIFIED FOR OFFICIAL USE ONLY 9551 9552 9553 9554 9555 9556 9557 9558 9559 9560 9561 9562 9563 9564 9565 2 6 U NETWORK DEFENSE AND SITUATIONAL AWARENESS U FOUO Network Defense and Situational Awareness is the IA System Enabler that allows the GIG to achieve the IA Mission Concept of Defend the GIG It consists of enterprise-wide protection monitoring detection and analysis that provide input into situational awareness of the operational mission s being carried out and result in response actions The collection and analysis of sensor information--coupled with intelligence data operational priorities and other inputs--enables the creation of user-defined operational pictures of the assurance of GIG resources The analysis of this information supports the development of situational awareness and the identification and characterization of potentially hostile activity U FOUO Situational awareness enables an adaptive and rapid adjustment of enterprise resources in response to unauthorized network activity and sub-optimal GIG resource configurations to support and achieve the six GIG IA Mission Concepts U FOUO This IA System Enabler consists of the following major functions as defined in the Joint Concept of Operations for Global Information Grid NetOps 20 April 2004 o U FOUO Protection Prior actions taken to counter vulnerabilities in GIG information transport processing storage service providers and operational uses Protection activities include emission security EMSEC communications security COMSEC computer security COMPUSEC and information security INFOSEC --all incorporating access control cryptography network guards and firewall systems o U FOUO Monitor The monitoring of information systems to sense and assess abnormalities the use of anomaly and intrusion detection systems Monitoring also includes receiving input from network monitoring as well as from a wide variety of realtime and status reporting o U FOUO Detection Timely detection identification and location of abnormalities--to include attack damage or unauthorized modification--is key to initiating system response and restoration actions Detection also includes actions taken in anticipation of an attack i e configuration adjustment o U FOUO Analyze Assessing pertinent information to achieve situational awareness evaluate system status identifying root cause defining courses of action prioritizing response and recovery actions and conducting necessary reconfiguration of GIG assets as needed o U FOUO Response Directed actions taken to mitigate the operational impact of an attack damage or other incapacitation of an information system Response also includes restoration--the prioritized return of essential information systems elements of systems or services to pre-event capability Coupled with restoration is the ability to undo a response 9566 9567 9568 9569 9570 9571 9572 9573 9574 9575 9576 9577 9578 9579 9580 9581 9582 9583 9584 9585 9586 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-1 UNCLASSIFIED FOR OFFICIAL USE ONLY 9587 9588 9589 9590 2 6 1 U GIG Benefits due to Network Defense and Situational Awareness U FOUO The Network Defense and Situational Awareness System Enabler provides the following benefits to the GIG o U FOUO Dynamic protection of GIG network and computing resources from attack attack being defined here as a sequence of one or more exploits or other actions taken by an adversary that lead to success of the adversary's mission updated defensive posture based on near-real-time detection intelligence and operational and network information to enable a rapid response o U FOUO Continuous assured e g availability confidentiality integrity discovery collection processing correlation storage and dissemination of intrusion detection and audit data IA services applied to the sensor and audit resources ensure the availability integrity and confidentiality of the information received and also enable the authentication of the source o U FOUO Detection and sharing of events and anomalies at multiple tiers i e local regional global within the GIG User-defined operational pictures UDOP of the situational awareness information will enable analysis at all tiers and response to events as they occur o U FOUO Trusted real-time user-defined operational picture of the IA security posture of the GIG at any tier Building upon the assured discovery collection processing analysis storage and dissemination of intrusion detection information and audit and network management data authorized users will be able to customize their view into the GIG as required to meet operational needs and also continuously monitor GIG network activity o U FOUO Rapid analysis and response alternatives developed and modeled Collection of sensor information audit data and network management data is only one step in the process Being able to rapidly analyze that information requires greatly enhanced correlation analysis and modeling tools over what is currently available today in order to determine if an attack is occurring or imminent and what the impact of such an attack might be if not countered o U FOUO Enterprise-wide tools will enable the capability to rapidly monitor analyze and respond to system computing and network attacks degradations outages misuse of resources and events such as changes in operational priorities o U FOUO Automatic and global intelligent self-learning defensive action enforcement to contain recover restore and undo and reconstitute the GIG Having determined an attack is underway--or imminent--and with likely resulting damage alternative defensive countermeasures can be postulated and modeled evaluated before implementation throughout the GIG 9591 9592 9593 9594 9595 9596 9597 9598 9599 9600 9601 9602 9603 9604 9605 9606 9607 9608 9609 9610 9611 9612 9613 9614 9615 9616 9617 9618 9619 9620 9621 9622 9623 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-2 UNCLASSIFIED FOR OFFICIAL USE ONLY 9624 o U FOUO Governance of response actions There are potential legal ramifications to employing defensive countermeasures to an attack The analysis and modeling that will be available will strengthen the legal position that all due diligence was taken to analyze alternatives before deploying any response o U FOUO Automatic prediction of attack strategies objectives and targets based on intrusion detection data network data and attack patterns Automated tools performing trend analysis of sensor data and log files will provide the GIG with the capability to predict when and where identified attacks may appear elsewhere on the network 9625 9626 9627 9628 9629 9630 9631 9632 9633 9634 9635 9636 9637 9638 9639 9640 9641 9642 9643 9644 9645 9646 9647 9648 9649 9650 9651 9652 9653 9654 9655 9656 9657 9658 2 6 2 U Network Defense and Situational Awareness Description U FOUO Network Defense and Situational Awareness is a critical enabler to provide the protection and support needed to achieve the GIG Mission Concept of Defend the GIG This enabler defines actions taken to protect against monitor detect analyze and respond to potential and actual unauthorized network activities as well as unintentional non-malicious user error that could potentially harm the GIG A concerted effort is required to find solutions to current technology issues related to an accurate view of organic system strengths and weaknesses for an enterprise of information on the scale of DoD's to be secure available and responsive to operational requirements U FOUO As a measure of effectiveness DoD-wide system administration is highly dependent upon an accurate real-time understanding of the configuration and situational awareness of DoD networks Adversaries may periodically identify a weakness in a system exploit that weakness and then return the system to its original state In addition multiple attacks and exploitations can occur simultaneously and affect multiple missions The planning of appropriate Courses of Action COAs will require constant awareness of the system and network configuration state which can lead to an overwhelming amount of data that needs to be analyzed As a result the task for administrators and analysts to understand how disparate attacks on a network affect an ongoing mission s and subsequently determine effective countermeasures becomes even more difficult U FOUO Distributed sharing of information is an important capability and begins with the monitoring and collecting of sensor information across the GIG Referring to Figure 2 6-1 it can be seen that sensor information will be gathered from various locations and at all levels to include local Tier 1 regional Tier 2 and global Tier 3 tiers Information will be shared across all tiers to include both peer-to-peer but also vertically within the organization Further while there might be a loss of information as it traverses horizontally and vertically it is critical to have the ability for higher functions in the vertical space to be able to drill-down into specifics of a lower tier's data UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-3 UNCLASSIFIED FOR OFFICIAL USE ONLY GIG Tier 1 boundary Enclave Tier 3 physical boundary Tier 2 network boundary Enclave Tier 3 network boundary CERT Tier 3 Public Internet Tier 3 LE CI DHS Tier 2 NMCC Tier 2 sensor Tier 1 alarm Threat alert advisory response Allies Coalition Partners sensor-monitor link This figure is U 9659 9660 Figure 2 6-1 U Representative Sensor Configuration 9661 U FOUO Today sensors are primarily distinct special purpose devices e g Intrusion Detection Systems IDSs Intrusion Prevention Systems IPSs Firewalls Guards --providing the information that is monitored and analyzed In the future every node and CND device on the network will provide sensor information from its unique perspective and that will be coupled with intelligence information mission priorities and audit logs to create a much broader view of the operational picture Sensors can be grouped in zones that are defined by geography function and security Zone node sensors that can operate on the concept of reporting status changes to their nearest neighbor will also be integrated into the GIG 9662 9663 9664 9665 9666 9667 9668 9669 9670 9671 9672 9673 9674 9675 9676 9677 9678 9679 9680 9681 U FOUO A major goal of the GIG is to provide a Black Core for the data sent across it to transit The term Black in this sense means that the data traversing the GIG is encrypted and if necessary also integrity-protected Performance situational monitoring and analysis of mixed mode Black Core will require a change to sensor strategy Sensors that require access to encrypted information will need to be located before encryption This introduces a host of new challenges including management and control of distributed sensors and sensor collection and processing across multiple classification boundaries U FOUO While this notion of a Black Core provides significant confidentiality and data integrity protection it can also limit the ability of the GIG core itself to detect attacks First if all data packets are encrypted at the IP level e g by HAIPEs or commercial IPsec implementations the GIG cannot detect the contents of the packets and thus cannot detect viruses worms or other malicious logic As a result the source of an attack may be hidden Information from the red IP header will need to be made available to the black IP header UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-4 UNCLASSIFIED FOR OFFICIAL USE ONLY 9682 9683 9684 9685 9686 9687 9688 9689 9690 9691 9692 9693 9694 9695 9696 9697 9698 9699 9700 9701 U FOUO Similarly if the IP traffic is being tunneled that is there is a black IP header wrapped around the actual traffic the GIG core may not even be able to tell where data packets are originating At best the GIG core can only tell that there is an unusual amount of traffic e g either much larger amounts of traffic than is normal or a usually-busy link goes quiescent The GIG cannot directly tell that an attack is under way nor can it launch a response to that attack In this case the only place where attacks can be detected and the only place from which a response can be effected is the application-layer code at the end system U FOUO Based on the size and complexity of the GIG CND capabilities will need to be available for high volume high speed connections to a variety of services i e provider services coalition services and cross-domain services Monitoring and collection of sensor information from coalition users and devices connected to the GIG is a serious concern U FOUO A non-DoD entity interface specification is needed to identify what minimum sensor information is required and how it is to be provided This specification must also address how defensive actions will be promulgated to coalition partners Correlating sensor information received from various networks will introduce additional challenges U FOUO Detection of anomalous behavior detection of attack quality of service deviations from expected communication patterns and all sorts of detailed monitoring provide the capability to ensure the integrity of individual GIG services and the enterprise-wide assurance of all managed information systems Referring to Figure 2 6-2 it can be seen that if anomalous or attack activity is detected then the appropriate response will be performed at each tier This figure is U 9702 9703 Figure 2 6-2 U Representative Flow of Situational Awareness Data UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-5 UNCLASSIFIED FOR OFFICIAL USE ONLY 9704 9705 9706 9707 9708 9709 9710 9711 9712 9713 9714 9715 9716 9717 9718 9719 9720 9721 9722 9723 9724 9725 U FOUO In addition information is passed to the next higher tier for activities requiring a wider view analysis and response An assumption can be made that anomalies and attacks will be detected at the lowest tiers While this may be true today more sophisticated attacks and anomalies can only be detected if a wider view is obtained from the outset Consequently while real-time data passed to higher tiers consists of only that which is necessary for real-time response detailed data should also be made available periodically for off-line analysis to identify trends and to apply algorithms for low-intensity attacks intrusions and exploitation U FOUO Authorized users must be guaranteed ready access to all information contributing to situational awareness ad Authorized users also must be able to verify the integrity and source of origin of the information--and in some cases ensure the confidentiality of the information To do this many different IA capabilities must be enabled To determine that a user is authorized requires that there be mechanisms to provide assured identities to all users and mechanisms to derive an authenticated session score to confirm that a user identity has been authenticated to some level of assurance A digital access policy will specify how access control to sensor information and any operational displays will be enforced and under what conditions exceptions to the policy will be managed Management of sensor resources will fall under Section 3 5 the Assured Resource Allocation Enabler U FOUO Managers and users of the GIG need near real-time awareness of current threats configuration status and performance of the GIG and its components A trusted UDOP is a tailored view of an operational cyberspace picture The GIG will provide relevant situational views of GIG operations at any level with aggregation and event correlation to the higher levels and from peer-to-peer Automated situational views will be enabled through 9726 o U FOUO Continuous monitoring of GIG configuration status and performance 9727 o U FOUO Posting of situational awareness information raw and processed 9728 o U FOUO Assembly of situational awareness information monitored data plus threat and operational priorities o U FOUO Storage of situational awareness information In addition to intrusion detection information situational awareness will encompass network management data intelligence findings operational missions operational mission requirements and priorities and IA service status 9729 9730 9731 9732 9733 9734 9735 U FOUO The CND component of the GIG will also provide the capability to take appropriate action on processed situational awareness data 9736 o U FOUO Automated display modifiable to suit each level of GIG management 9737 o U FOUO Enterprise-wide mapping of services applications to identify and mitigate vulnerabilities of all DoD hosts and associated services and applications o U FOUO Enterprise-wide tools to rapidly evaluate analyze and respond to system and network attacks degradations outages and events 9738 9739 9740 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-6 UNCLASSIFIED FOR OFFICIAL USE ONLY 9741 9742 9743 9744 9745 9746 9747 9748 9749 9750 9751 9752 9753 9754 9755 9756 9757 9758 9759 9760 9761 9762 9763 o U FOUO Ability to rapidly adjust the GIG configuration based on different cyber Information Operations Condition INFOCON levels to best respond to identified situations U FOUO The GIG will have the capability to immediately identify detect and respond appropriately to anomalies attacks or disruptions from external threats internal threats and natural causes Once the event has occurred the GIG will have the capability to implement mission impact analysis battle damage assessment The GIG will have the automated response capability to globally enforce intelligent self-learning defensive actions that contain recover restore and reconstitute the GIG e g automatically block DoS attacks traffic to vulnerable DoD hosts and counter attack Response actions will be coordinated across a broad range of operational elements including Enterprise Service Management for configuration management and restoration of disrupted or degraded capabilities U FOUO Cyber attack attribution will play an essential role in identifying attackers and deterring further attacks These capabilities will provide attacker attack profiles and fingerprinting trace to true country of origin as well as provide complete trace-back and geolocation attackers Forensic data will be captured and shared with Law Enforcement and Counter-Intelligence to investigate and if warranted prosecute perpetrators of unauthorized activities U FOUO As a complementary mechanism a network capability will collect and assess network data to provide warnings of compromise to CND command and control elements and information will be further disseminated to subordinate CND organizations It will provide CND analysis of network data to detect if a severe compromise calls into question the integrity of the GIG UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-7 UNCLASSIFIED FOR OFFICIAL USE ONLY 9764 9765 9766 2 6 3 U Network Defense and Situational Awareness Technologies U FOUO The following technology areas support the Network Defense and Situational Awareness IA System Enabler 9769 U Note For convenience of analysis and organization the technologies have been grouped together by the major function it is most designed to effect This is not meant to suggest that the following technologies can only support one function as many span multiple functions 9770 U Protection 9767 9768 9771 o U Protect Technologies 9772 o U Firewalls 9773 o U Filters Guards 9774 o U Anti-Virus Anti-SPAM 9775 o U Disk and File Encryption 9776 o U Deception Technologies 9777 o U Honeypot 9778 o U Honeynet 9779 9780 U Monitor o U Situational Awareness 9781 o U User-Defined Operational Picture UDOP 9782 o U Network Operations NETOPS 9783 o o 9784 9785 9786 U Network Mapping U Vulnerability Scanning U Detection o U Intrusion Detection Systems IDS 9787 o U Host-Based IDS Network-Based IDS 9788 o U Misuse Detection Anomaly Detection 9789 o o 9790 9791 U Intrusion Prevention Systems IPS o U Host-Based IPS Network-Based IPS U User Activity Profiling UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-8 UNCLASSIFIED FOR OFFICIAL USE ONLY 9792 9793 U Analyze o o 9794 9795 9796 9797 o U Traceback U Correlation Technologies U Response o U CND Response Actions o 9798 9799 U Cyber Attack Attribution o U Courses of Action COAs U Automated IA Vulnerability Alert IAVA Patch Management 9800 2 6 3 1 U Protect Technologies 9801 2 6 3 1 1 U Technical Detail U The ability to protect GIG network assets from computer network attack is a key cornerstone of computer network defense CND capabilities A robust CND architecture includes both defense-in-depth and defense-in-breadth 9802 9803 9804 9805 o U Defense-in-depth - multiple layers of protection through the network against a particular attack type o U Defense-in-breadth - protection against various attack types through and across the network 9806 9807 9808 9809 9810 9811 9812 9813 9814 9815 9816 U Protection capabilities tend to be the first line of defense against network attacks as well as the propagation of potentially harmful non-malicious user activity Less sophisticated adversaries can often be deterred by the sheer existence of protect technologies in today's network architectures The most straightforward example of this is the placement of stateful firewalls at network perimeters that serve to deflect automated scanning and probing activity U Current protect technologies are for the most part limited to static defenses against known attack types They include but are not limited to the following technology areas o U Network-Based Firewalls - The most common current implementation of protect technologies is network firewalls situated at perimeter boundaries to restrict data communications to and from one of the connected networks RFC 2828 These firewalls often provide the division between intranets and the Internet and come in both stateful and non-stateful varieties o U Host-Based Firewalls - Includes software application firewalls such as those that come pre-packaged with operating systems as well as independent commercial software firewalls and hardware-based firewalls resident on the network interface card Current hardware-based firewalls are highly resistant to attacks that successfully gain user access to a host 9817 9818 9819 9820 9821 9822 9823 9824 9825 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-9 UNCLASSIFIED FOR OFFICIAL USE ONLY 9826 o U Network Filtering Devices - A means of restricting data communications between connected networks--often implemented on network routers These filtering devices can act as primitive non-stateful firewall devices o U Application Filters - A means of restricting data communications at the application layer e g wrappers o U Virus Protection - Software designed to search hard drives and disks for known viruses and then quarantine any found o U Disk and File Encryption - Software designed to encrypt portions of a disk to protect data while not in use o U Guards - Guards are generally used to prevent unauthorized data transfer between security domains Hence guard technology is discussed in Section 2 3 9827 9828 9829 9830 9831 9832 9833 9834 9835 9836 9837 2 6 3 1 2 U Usage Considerations 9838 2 6 3 1 2 1 U Implementation Issues U FOUO Many protection mechanisms are currently implemented and managed on a deviceby-device or application-by-application basis This presents significant challenges in a distributed advanced system such as the GIG where implementation and management is designed with a tiered approach for all levels For a network of this scale it will be necessary to deploy technologies with advanced centralized management capabilities 9839 9840 9841 9842 9843 9844 9845 9846 9847 9848 9849 9850 9851 9852 9853 9854 9855 9856 9857 U FOUO The current trend in patch management also presents significant issues within the GIG Many commercial operating systems and applications including virus protection software rely heavily on regular updates and patches to maintain up-to-date protection capabilities This approach is rudimentary at best since it requires secure web portals accurate and trusted update code without inadvertent consequences and valuable bandwidth 2 6 3 1 2 2 U Advantages U There is a clear advantage to preventing malicious activity before it reaches its intended target Preventing an attack is far more desirable than detecting an attack--then responding to and recovering from it The better we do the former the easier it will be to do the latter We cannot assume however that all attacks can be prevented and therefore we must rely on a full breadth of CND capabilities to defend the network U Network-based protection systems such as perimeter firewalls and network filtering devices offer the advantage of protecting entire enclaves from many types of attack at the gateway between the Internet and an intranet UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-10 UNCLASSIFIED FOR OFFICIAL USE ONLY 9858 9859 9860 9861 9862 9863 9864 9865 9866 9867 9868 9869 9870 9871 9872 9873 9874 9875 9876 9877 9878 9879 9880 9881 9882 9883 9884 9885 9886 9887 9888 9889 9890 U Host-based protection systems on the other hand push the protection capabilities to the network endpoints Adversaries frequently consider these endpoints often user workstations to be attractive and more vulnerable targets to attack By placing resilient host-based firewalls on the individual workstations the defensive posture is increased significantly and makes them lessattractive targets An additional advantage is that even if one workstation is compromised the adversary still does not have open access to other workstations on the intranet By pairing hostbased firewalls with network-based perimeter firewalls an additional layer is added to the defense-in-depth architecture U The application filters technology area including virus protection provides the advantage of another defense-in-depth layer against cyber attack this time at the application layer A variety of wrappers have been developed to intercept system calls intended to exploit an application operating system or host access Commercial filters exist to scan email for malicious attachments This approach to protect workstations can stop attacks such as worms from propagating past the infected host or further infecting the host U Disk and file encryption a current COTS technology area provides the advantage of encrypting file data stored on hard drives This increases the work factor required by the adversary to access the file the higher the number of encryption bits the longer it will take to crack 2 6 3 1 2 3 U Risks Threats Attacks U FOUO Details of the GIG IA Risk Assessment including detailed risks threats and attacks are provided under separate cover A fair amount is known about today's adversaries and their goals and techniques Unfortunately very little can be said about the 2020 adversaries thus making protecting against them a significant challenge U FOUO Results of the risk assessment indicate that protect technologies can in some cases provide a control surface for the adversary to launch an attack against the GIG This is a risk that must be carefully considered when both designing and integrating protection mechanisms The CND architecture must be designed so that protect technologies do not introduce vulnerable choke points One approach to addressing this is to push the protection capabilities to the end point workstations rather than at network perimeters Another approach in use today is redundancy in the architecture 2 6 3 1 3 U Maturity U There is much room for improvement in protect technologies o U Current technologies are vulnerable to network attack and must be designed for robustness o U Protection must be designed throughout the network not just at the perimeters Adversaries often target the weaker less protected network endpoints such as workstations o U Protection must be designed into all network components not band-aids placed over weak Commercial-off-the-Shelf COTS and Government-off-the-Shelf GOTS devices 9891 9892 9893 9894 9895 9896 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-11 UNCLASSIFIED FOR OFFICIAL USE ONLY 9897 o U Must be designed to be effective in encrypted network environments 9898 o U Must be able to prevent attacks as close to the attack source as possible This requires the ability to first detect where the source is at the onset of the attack o U Must do a better job of protecting against an adversary with insider network access 9899 9900 9901 9902 9903 9904 9905 9906 9907 9908 9909 U FOUO Because COTS products are widely available and have been so for years protect technology is rated as Mature TRL 7-9 2 6 3 1 4 U Standards U There are no current standards for protect technologies Any standards should be closely tied to those for intrusion detection as a whole in particular if the protect technology reports unusual behavior to a centralized monitoring or analysis engine U The following Protection Profiles have been evaluated and certified with NIAP http niap nist gov cc-scheme pp index html o U U S Government Firewall Protection Profile for Medium Robustness Environments Version 1 0 o U Application-Level Firewall for Basic Robustness Environments Protection Profile Version 1 0 o U Application-Level Firewall for Medium Robustness Environments Protection Profile Version 1 0 o U Traffic Filter Firewall Protection Profile for Medium Robustness Environments Version 1 4 o U Traffic Filter Firewall Protection Profile for Low Risk Environments Version 1 1 9910 9911 9912 9913 9914 9915 9916 9917 9918 9919 9920 9921 9922 9923 9924 9925 9926 9927 9928 9929 9930 2 6 3 1 5 U Cost Limitations U Protect technologies range from inexpensive such as host-based virus filters to moderately expensive such as perimeter firewalls U The requirement to continuously update today's protect technologies with security patches and new signature downloads is a significant limitation to their usefulness and survivability Current industry practice is to issue a constant stream of patches that must be evaluated and implemented--requiring significant management overhead and annual licensing agreements Without the most recent updates these systems remain vulnerable to a variety of attacks many of which are readily downloaded from the Internet U A disadvantage of network-based protection systems is that once an attack pierces the edge device it can cause widespread harm within the intranet This is especially the case if little or no internal protection systems are in place UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-12 UNCLASSIFIED FOR OFFICIAL USE ONLY 9931 9932 9933 9934 9935 9936 9937 9938 9939 9940 9941 9942 9943 9944 9945 9946 9947 9948 9949 9950 9951 9952 9953 9954 9955 9956 U A disadvantage of host-based protection systems is that a greater number of protection systems must be managed Centralized management capabilities will be critical to this architectural approach U The disadvantages of application filters include scalability with technologies that do not have centralized management systems complexity associated with customization per user behavior and any reliance upon signatures that must be updated on a regular basis U The disadvantage of disk and file encryption is that when a file or encrypted partition is being accessed it is decrypted and vulnerable This is an inexpensive technology available today 2 6 3 1 6 U Dependencies U The ability to adequately protect a network relies heavily on maintaining control of the GIG assets as well as enforcing strong policies and procedures which GIG users are bound to follow 2 6 3 1 7 U Alternatives U The alternative to wide deployment of protect technologies is the incorporation of a strong IA architecture within the GIG 2 6 3 1 8 U Complementary Techniques U A resilient GIG network with a strong IA architecture goes a long way to provide protection against cyber attack and can therefore be considered a complementary technique For example encrypted network segments use of strong authentication and well written software immune from buffer overflow attacks can all serve to prevent network attacks There will be holes however that protect technologies will serve to plug 2 6 3 1 9 U References U A Public Key Infrastructure for the Secure Border Gateway Protocol S-BGP by K Seo C Lynn and S Kent DARPA Information Survivability Conference and Exposition II Volume 1 June 2001 pp 239-253 U Document Integrity through Mediated Interfaces by M Tallis and R Balzer DARPA Information Survivability Conference and Exposition II Volume I1 June 2001 pp 263-272 9959 U Dynamic VPN Communities Implementation and Experience by D Kindred and D Sterne DARPA Information Survivability Conference and Exposition II Volume 1 June 2001 pp 254-263 9960 U Internet Security Glossary Version 2 20 August 2004 replaces RFC2828 9961 U Preventing Denial of Service Attacks on Quality of Service by E Fulp Z Fu D Reeves S Wu and X Zhang DARPA Information Survivability Conference and Exposition II Volume I1 June 2001 pp 159-174 9957 9958 9962 9963 9964 9965 9966 U Security at the Network Edge A Distributed Firewall Architecture by T Markham and C Payne DARPA Information Survivability Conference and Exposition II Volume 1 June 2001 pp 279-286 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-13 UNCLASSIFIED FOR OFFICIAL USE ONLY 9967 U http www securecomputing com 9968 U http www symantec com 9969 2 6 3 2 U Deception Technologies 9970 2 6 3 2 1 U Technical Detail U Information systems have seen a growth in size and complexity over the past several years Unfortunately the ability to defend these systems has not evolved as quickly as the growth in the sophistication tools and techniques of attackers Attackers are constantly developing new avenues for exploitation Fortunately research activities over the past several years have produced new technologies that will support a more advanced and layered approach to security 9971 9972 9973 9974 9975 9976 9977 9978 9979 9980 9981 9982 2 6 3 2 1 1 U Honeypots U A honeypot is an information system resource whose value lies in unauthorized or illicit use of that resource - Lance Spitzner U Honeypots also known as deception-based mechanisms or decoy-based intrusion protection are specifically designed to attract an attacker's attention away from an operational system into an environment where the attacker can be observed and monitored--ideally without the attacker's knowledge 9988 U The intention of honeypots is not to capture an attacker or to thwart an attack but rather to allow an attack to proceed in a controlled manner as a means to monitor and gather information about new techniques and methods used to compromise systems This must be done while carefully balancing the benefit of learning the attacker's methods against the risk that a compromised system will be used as a launching point to attack real operational systems or other systems on the network 9989 U In general there are two ways that honeypots are implemented 9983 9984 9985 9986 9987 9990 o U Production - primarily used by companies or corporations to protect against an attack easy to use but capture limited amounts of information o U Research - primarily used by research military or government organizations complex to deploy and maintain but capture extensive amounts of information 9991 9992 9993 9994 9995 U The two general types of honeypots are o U Low-Interaction Honeypots - requires less monitoring limited interaction normally work by emulating services and operating systems o U High-Interaction Honeypots - requires more monitoring more complex normally involve real operating systems and applications 9996 9997 9998 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-14 UNCLASSIFIED FOR OFFICIAL USE ONLY 9999 10000 10001 10002 10003 10004 10005 10006 10007 10008 10009 10010 10011 10012 10013 10014 10015 10016 10017 U Low-Interaction Honeypots - Low-interaction honeypots such as Honeyd work on the concept of monitoring unused IP space Once an attack is attempted the connection is intercepted and redirected to an emulated service The honeypot is then able to detect and log the activity as well as capture all of the attacker's interaction with the emulated service In some honeypots actual operating systems can also be emulated U High-Interaction Honeypots - High-interaction honeypots such as honeynets offer an attacker an entire network of computers that are designed to be attacked Within this highly controlled network nothing is emulated or assumed The idea here is to allow the attacker to find attack and break into these systems while controlling and capturing every activity 2 6 3 2 1 2 U Honeynets U As previously discussed honeypots are deception devices within an operational network to learn an attacker's behavior and techniques Honeynets on the other hand are an entire network of deception devices and are considered a combination of high-interaction honeypots Their purpose is not focused on a specific operational environment but rather to research an attacker's behavior in general Also honeynets are excellent tools for learning how to set up and manage all aspects of operational systems including traffic analysis intrusion detection systems system log and audit capabilities system hardening and risk management Honeynets can be set up to model an entire operational network in order to research security risks and vulnerabilities of the network architecture 10023 U The Honeynet Project is an ongoing research effort that is conducted on a volunteer basis by a non-profit research organization of security professionals The organization is dedicated to learning the tools tactics and motives of the blackhat community and sharing the lessons learned to benefit both its members and the security community Founded in October 1999 the Honeynet Project is now in its fourth phase which is to create a centralized system that can collect and correlate data from distributed honeynets 10024 2 6 3 2 2 U Usage Considerations 10025 10029 2 6 3 2 2 1 U Implementation Issues U The two legal issues that need to be addressed when deploying deception technologies are entrapment and privacy Although some attackers would like to argue that their activity was induced or persuaded this is not the case Attackers target honeypots honeynets on their own initiative Therefore entrapment is most likely not an issue 10030 U When deploying deception technologies in the U S three legal issues must be considered 10018 10019 10020 10021 10022 10026 10027 10028 10031 o U Ensure compliance with laws restricting your right to monitor activities of users on your system o U Recognize and address the risk that the honeypot may be misused by attackers to commit crimes or store and distribute contraband o U Consider the possibility that the honeypot can be used to attack other systems and result in potential liability for damages 10032 10033 10034 10035 10036 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-15 UNCLASSIFIED FOR OFFICIAL USE ONLY 10037 10038 10039 10040 10041 10042 10043 10044 10045 10046 10047 10048 10049 10050 10051 10052 10053 10054 10055 10056 10057 10058 10059 10060 10061 10062 10063 U At the federal level the two main statutes concerning communications privacy are the Electronic Communication Privacy Act 18 USC 2701-11 and the federal Wiretap Statute Title III 18 USC 2510-22 Outside of the U S the applicable laws of jurisdiction may be different and should be investigated further U FOUO Honeypot and honeynet implementations can be complex and will vary depending upon the specific goals and objectives Honeypots should be placed behind the firewall protecting the operational systems in order to mitigate risk By doing so the firewall will be able to log all traffic going through it and can provide some initial alerting capability Review of the firewalls logs assuming the firewall is not compromised will assist in determining how the attack was initiated Any packets sent to the honeypot are most likely probes from an attacker as no one should be communicating with it Any traffic from a honeypot is indication that the device has been compromised This is where it is critical to have the honeypot behind a firewall--to strictly control traffic to and from the honeypot U FOUO The system logs of the honeypot must be protected An attacker will attempt to delete or modify system logs to cover their trail In addition to normal system logs for the benefit of the attacker provision must be made to export the real system logs the ones tracking the attacker's moves to a protected system for analysis This has to be done in such a manner that a sniffer used by the attacker would not detect the log files were being sent Different protocols and mechanisms can be used to achieve this U FOUO A sniffer running on the firewall can be used to capture keystrokes and screen shots so that there is documentation of everything the attacker enters and sees To prevent the hacker from using encryption to hide activities all services such as Secure Shell SSH should be disabled 2 6 3 2 2 2 U Advantages U The simple concept of honeypots and honeynets give way to some powerful strengths and advantages o U Intrusion detection capability Honeypots provide detection of new types of attacks also known as zero-day attacks that were undetected by other security mechanisms o U No false positives Honeypots by nature do not conduct authorized activity Therefore any activity captured by a honeypot is considered suspect o U Small data sets of high value Honeypots collect only small amounts of valuable information i e what the attacker is doing and how the operational systems can be better protected thus reducing the noise that needs to be analyzed o U Divert and control Attackers probing a network will encounter honeypots that divert activity away from operational systems during some percentage of the time The time an attacker spends investigating a honeypot will delay an attack on a real system o U Encryption or IPv6 Unlike most other security technologies honeypots are unaffected by encrypted or IPv6 environments 10064 10065 10066 10067 10068 10069 10070 10071 10072 10073 10074 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-16 UNCLASSIFIED FOR OFFICIAL USE ONLY 10075 10076 10077 10078 10079 10080 10081 10082 10083 10084 10085 10086 10087 10088 10089 10090 10091 10092 10093 10094 10095 10096 10097 10098 10099 10100 10101 10102 10103 10104 10105 10106 10107 10108 10109 10110 10111 U Low-interaction honeypots have the advantage of simplicity These honeypots are typically easier to deploy and maintain with minimal risk A plug-and-play approach that involves installing software and selecting the operating systems and services to be emulated and monitored makes deployment easy for most organizations In addition by containing the attacker's activity by emulated services the risk is mitigated by never allowing access to an operating system to attack or do harm Low-interaction systems work well because any access is anomalous U High-interaction honeypots give the advantage of providing attackers with actual--not emulated--operating systems and services to interact with This allows extensive amounts of information to be captured and as a result a greater opportunity to learn the full extent of the attacker's behavior Another advantage of high-interaction honeypots is that no assumptions on how an attacker will behave are made Since the environment is open and all activity is captured these honeypots are able to learn behavior beyond what is expected 2 6 3 2 2 3 U Risks Threats Attacks U FOUO There are both security and liability risks involved with deploying honeypots These devices will be compromised and could be used as launching points for other attacks Given the fact that there are ways to fingerprint many honeypot implementations it is safe to assume that an attacker will indeed determine that the device is a honeypot Therefore one must consider the threat that an attacker might retaliate in some way after being duped U FOUO All honeypots can and will be detected by an attacker who lingers long enough Some honeypots provide signatures that can be easily fingerprinted warning attackers to move on The firewalls providing some of the analysis data and protecting the operational systems can and will be compromised by determined attackers The honeypots themselves will eventually be compromised by attackers who gain root access to the systems The primary risk is that an attacker takes control of the honeypot or honeynet and uses it against the remaining operational systems or uses it as a launch point to other systems U FOUO Finally there is a risk of overdependence on honeypots honeynets Although a honeypot honeynet may be able to catch an attacker who is blindly groping a system the same success will not be shared by a more sophisticated attacker with a focused mission Therefore implementing a honeypot honeynet system may provide a false sense of security 2 6 3 2 3 U Maturity U FOUO Honeypot technology has been around for many years and both commercial and Government-developed solutions are available The current thrust in honeypot technology is to develop scalable solutions that more fully recreate a full operating system appearance to the attacker In this regard virtual machines have become highly useful to honeypot developers Overall maturity of honeypot technology is rated as Emerging TRL 4-6 while honeynet technology is rated as Early TRL 1-3 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-17 UNCLASSIFIED FOR OFFICIAL USE ONLY 10115 2 6 3 2 4 U Standards U There are no standards for honeypots and honeynets per se However there are standards that apply to data capture what data should be captured at each honeynet and in what format and data collection what data should be sent to a central collection site and in what format 10116 U Data Capture Standards 10112 10113 10114 10117 o U All network activity packets and full packet payload must be captured in tcpdump binary format OpenBSB libpcap standards and rotated compressed gzip on a daily basis o U Firewall logs must be converted to ASCII format to allow uploading into a centralized database o U An attacker's activity must be captured on the system itself In the past sniffing connections to capture keystrokes off the wire would suffice However attackers today are likely to adopt some form of encryption to communicate The Honeynet Project has developed Sebek2 a kernel module that is capable of logging an attacker's keystrokes and capturing files uploaded via secure copy scp 10118 10119 10120 10121 10122 10123 10124 10125 10126 10127 U Data Collection Standards 10128 o U Tcpdump binary logs - each honeynet can forward daily tcpdump binary log captures 10129 o U Firewall logs - every inbound and outbound connection logged by the firewall can be sent in ASCII text format on a daily basis 10130 10131 10132 10133 10134 10135 10136 10137 10138 10139 10140 10141 10142 10143 10144 10145 2 6 3 2 5 U Cost Limitations U Deception-based technologies are not necessarily expensive to deploy The cost is dependent upon the size of the operational system in which they are being placed and the maintenance and support cost to operate and manage them First and foremost it is important to consider the nature and cost of containment and control Measures should be taken to mitigate the risk of having a honeypot system deployed in a network If a product does not support any native containment and control the cost and complexity of implementation should be seriously examined U Analysis of the data is another cost that must be factored Some products provide integrated analysis reporting and alerting However other products require involvement by an administrator which could have a significant impact on the cost of using such a system Ongoing administrative costs include maintenance of content and restoration of the honeypot Periodic updates to the content will be essential to maintain the appearance of a valid and live system Also important is the need to periodically restore the system to a clean and controlled state Once again automated capabilities for restoration can greatly reduce administrative costs UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-18 UNCLASSIFIED FOR OFFICIAL USE ONLY 10146 10147 10148 10149 10150 10151 10152 10153 10154 10155 10156 10157 10158 10159 10160 10161 10162 10163 10164 10165 10166 10167 10168 10169 10170 10171 10172 10173 10174 10175 10176 10177 10178 10179 10180 10181 U Honeypots like any other technology have limitations Honeypots have a limited view in that only activity with direct interaction can be tracked and captured Therefore attacks made against other systems will not be captured Also chances are that an attacker will eventually learn that a device is a honeypot and either leave after cleaning up as much as possible or worse take punitive action against the operational systems Even a successful honeypot will provide valuable data on the steps taken by an attacker which has to be delivered to another system without the attacker's knowledge and then undergo extensive analysis before it can prove to be useful 2 6 3 2 6 U Dependencies U As an information gather tool a honeynet can employ Methodology Fingerprinting to determine the patterns of behavior of a particular attack or attacker as well as be used to discover the unknown U A honeynet can perform these tasks by controlling capturing and analyzing data Data control involves such activities as restricting inbound and outbound traffic from a compromised honeynet Such tools as a Honeywall firewalls such as OpenBSD firewall and Snort_inline a modified version of Snort that is used in the Honeynet Project to drop or modify packets would handle data control U Capturing data allows the honeynet analysts to observe intruders even in encrypted environments and without being noticed by the intruder The honeynet analysts can also monitor all attacker activity Data can be captured via keylogging firewall logs packet sniffer logs and Honeyd logs to name a few Snort Sebek and Termlog are a few tools that may be used to capture data within a honeynet The data can then be exported to a server for analysis U Data analysis includes traffic analysis IP addresses and ports traffic frequency and volume fingerprinting flags and options indicate platform personality content analysis granularity confidentiality issues encryption and digest analysis Examples of tools used to analyze the data include HoneyInspector which enables real-time analysis PrivMsg which extracts IRC conversations from tcmdump binary log files eliminates noise and Sleuthkit a forensic toolset for analyzing hacked systems U Most of the technologies workstations servers firewalls etc used to create Honeynets are not new However many of the tools used to control capture and analyze the data are new Tools such as Sebek have become available within the last two years In the future developers are planning to include capabilities to automatically filter large volumes of data correlate IDS data with other network data and provide a unified view of the event or attack 2 6 3 2 7 U Alternatives U Other capabilities exist that could track the activities of attackers but none in so controlled an environment UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-19 UNCLASSIFIED FOR OFFICIAL USE ONLY 10182 10183 10184 10185 10186 10187 10188 10189 10190 10191 10192 10193 10194 2 6 3 2 8 U Complementary Techniques U Honeypots complement network-based and host-based Intrusion Detection Systems IDSs Although closely related honeypots do not require the capability to discriminate between operational traffic and attacker traffic nor share the likelihood of many false positives 2 6 3 2 9 U References U The Evolution of Deception Technologies as a Means for Network Defense Recourse Technologies http www sans org rr papers 30 recourse php U Honeypot Definitions Requirements Standards version 1 5 3 22 October 2003 http www honeynet org alliance requirements html U Honeypots - Definitions and Value of Honeypots by Lance Spitzner http www tracking-hackers com papers honeypots html 29 May 2003 U Honeypots - Definitions and Value of Honeypots by Lance Spitzner http www secinf net honeypots Honeypots_Definitions_and_Value_of_Honeypots html 10 December 2002 10197 U Honeypots the Hottest Thing in Intrusion Detection by John Harrison http channelzone ziffdavis com article2 0%2C1759%2C1516562%2C00 asp 4 November 2003 10198 U The Honeynet Project http www honeynet org misc project html 10199 U Honeynet Project What a Honeynet Is 10200 http www awprofessional com articles printerfriendly asp p 23948 10201 U Know Your Enemy GenII Honeynets 10202 http www securesynergy com library articles 051-2003 php 10203 U Know Your Enemy Honeynets Honeynet Project http www honeynet org papers honeynet index html 12 November 2003 10195 10196 10204 10205 10206 U Know Your Enemy Chapter 8 Legal Issues by Richard Salgado http www honeynet org book Chp8 pdf 29 April 2004 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-20 UNCLASSIFIED FOR OFFICIAL USE ONLY 10207 2 6 3 3 U Situational Awareness 10208 2 6 3 3 1 U Technical Detail 10209 2 6 3 3 1 1 U UDOP U FOUO Network situational awareness capabilities include monitoring tools network health bandwidth utilization and key servers and processes on-hand as percentage of those required for fixed and deployed forces The CND UDOP provides situational awareness of CND activities operations and their impact collaboration and decision support to all levels of the GIG The CND UDOP is the integration of a comprehensive data presentation interface and data storage coupled with intelligent data acquisition The resulting solution is robust and flexible and provides situational awareness information across the DoD to support the Warfighter 10210 10211 10212 10213 10214 10215 10216 10217 10218 10219 10220 10221 10222 10223 10224 10225 10226 10227 10228 10229 10230 10231 10232 10233 10234 10235 10236 10237 10238 10239 10240 10241 U FOUO These basic requirements define what will be included in the CND UDOP The CND UDOP is defined as that portion of the IA and Network Operations NETOPS operational picture that provides local intermediate and DoD-wide situational awareness of CND activities operations and their impact collaboration and decision support The emerging CND UDOP leverages common data views and mechanisms for data sharing and displays all information necessary for the defense of DoD networks 2 6 3 3 1 2 U NETOPS U FOUO The CND UDOP is expected to receive the majority of its data from sources that will also feed the larger NETOPS picture U FOUO Information used to support the UDOP consists of both raw data inputs and processed and correlated alert information Flow data is currently used for a number of analytical techniques--namely scan and application detection Many analysis methods are available and many others are under development U FOUO Core routers form the backbone of the existing monitor network Attack detection and prevention systems installed at the core routers have the potential to detect and block attacks before they reach the enclaves Sensors at these locations provide the analyst with a high-level view of attacks launched against large numbers of hosts located at different physical locations provided that the data from the sensors is aggregated at some point Also a small number of sensors are required to detect and block attacks against a large number of hosts U FOUO Analysis is conducted on both raw and processed data whether acquired from the existing sensor grid or from other sources The analysis uses both automated and manual means to correlate sensor grid data alarms and event detections An alarm management interface provides operators the ability to acknowledge alarms and perform COAs on those alarms When launched from the main dashboard level the interface can show all of the alarms for the operator's sphere of responsibility UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-21 UNCLASSIFIED FOR OFFICIAL USE ONLY 10242 2 6 3 3 2 U Usage Considerations 10243 2 6 3 3 2 1 U Implementation Issues U FOUO Usage considerations are complex and varied The following list identifies significant requirements the system must deliver to the user 10244 10245 10246 o U FOUO The system must accomplish information sharing and information data transmission in an appropriately controlled and secure environment ensuring the appropriate security classification level for each level of user o U FOUO In disseminating technical information to users the system must provide the capability to evaluate integrate and synchronize proposed CND options with overall battle and security plans o U FOUO The system must disseminate information on defensive strategies to the CND community o U FOUO The system must provide information sharing and collaboration capabilities for near real-time tactical warning between the operations and intelligence communities o U FOUO The system must provide a capability for distributed collaboration to coordinate mitigation and response in execution of the CND mission o U FOUO The system must effectively enable controlled releasable and discloseable information sharing among authorized users within the DoD other U S Government departments and agencies law enforcement and other emergency response agencies selected non-government and private sector entities and organizations across a global architecture o U FOUO The system must be scalable and adaptable to dynamic user requirements and have the reserve capacity to support surge loading and multiple military operations 10247 10248 10249 10250 10251 10252 10253 10254 10255 10256 10257 10258 10259 10260 10261 10262 10263 10264 10265 10266 10267 10268 10269 10270 10271 10272 10273 10274 10275 10276 10277 U FOUO A sensor needs to be placed at every entrance and exit point to or from the network being protected If the network in question has no gateways LAN an assessment must be made as to what the best collection points on the network are U FOUO The use of multiple and diverse sensor products compounds the analytical task of the network analysts Each sensor has its own unique method for analyzing network packets and network sessions and for determining what constitutes an alert To reduce the number of alerts sent to the analysts from different sensors an automated approach to data correlation and summarization is needed U FOUO Data correlation needs to occur across commercial and government products bridging the gap between network sensors host-based information and audit logs Flow data is centralized and used to detect patterns Mechanisms for centralizing data dedicated circuits must be in place to transport this data The automated analysis of attacks should include indications of severity levels damage assessment and recommended COAs UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-22 UNCLASSIFIED FOR OFFICIAL USE ONLY 10278 10279 10280 10281 10282 10283 10284 10285 2 6 3 3 2 2 U Advantages U FOUO Effective CND requires an operational view of the networked environment to provide situational awareness of potential threats attacks network status and other critical information to support a mission commanders' decision-making and prevent stop or reverse degradation of network resources due to unauthorized activities The criticality of enhancing CND situational awareness is due to the increasingly information-centric operations conducted by DoD and its allies Specifically o U FOUO Commanders and their forces are dependent upon accurate complete reliable timely and secure information to conduct their missions o U FOUO Commanders and their forces are dependent on the GIG and other assets and need to know when situations exist that can affect the information systems and networks supporting their critical Warfighting processes o U FOUO DoD must protect monitor detect analyze and respond to unauthorized activity within DoD information systems and global networks to ensure continuity of operations throughout the spectrum of conflict i e CND o U FOUO Commanders need the capability to quickly comprehend the status and reliability of their information and information systems to successfully engage in network centric operations o U FOUO Network operators need the capability to develop user defined operational pictures UDOP for tailored or filtered views to meet the specific needs of Commanders and deployed Warfighters o U FOUO Network operators require insight into the networked environment that will permit real-time decisions supporting security continued availability and restoration of DoD networks o U FOUO Network operators need the capability to quickly share information concerning the status of allied coalition nations' Command Control Communications Computers C4 systems 10286 10287 10288 10289 10290 10291 10292 10293 10294 10295 10296 10297 10298 10299 10300 10301 10302 10303 10304 10305 10306 10307 10308 10309 10310 10311 10312 10313 U FOUO Another advantage of the envisioned centralized structure is the use of flow analysis Flow analysis requires much less data than content analysis which eases computing data transfer and data storage requirements resulting in significant performance benefits on a global network such as the GIG 2 6 3 3 2 3 U Risks Threats Attacks U FOUO The CND UDOP is expected to get the majority of its data from sources deployed in the ESG However additional data sources Joint CERT Database Indications Warnings etc will need to be used to complete the CND UDOP picture The correlation of information from many distributed sources represents both a risk and a challenge for DoD UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-23 UNCLASSIFIED FOR OFFICIAL USE ONLY 10314 10315 10316 10317 10318 10319 10320 10321 10322 10323 10324 10325 10326 10327 10328 10329 10330 10331 10332 10333 10334 10335 10336 10337 10338 10339 10340 10341 10342 10343 10344 10345 10346 10347 10348 U FOUO The collaboration engine and tools are the hooks into the DoD collaboration software that among other capabilities allows users of the UDOP to collaborate with other users The collaboration interface will include the capability for users of the UDOP to share and discuss incidents reports and alarms Any failure of this collaboration capability could significantly impact mission success 2 6 3 3 3 U Maturity U FOUO Automated Indications and Warning I W is a proactive process that involves collecting assembling and analyzing large amounts of intelligence data from a variety of sources Current collection correlation and visualization capabilities exist that support a NETOPS The CENTAUR flow data analysis system has been operational since 2000 U FOUO The rate of increase in network bandwidth is currently greater than the rate of increase in processing speeds and the rate of increase of memory sizes and speeds As a result automated I W components built in software i e IDSs Traffic Normalizers TNs and Intrusion Prevention Systems IPSs face significant difficulty being able to handle traffic at full line rate Unfortunately creating custom hardware such as Application-Specific Integrated Circuits ASICs requires a significant investment in manpower and in planning In response to this need various vendors have created programmable embedded systems that can process packets at full line rate in Gigabit or higher networks Such technologies are broadly referred to as Network Processors NPs U FOUO Overall the maturity levels of both UDOP and NETOPS technologies are rated Emerging TRL 4-6 2 6 3 3 4 U Standards U FOUO Other then DoD Information Technology Security Certification and Accreditation Process DITSCAP -related certification and accreditation requirements there are no standards directly applicable to this technology area However a requirements document Computer Network Defense User Defined Operational Picture CND UDOP Requirements List 23 March 2004 has been released This requirements list is expected to influence emerging standards by providing recommendations on a vendor-neutral sensor information exchange format and interface standard 2 6 3 3 5 U Cost Limitations U FOUO Analysis data centers are affordable Cluster technology which combines independent computers into a unified system or cluster through software and networking makes this analysis extremely scalable Clusters are typically used for high availability to provide greater reliability or high performance computing to provide greater computational power than a single computer can provide Beowulf clusters are an example UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-24 UNCLASSIFIED FOR OFFICIAL USE ONLY 10349 10350 10351 10352 10353 10354 10355 10356 10357 10358 10359 10360 10361 10362 10363 10364 10365 10366 10367 10368 10369 10370 U Limitations to integrating a complete UDOP include the implementation of an enhanced sensor grid across the DoD enterprise developing technologies scalable to the GIG and creating detection tools that work with the IPv6 protocol Sensor development is ongoing and will be deployed at some level in the near future However to achieve the full vision of the UDOP more robust sensors will be necessary Implementation of the sensor grid and continued research into the gap areas will further extend the current UDOP capabilities to meet UDOP needs 2 6 3 3 6 U Dependencies U FOUO Visualization and correlation engine capabilities are dependent on both the ability to collect data from many sources at high data rates and the ability to analyze this data in near real time This technology requires a source of flow data bandwidth to centralize data and sufficient disk storage to store and process data The ESG of 2008 is envisioned as a grid of sensors each fully capable of collecting sufficient data in near real time to meet the needs of the UDOP Fully implementing the sensor grid and maintaining sufficient centralized storage capacity are critical collection capabilities 2 6 3 3 7 U Complementary Techniques U FOUO A complementary technique exists on the DoD enterprise at this time CENTAUR is a metadata collection storage and analysis system that accepts Netflow data as its primary input It enables analysis of traffic flow data produced by routers to determine the presence of malicious activity The information is used to correlate collaborate both reported incidents as well as to detect anomalous activity including blatant and stealthy activities Operational incidents are reported and correlation of various network data is performed reported and distributed accordingly 10372 2 6 3 3 8 U References U Assessment of IA CND Focus Areas Mitre Corporation June 2004 10373 U Beowulf Project Overview http www beowulf org overview index html 10374 U Computer Network Defense User Defined Operational Picture CND UDOP Requirements List DISA 23 March 2004 10371 10375 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-25 UNCLASSIFIED FOR OFFICIAL USE ONLY 10376 2 6 3 4 U Network Mapping 10377 2 6 3 4 1 U Technical Detail U FOUO Vulnerability scanning tools can discover and store topology and status information about transport-layer optical devices to data routers switches and IP addresses They also have the capability to conduct a basic mapping of applications to their underlying systems and servers These tools provide a graphical view of the environment and provide indicators of the presence of new devices that have appeared since the last scan 10378 10379 10380 10381 10382 10383 10384 10385 10386 10387 10388 10389 10390 10391 10392 U FOUO Vulnerability management tools find evaluate and optionally eliminate vulnerabilities on systems before attackers take advantage of them Efficient and comprehensive near-real-time discovery tools are needed for accurate analysis of DoD's physical and virtual networks as well as to identify applications running on the network and manifestations of cyber situational awareness These tools are also needed to ensure that users adhere to security policies and to deter users from introducing vulnerabilities This desired capability must also be scalable to very large networks U FOUO In some applications mappers are combined with vulnerability databases and other correlation tools to identify potential weaknesses or routes of attack for various components In such cases these posture discovery tools enhance 10393 o U Security Monitoring Management 10394 o U Network Security 10395 o U Problem Management 10396 10397 10398 10399 10400 10401 10402 10403 10404 10405 10406 2 6 3 4 2 U Usage Considerations U FOUO Usage considerations relate to the legal concerns associated with either passive listening or active vulnerability identification Passive discovery tools have virtually no impact on normal operations as they represent one-way listening devices on the network Active discovery tools impact bandwidth availability and can cause intrusion detection alarm conditions 2 6 3 4 2 1 U Implementation Issues U FOUO In order to work most effectively vulnerability management tools should have unimpeded access to the systems to be tested Therefore the vulnerability management tools must be inside of any site firewalls In cases where multiple subnets protected by separate firewalls exist within an enclave multiple vulnerability management tools will be needed This increases the number of tools required--increasing cost and management difficulties UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-26 UNCLASSIFIED FOR OFFICIAL USE ONLY 10407 10408 10409 10410 10411 10412 10413 10414 10415 10416 10417 10418 10419 10420 10421 10422 10423 10424 10425 10426 10427 2 6 3 4 2 2 U Risks Threats Attacks U FOUO The very feature of the GIG that makes it most beneficial the ubiquitous access to the system resources enterprise-wide is also what makes the GIG an attractive target for adversaries There are over 90 countries with affirmed nation state computer network exploitation efforts at the tactical and strategic levels most collecting critical information against the United States and her allies Nearly 20 countries have confirmed dedicated computer network attack programs Their mere existence suggests success and satisfaction with the returns on their investments U FOUO In the GIG vision all systems will be interoperable and information of all types reachable from anywhere As a result there will be many insiders with potential access to information that was not available to them before In addition the connection of temporary coalition partners to the GIG will widen system access beyond our immediate control Without accurate vulnerability detection and control an adversary can use this increased capability against us and or deny us the use of these capabilities at the point when we have become most reliant upon them 2 6 3 4 3 U Maturity U FOUO Current network mapping and vulnerability discovery approaches are used for configuration management vulnerability reduction and for resource identification in large-scale enterprise networks While both active and passive mapping solutions are currently installed the usual means of accurate network discovery is to actively perform port mapping and open port investigations on network components to determine the following 10428 o U The current host operating system 10429 o U The primary use of the network component 10430 o U Services and applications running on the system 10431 o U The physical connections and topology of the network 10432 o U If current platforms have unpatched vulnerabilities or are running unsecured services 10433 10434 10435 10436 10437 10438 10439 10440 10441 10442 10443 10444 U FOUO Together the maturity of the various technologies of the Network Mapping technology area is rated as Emerging TRL 4-6 2 6 3 4 4 U Standards U FOUO Standards for mapping and vulnerability discovery are not applicable In the GIG environment near continuous monitoring will be essential because the environment will be so dynamic ad hoc creation of expedient COIs and the associated vulnerabilities etc Alert on Change could more appropriately be called Alert and Change since automated decision-making and response based on GIG-wide situational awareness will be vital to provide Active Network Defense for the GIG This will require the use of agents and a GIG-wide hierarchy of agent functional stacks for correlating and fusing the data from homogeneous and heterogeneous sensor agents spread throughout the GIG In this regard standards should be developed to reflect automated agent-based change mechanisms UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-27 UNCLASSIFIED FOR OFFICIAL USE ONLY 10445 10446 10447 10448 10449 10450 10451 10452 10453 10454 10455 10456 10457 10458 10459 10460 10461 10462 10463 10464 10465 10466 10467 10468 10469 10470 10471 10472 10473 10474 10475 10476 10477 U Common Vulnerabilities and Exposures CVE is a list or dictionary that provides common names for publicly known vulnerabilities and information security exposures CVE standardized the names for all publicly known vulnerabilities and security exposures U Open Vulnerability Assessment Language OVAL is the common language for security experts to discuss and agree upon technical details about how to check for the presence of vulnerabilities on computer systems OVAL queries are based primarily on the known vulnerabilities identified in CVE 2 6 3 4 5 U Cost Limitations U FOUO Mapping and vulnerability tools themselves represent minor costs However the implementation of an agent-based discovery technology including the capability for automated vulnerability repair represents both costs and limitations based on acceptance of allowable command functions Further although agent-based solutions require greater deployment labor they ultimately reduce operating cost by enabling near-continuous monitoring and potential Alert and Change 2 6 3 4 6 U Dependencies U FOUO To be effective in a large and ever changing environment the preferred discovery approach needs to be both fast and focused It should interpret the initial conditions and transpose these conditions through a scalable interface to the system administrator Discovery tools should also have the inherent capability to interface with other tools and agent-based architectures at local host and hierarchal levels so more advanced discoveries or controls can take place The ultimate goal would be to identify and then correct the identified deficiencies Such response tools are dependent on both accurate discovery and automated decision making U FOUO The GIG's Net-Centric Operations Warfare NCOW development problem related to vulnerability discovery is best viewed not just as communications networking information assurance and knowledge dissemination problem Rather due to size and complexity it should be viewed primarily as an artificial intelligence AI problem Here artificial intelligence is defined as U A collection of algorithms and their attendant infrastructure organized to automate a decision-making process U FOUO The GIG will need a ubiquitous AI architecture to address the discovery problem The key expected AI building block an Agent Functional Stack AFS is a collection of specialized intelligent agents organized into layers thus providing services to each other These should be used for managing IA services at the enclave initially and in the future at a COI UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-28 UNCLASSIFIED FOR OFFICIAL USE ONLY 10478 10479 10480 10481 10482 10483 10484 10485 10486 10487 2 6 3 4 7 U Alternatives U FOUO Many network mapping programs are designed to automatically discover a local network They use SNMP or pings to identify network devices and work out how they are physically connected together The network is then presented as a topology diagram with simple integrated monitoring Changes in the network are reflected in the diagram that continuously updates and are usually customizable to provide various views of the network map Some of these tools identify the characteristics of the links as well as the various devices including their operating system primary use and some even what ports they have open While current graphical network monitoring can be a useful management tool for system administrators active monitors can become bandwidth intensive when used in enterprise-level applications 10492 U FOUO A probe usually implements a portion of the device's protocol if the device does not answer properly the mapper will indicate the device as down or in the alarm or warning state Devices on the network are usually shown as various figures on a map In general each figure represents a piece of network equipment such as a router switch or hub a workstation a database or a server 10493 2 6 3 4 8 U Complementary Techniques 10494 10496 2 6 3 4 9 U References U Introduction to Vulnerability Scanning by Tony Bradley Internet Networking Security http netsecurity about com cs hackertools a aa030404 htm 10497 U http www cve mitre org 10498 U http www us-cert gov oval about html 10488 10489 10490 10491 10495 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-29 UNCLASSIFIED FOR OFFICIAL USE ONLY 10499 2 6 3 5 U Intrusion Detection Systems 10500 10505 2 6 3 5 1 U Technical Detail U Due to the ubiquitous nature of the Internet and local networks today organizations have seen an increase in the number of systems being implemented that can monitor against the growing number of intrusion events and security breaches While IDSs are primarily concerned with the detection of hostile actions they can in some cases even initiate a series of actions in response to an intrusion or attack 10506 U The two primary types of IDSs are 10501 10502 10503 10504 10507 o U Host-Based IDS - derives its source of information from a single host or system 10508 o U Network-Based IDS - derives its source of information from a whole segment of a local network 10509 10510 10511 10512 10513 10514 10515 10516 10517 10518 10519 10520 10521 10522 10523 10524 10525 10526 10527 10528 10529 10530 10531 10532 10533 10534 10535 10536 2 6 3 5 1 1 U Host-Based IDS HIDS U A HIDS resides on a single computer and provides protection for that specific computer system This allows HIDS to analyze activities with great reliability and very fine granularity HIDS are essential in monitoring systems that reside on high-speed networks and in networks in which encryption is used As HIDS are used in more critical locations their ability to both detect and withstand attacks must also increase By implementing a HIDS within the kernel layer detection can be placed closer to the root operation that compromises a system This improves the ability of a HIDS to detect both known and unknown attacks Implementation within the kernel can also help maintain the robustness of the HIDS itself by having it run within protected space where it cannot be easily modified or subverted U The current state of technology for kernel-layer HIDS shows an increasing emergence of COTS products Most of these products are agent-based solutions They intercept system calls between applications and the kernel but do not run within the context of the kernel This would make them more vulnerable to mimicry attacks and attacks against their availability 2 6 3 5 1 2 U Network-Based IDS NIDS U The majority of commercial intrusion detection systems are network-based These IDSs detect attacks by capturing and analyzing network packets By listening on a network segment or switch one NIDS can monitor the network traffic affecting multiple hosts that are connected to the network segment thereby protecting those hosts The need to work online with encrypted networks destined to a single host has seen the introduction of what some consider a separate class of intrusion detection systems known as Network Node IDS NNIDS NNIDS are a blend of HIDS and NIDS with agents deployed on every host within the network being protected typical NIDS uses network agents to monitor whole LAN segments Most of the large intrusion detection systems that are commercially offered today merge the strengths of HIDS and NIDS into a unique concept U There are generally two different analysis approaches of IDSs misuse detection and anomaly detection UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-30 UNCLASSIFIED FOR OFFICIAL USE ONLY 10537 o U Misuse Detection - Misuse detection techniques attempt to model attacks on a system as specific patterns and then systematically scan the system for occurrences of these patterns This process involves a specific encoding of previous behaviors and actions that were deemed intrusive or malicious Misuse detectors analyze system activity looking for events or sets of events that match a predefined pattern of events that describe a known attack As the patterns corresponding to known attacks are called signatures misuse detection is sometimes called signature-based detection The most common form of misuse detection used in commercial products specifies each pattern of events corresponding to an attack as a separate signature However there are more sophisticated approaches called state-based analysis techniques that can leverage a single signature to detect groups of attacks After revamping the commercial IDSs with signatures which reflect generic attack classes we seem to be in a very good position to detect incoming attacks through content examination o U Anomaly Detection - Anomaly detection approaches attempt to detect intrusions by noting significant departures from normal behavior Anomaly detectors identify abnormal unusual behavior anomalies on a host or network They function on the assumption that attacks are different from normal legitimate activity and can therefore be detected by systems that identify these differences Anomaly detection while initially attractive has yet to show any promise due to the large number of false alarms that are created Although some commercial IDSs include limited forms of anomaly detection few if any rely solely on this technology The anomaly detection that exists in commercial systems usually revolves around detecting network or port scanning However anomaly detection remains an active intrusion detection research area and may play a greater part in future IDSs 10538 10539 10540 10541 10542 10543 10544 10545 10546 10547 10548 10549 10550 10551 10552 10553 10554 10555 10556 10557 10558 10559 10560 10561 2 6 3 5 2 U Usage Considerations 10562 2 6 3 5 2 1 U Implementation Issues U Current systems require full content examination However metadata-based detectors have shown promise in handling scans and large-scale worm activities This means that detection is still very much content-oriented and that future detectors must continue to be able to handle full content examination 10563 10564 10565 10566 10567 10568 10569 10570 10571 10572 10573 10574 10575 U Physical limitations dominate Sufficient cooling power and rack space requirements are the driving factors Load balancing is also a must as detectors have fixed bandwidth limitations U There are serious concerns about deployment of NIDS and HIDS in the GIG The current architectures used by DISA and the services NIDS may not be compatible with the Black Core concept and may not scale well Further there is little protection at the enclave level today HIDS are rarely used if at all and planning and deployment in the GIG requires significant architectural work Subsequently the integration of many NIDS and HIDS into the tiers envisioned for the GIG will require significant architectural work standards development and technology development UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-31 UNCLASSIFIED FOR OFFICIAL USE ONLY 10580 2 6 3 5 2 2 U Advantages U Host-based IDSs with their ability to monitor events local to a host have the advantage of being able to detect attacks that cannot be seen by a network-based IDS Also host-based IDSs can often operate in an environment in which network traffic is encrypted by gathering information before data is encrypted or after the data is decrypted at the destination host 10581 U The advantages of misuse signature detection methods are 10576 10577 10578 10579 10582 o U Lower false alarm rates 10583 o U Simple algorithms 10584 o U Easy creation of attack signature databases 10585 o U Easy implementation 10586 o U Typically minimal system resource usage 10587 U The advantages of anomaly detection methods are 10588 o U Possibility of detection of novel attacks 10589 o U Anomalies are recognized without specific knowledge of details 10590 o U Ability to detect abuse of user privileges 10591 o U Ability to produce information that can in turn be used to define signatures for misuse detectors 10592 10593 10594 10595 10596 10597 10598 10599 10600 10601 10602 10603 10604 10605 10606 2 6 3 5 2 3 U Risks Threats Attacks U A risk exists in the fact that current commercial IDSs do not detect novel attacks nor do they catch most novel variations of attacks This is a significant technology gap in the IDS technology area and calls for more research and development U Furthermore an important distinction needs to be made between the terms detection and recognition For signature-based systems there is very little difference between the two-- detection means that an attack is recognized at least for those systems with very low falsepositives However the same is not true for anomaly-based systems Here detection data that has been recorded may not result in a report or recognition but still be analyzed more deeply at a later time Misuse detectors do not report or record near misses and so the only time the detection data is available is when an attack is recognized 2 6 3 5 3 U Maturity U While much IDS research is underway commercial IDSs are still in their formative years The negative publicity of some commercial IDSs can be attributed to the following 10607 o U Large number of false alarms 10608 o U Awkward control and reporting interfaces UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-32 UNCLASSIFIED FOR OFFICIAL USE ONLY 10609 o U Overwhelming number of attack reports 10610 o U Lack of scalability 10611 o U Lack of integration with enterprise network management 10612 10613 10614 10615 10616 10617 10618 10619 10620 U However there is a strong commercial demand for IDSs that will increase the likelihood of these problems being addressed in the near future U FOUO The various sub-technologies of the Intrusion Detection System technology area can be generally assigned Technology Readiness Level group of Emerging TRL 4-6 2 6 3 5 4 U Standards U Standardization is problematic as we are still dependent on vendor hardware that changes from time to time Still sensor outputs are standardizing with almost everyone supporting Packet Capture PCAP The PCAP library provides a high level interface to packet capture systems and allows access to all packets on the network 10625 U There are no mature IDS standards at this point in time The Internet Engineering Task Force IETF has one working group the Intrusion Detection Working Group IDWG which is tasked with defining formats and exchange procedures for sharing information of interest to intrusion detection and response system and to management systems which may need to interact with them The standards are listed in Table 2 6-1 10626 Table 2 6-1 U Standards for Intrusion Detection Systems 10621 10622 10623 10624 This table is U IETF Intrusion Detection Working Group drafts Name Description Intrusion Detection Message Exchange Requirements October 22 2002 The Intrusion Detection Message Exchange Format IDMEF January 8 2004 The Intrusion Detection Exchange Protocol IDXP October 22 2002 This Internet-Draft describes the high-level requirements for sharing IDS information http www ietf org internet-drafts draft-ietf-idwg-requirements10 txt Describes a data model to represent information exported by intrusion detection systems and explains the rationale for using this model http www ietf org internet-drafts draft-ietf-idwg-idmef-xml-12 txt Describes the Intrusion Detection Exchange Protocol IDXP an applicationlevel protocol for exchanging data between intrusion detection entities http www ietf org internet-drafts draft-ietf-idwg-beep-idxp-07 txt IETF Incident Handling Working Group working drafts Distributed Denial of Service Incident Handling Real-Time Inter-Network Defense February 28 2004 The Incident Object Description Exchange This proposal integrates current incident detection and tracing practices for network traffic which could be extended for security incident handling Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the defined protocol and extended to each NP's clients http www ietf org internet-drafts draft-moriarty-ddos-rid-06 txt Provides implementation guidelines for Computer Security Incident Response Teams CSIRT adopting the Incident Object Description Exchange Format UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-33 UNCLASSIFIED FOR OFFICIAL USE ONLY Format IODEF Implementation Guide March 9 2004 This table is U IODEF http www ietf org internet-drafts draft-ietf-inch-implement-00 txt This Table is U 10627 10628 10629 10630 10631 10632 10633 10634 10635 U Preliminary implementation work is probably possible though implementations would have to change as the standard is finalized The design involves sending XML-based alerts over an HTTP-like communications format A lot of attention has been paid to the needs of IDS analysis and to making the protocol work through firewalls in a straightforward way U There is also an effort by the ISO's T4 committee to develop an Intrusion Detection Framework The status of that effort is presently unknown and attempts to gather further information have been unsuccessful U The following Protection Profiles have been evaluated and certified with NIAP http niap nist gov cc-scheme pp index html 10636 o U Intrusion Detection System System Protection Profile Version 1 4 10637 o U Intrusion Detection System Analyzer Protection Profile Version 1 1 10638 o U Intrusion Detection System Sensor Protection Profile Version 1 1 10639 o U Intrusion Detection System Scanner Protection Profile Version 1 1 10640 10641 10642 10643 10644 10645 10646 10647 2 6 3 5 5 U Cost Limitations U The acquisition of IDS software is not the actual cost of ownership Additional costs include acquisition of a system to run the software specialized assistance in installing and configuring the system personnel training and maintenance costs Personnel to manage the system are the largest cost U Most host-based systems implement common architectures in which a host system works as a host agent reporting to a central console The associated costs of HIDS deployments can vary depending on vendor and software versions 10652 U Network-based systems can be deployed as stand-alone hosts with a possible management interface or distributed sensors and management console The cost of commercially available sensors varies depending on vendor bandwidth and functional capabilities Management consoles can be free or can cost several thousand dollars--also depending on the vendor Additional costs include hardware or back-end databases 10653 U Intrusion detection technology is still evolving Limitations of IDSs include the following 10648 10649 10650 10651 10654 o U Certain types of attacks are still possible which preclude detection at present 10655 o U Bandwidth is a serious limitation on most hardware UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-34 UNCLASSIFIED FOR OFFICIAL USE ONLY 10656 10657 10658 10659 10660 10661 10662 10663 10664 10665 10666 10667 10668 10669 10670 10671 10672 10673 10674 10675 10676 10677 10678 10679 10680 10681 10682 10683 10684 10685 10686 2 6 3 5 6 U Dependencies U We are still largely dependent on commercial vendors for hardware basic software development Other trends in computing that is believed will affect the form and function of IDS products include the move to appliance-based IDSs It is also likely that certain IDS patternmatching capabilities will move to hardware in order to handle increased bandwidth 2 6 3 5 7 U Alternatives U Government-developed IDSs may be better suited for generic attack class detection Currently systems rely on a commercially developed base which has been optimized to detect singular attacks U Current anomaly detection methods have proven inadequate and therefore prompt new methods to be researched and tried Additionally very little research has been done in the area of parallel processing of content via Beowulf clusters even though this area shows much promise Beowulf clusters are scalable performance clusters that are based on commodity hardware on a private system network and with open source software Linux infrastructure Each cluster consists of PCs or workstations that are dedicated to running high performance computing tasks with improved performance being proportional to added machines U Traffic normalizers commonly referred to as protocol scrubbers are inline network devices that remove protocol ambiguities from network traffic The primary objective of the traffic normalizer is to provide a security enhancement that aids in preventing insertion DoS and evasion attempts against IDSs thereby eliminating a weakness of many IDSs 2 6 3 5 8 U Complementary Techniques U As stated earlier metadata-based detection can take some of the load off content-based examination However in the end some content must be made available to validate any attack U When used in conjunction with firewalls and other access control devices IDSs can bolster an organization's ability to detect prevent and respond to unauthorized access and intrusion attacks Firewalls if positioned within the enclave can decrease the amount that an IDS is required to examine In addition any number of policy enforcement mechanisms i e guards OS application wrappers and anti-virus can become complements to an IDS U Several other tools exist that are often labeled as intrusion detection products by vendors These tools include vulnerability analysis assessment systems file integrity checkers and attack isolation 10689 2 6 3 5 9 U References U Algorithm-Based Approaches to Intrusion Detection and Response by Alexis Cort 16 March 2004 10690 U Beowulf Project Overview http www beowulf org overview index html 10691 U Defending Yourself The Role of Intrusion Detection Systems by John McHugh Alan Christie and Julia Allen IEEE Software - September October 2000 10687 10688 10692 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-35 UNCLASSIFIED FOR OFFICIAL USE ONLY 10693 10694 10695 10696 10697 10698 10699 10700 10701 10702 10703 10704 10705 10706 10707 10708 10709 10710 U FAQ Network Intrusion Detection Systems by Robert Graham accessed on 10 March 2004 http www robertgraham com pubs network-intrusion-detection html#2 1 U Intrusion Detection FAQ What open standards exist for Intrusion Detection by Stuart Staniford-Chen 8 April 2000 http www sans org resources idfaq id_standards php U Intrusion Detection Implementation and Operational Issues by Julia Allen Alan Christie and John McHugh IEEE Crosstalk January 2001 U Intrusion Detection Systems IDS Part 2 - Classification Methods Techniques by P Kazienko and P Dorosz 15 June 2004 http www windowsecurity com articles IDS-Part2-Classificationmethods-techniques html U Justifying the Expense of IDS Part One An Overview of ROIs for IDS by David Kinn and Kevin Timm Security Focus Infocus 18 July 2002 U NIST Special Publication on Intrusion Detection Systems by Rebecca Bace and Peter Mell U Why is a firewall alone not enough What are IDSes and why are they worth having by Wojciech Dworakowski 23 July 2004 http www windowsecurity com articles Why_is_a_firewall_alone_not_enough_What_are_IDS es_and_why_are_they_worth_having html UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-36 UNCLASSIFIED FOR OFFICIAL USE ONLY 10711 2 6 3 6 U Intrusion Prevention Systems IPSs 10712 2 6 3 6 1 U Technical Detail U A new category of CND technologies has recently emerged in the COTS environment Called Intrusion Prevention Systems IPSs these technologies represent the merger of protect capabilities with intrusion detection capabilities As technology advanced it became clear that if a device knowingly prevented an attack then it also detected the attack and could alert the operator in some useful way while also blocking it Likewise advanced technology made it possible to first detect an attack and then protect against it in either a static or dynamic fashion One can imagine that the five core CND capabilities of protect monitor detect analyze and respond could all exist together on one platform as technology continues to mature 10713 10714 10715 10716 10717 10718 10719 10720 10726 U IPSs are considered as the convergence of the fourth generation of firewall and IDS technologies IPSs can monitor traffic and decide whether to drop or allow traffic based on expert analysis These devices normally work at different areas in the network and can proactively monitor suspicious activity that may otherwise have bypassed the firewall A complete network IPS solution has the ability to enforce traditional static firewall rules and administrator-defined whitelists and blacklists 10727 U The two main types of IPSs are 10721 10722 10723 10724 10725 10728 o U Host-Based IPS - runs software directly on workstations and servers and can detect and prevent threats aimed at the local host o U Network-Based IPS - monitors from a network segment level and can detect and prevent both internal and external attacks 10729 10730 10731 10732 10733 10734 10735 10736 10737 10738 10739 10740 10741 10742 10743 10744 10745 U Host-Based IPS HIPS - As with HIDS HIPS relies on agents that are installed directly on the system being protected and are closely bound to the operating system kernel and services This allows system calls to the kernel or APIs to be monitored and intercepted in order to prevent and log attacks In addition data streams and the environment that are specific to a particular application may be monitored in order to protect against generic attacks for which no signature exists U Network-Based IPS NIPS - NIPS combines features of a standard IDS an IPS and a firewall Packets appear at either the internal or external interface and are passed to the detection engine to determine if the packet poses a threat Upon detection of a malicious packet an alert is raised the packet is discarded and the flow is marked as bad This results in the remaining packets of that particular TCP session arriving at the IPS device and immediately being discarded U In both types of IPSs attack recognition is usually accomplished by known-attack detection or anomalous behavior detection UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-37 UNCLASSIFIED FOR OFFICIAL USE ONLY 10746 2 6 3 6 2 U Usage Considerations 10747 2 6 3 6 2 1 U Implementation Issues U A number of challenges to implementing an IPS device stem from the inherent nature of being designed to work in-line thus presenting a potential choke point and single point of failure Performance of the network can be seriously impacted Increased latency and reduced throughput could become problematic as IPS devices struggle to keep pace with high speed networks A NIPS device must perform much like a network switch and meet stringent network performance and reliability requirements 10748 10749 10750 10751 10752 10753 10754 10755 10756 U Another potential problem deals with false positives Although not as critical for an IDS device false positives can be far more serious and far reaching for an in-line IPS device The result can be a self-inflicted DoS condition 10764 2 6 3 6 2 2 U Advantages U The basic advantage of an IPS in comparison to an IDS is the ability to not only detect attacks but also to block them An IPS acts to combine previous single-point security solutions i e firewalls for access control and IDS for hackers into a solitary architecture that is capable of blocking network attacks intrusions viruses malicious code and spam For zero-day attacks where the virus is previously unknown current IPS technologies can utilize databases of known protocol weaknesses and anomalous behavior techniques also known as heuristics to identify malicious traffic 10765 U The benefits of deterministic intrusion prevention can be summarized as 10757 10758 10759 10760 10761 10762 10763 10766 o U Proactive protection from the network security infrastructure 10767 o U Operational efficiencies due to reduced need to react to event logs for protection 10768 o U Increased coverage against packet attacks and zero-day attacks 10769 10770 10771 10772 10773 10774 10775 10776 10777 10778 10779 10780 10781 2 6 3 6 2 3 U Risks Threats Attacks U Few barometers exist to provide an indication as to how much software or tools are needed to protect an organization's systems Another risk is the false sense of confidence within an organization once IPS is deployed Without adequate training of personnel and proper implementation and maintenance by service providers the IPS remains at risk 2 6 3 6 3 U Maturity U As stated previously the IPS technology is new and emerging While IPSs represent a significant advancement over its predecessors the IPS technology is just beginning to evolve and gain acceptance in industry A recent trend of consolidation within the IPS industry has been observed and shows no signs of slowing The aim of these mergers is to acquire capabilities that can be re-branded into a resultant technology that is marketable as a new form of IPS U FOUO The maturity of the various sub-technologies of the Intrusion Prevention System technology area is rated Early TRL 1-3 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-38 UNCLASSIFIED FOR OFFICIAL USE ONLY 10782 10783 10784 10785 10786 10787 10788 10789 10790 10791 10792 10793 10794 10795 10796 2 6 3 6 4 U Standards U Due to the sensitive nature of most security events the information will have to be sufficiently abstracted and shared via a standardized protocol The current best candidate is the Intrusion Detection Message Exchange Format IDMEF Participating organizations would be able to exchange security-related information i e new protocol anomaly patterns and worm outbreaks Although a handful of collections have currently embarked on this endeavor adoption in production systems is sparse thus far 2 6 3 6 5 U Cost Limitations U As with any new emerging technology IPS can be widely categorized as relatively expensive Costs include the initial investment in IPS devices as well as continual costs of IPS upgrades maintenance training and management U One potential limitation of HIPS is that given the tight integration with the host operating system future OS upgrades could cause problems 2 6 3 6 6 U References U Intrusion Prevention A White Paper www nitroguard com 10798 U Intrusion Prevention Systems by Mike Barkett July 2004 http www nfr com resource downloads SentivistIPS-WP pdf 10799 U Intrusion Prevention Systems IPS January 2004 10800 http www nss co uk WhitePapers intrusion_prevention_systems htm 10801 10803 U Intrusion Prevention Systems IPS Next Generation Firewalls A Spire Research Report - March 2004 by Pete Lindstrom http www toplayer com generic Spire_IPS_Whitepaper pdf 10804 2 6 3 7 10805 2 6 3 7 1 U Technical Detail U FOUO There are many challenges in detecting and responding to insider misuse including analyzing how insider misuse differs from penetrations and other forms of misuse by outsiders The differences among users themselves vary by responsibility and involve either physical presence and or logical presence For example there may be logical insiders who are physically outside and physical insiders who are logically outside Technology solutions for user profiling are primarily focused on activity monitoring those insiders who are both logical and physical users 10797 10802 10806 10807 10808 10809 10810 10811 10812 10813 10814 10815 10816 10817 U User Activity Profiling U FOUO User activity profiling attempts to learn normal behavior patterns with respect to key observed or derived features i e resource usage and temporal patterns There are different degrees of logical insiders related to the nature of the systems and networks involved the extent to which authentication is enforced and the exact environment in which a user is operating at the moment UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-39 UNCLASSIFIED FOR OFFICIAL USE ONLY 10823 U FOUO Profiling the behavior of not only individuals but also the programs they operate can be a useful reference for detecting potential intrusions against systems In general anomaly detection techniques for profiling program behavior evolve from memorization to generalization using both host-base and network-based agent structures These techniques often employ machine-learning techniques that can generalize from past observed behavior to the problem of intrusion detection 10824 2 6 3 7 2 U Usage Considerations 10825 2 6 3 7 2 1 U Implementation Issues U FOUO Detecting insider misuse must rely heavily on user profiling of expected normal behavior as well as application-specific rules The goal of monitoring programs is to be able to detect potential insider misuse by noting irregularities in user activities or program behavior and without extensive false alarms These monitors often start from the development of a simple equality matching algorithm over time and evolve to a feed-forward back-propagation neural network for learning program behavior and finally to approaches for recognizing recurrent features in activity execution In order to detect future malicious activities against systems intrusion detection systems must be able to generalize from past observable behavior 10818 10819 10820 10821 10822 10826 10827 10828 10829 10830 10831 10832 10833 10834 10835 10836 10837 10838 10839 10840 10841 10842 10843 10844 10845 10846 10847 10848 10849 10850 10851 10852 10853 10854 10855 U FOUO The validation of profiling systems is problematic and usually relies on some variant of cross profiling wherein fine-grained system measurements for one subject are played through the trained profile of another Measurements can include network traffic activity identity of current programs being executed user typing speed time of day etc Typical measures of detection effectiveness include time to detection and probability of detection for say a user typing in a different way then normal or a window of unusual commands being issued Unfortunately this approach cannot be used to make strong claims about effectiveness against malicious use but rather about discrimination between examples of use that are to the best of the analyst's knowledge legitimate U FOUO For large enterprise environments in which monitoring key strokes are not considered practical some effort has been made to use triggers to initiate monitoring plus monitor key-stroke dynamics Triggers are most useful when closely monitored for false alarm control Keystroke dynamics tend to be much less reliable in general particularly when the differences in a typist's frame of mind or the time of day must be considered U FOUO Among the issues in implementing an activity monitor solution are providing a realtime database relating to physical whereabouts and extending statistical profiling to accommodate subtle computer usage variants Further considerations should also take into account personal behavior such as intellectual and psychological attributes U FOUO As an example of an intellectual attribute consider writing styles There are already a few tools for analyzing natural-language writing styles Profiles of individual-specific 'misspellings ' the frequency of obscenities and the choice of explicit expletives the relative use of obscure words and measures of obfuscation proclivities and meanderings are also useful UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-40 UNCLASSIFIED FOR OFFICIAL USE ONLY 10856 2 6 3 7 2 2 U Advantages 10857 U FOUO User profiling has long been used with some success to detect masquerader attacks and insider abuse In general profiling can be applied to any process under observation such as the system call stream from programs and invites analogy to process control The basic paradigm is to alert when the process under observation exhibits behavior that is extremely unusual with respect to learned norms 10858 10859 10860 10861 10862 10863 10864 10865 10866 10867 10868 10869 10870 10871 10872 10873 10874 10875 U FOUO As previously discussed there are generally two types of intrusion detection systems misuse detection and anomaly detection The most significant advantage of misuse detection approaches is that known attacks can be detected fairly reliably and with a low false positive rate 2 6 3 7 2 3 U Risks Threats Attacks U FOUO Masquerader and insider abuse pose fundamentally different problems than traditional detection solutions were intended to resolve The masquerader may be detected by stylistic differences while the insider can train his profile so that the eventual exploit appears normal The difficulty is exacerbated by the problem of a hit and run attack where the exploit is one event in an otherwise normal stream U FOUO Another difficult to resolve problem is the false alarm Even with fine-grained user profiles user job functions mature and profiles change over time There is a serious risk that a tool's alarm generation capability will be greatly limited to reduce the number of false alarms being generated 10881 U FOUO Many Government organizations strongly endorse the use of proprietary COTS IDSlike software that are unsecure unreliable and nonsurvivable There are few emerging intrusion detection systems that are completely reliable at detecting hitherto unrecognized insider misuse The reality that COTS intrusion-detection tools are not oriented toward insider attacks unknown forms of misuse intelligent results interpretation and long-term evolution presents a very significant reason for closer evaluation of GOTS solutions 10882 2 6 3 7 3 U Maturity 10883 U FOUO Efforts to date have concentrated on relatively straightforward statistical measures thresholds weightings and statistical aging of the profiles independent of particular users The basic problem with tools that automatically learn user models from things like what applications the person uses order important and the associated timing information is scalability and computation time For this reason current solutions are limited to enclave-level networks 10876 10877 10878 10879 10880 10884 10885 10886 10887 10888 10889 U FOUO The maturity of the various sub-technologies of the User Activity Profiling technology area is rated Early TRL 1-3 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-41 UNCLASSIFIED FOR OFFICIAL USE ONLY 10890 10891 10892 10893 10894 10895 10896 10897 2 6 3 7 4 U Standards U FOUO There are no standards that address this technology need However USSTRATCOM has published a CND Insider Threat Requirements document that addresses basic objectives and needs for insider threat technology solutions 2 6 3 7 5 U Cost Limitations U FOUO Simple activity monitor technologies that trigger more large-scale monitoring are not expensive to deploy The cost is dependent upon the size of the operational system in which they are being placed and the maintenance and support cost to operate and manage them 10904 2 6 3 7 6 U Dependencies U FOUO Adequate controls of insider misuse suggest that better system security is necessary as one part of the solution There is a fundamental need for better differential access controls access control lists compartmentalized protection fine-grain roles etc There is also a need for better user authentication to prevent intruders from gaining insider access and to provide positive identification of insiders that might diminish their ability to masquerade as other insiders and to otherwise hide their identities 10905 2 6 3 7 7 U Alternatives 10906 U FOUO Personal on-line behavior can also be profiled statistically by extending the analysis information that is recorded such as with whom an individual tends to exchange e-mail which Web sites are visited regularly and even what level of sophistication the user appears to exhibit This is only a minor extension of what can be done with monitor tools available today 10898 10899 10900 10901 10902 10903 10907 10908 10909 10910 10911 10912 10913 2 6 3 7 8 U Complementary Techniques U FOUO There are a few relative differences in detecting insider misuse compared with outsider-initiated misuse but these differences do not seem to be intrinsic Instead the differences might involve the following 10914 o U Information to be gathered 10915 o U Rules given to an expert system 10916 o U Parameters used to tune the profile-based analysis 10917 o U Priorities associated with different modes of misuse 10918 o U Urgency accorded to various responses 10919 10920 10921 10922 U FOUO Some new inference tools might be useful but they could also be developed generally enough to be applicable to outsider misuse as well 2 6 3 7 9 U References U CND Insider Threat Requirements V0 43 USSTRATCOM August 2004 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-42 UNCLASSIFIED FOR OFFICIAL USE ONLY 10923 10924 10925 10926 10927 10928 10929 10930 10931 U The Challenges of Insider Misuse by Peter G Neumann Sri Computer Science Lab PostWorkshop Version 23 August 1999 Prepared For The Workshop On Preventing Detecting And Responding To Malicious Insider Misuse 16-18 August 1999 At Rand Santa Monica California U Evaluating Software Sensors for Actively Profiling Windows 2000 Computer Users by Jude Shavlik University of Wisconsin-Madison Mark Shavlik Michael Fahland Shavlik Technologies St Paul Minnesota U Learning Program Behavior Profiles for Intrusion Detection by Anup K Ghosh Aaron Schwartzbard Michael Schatz Reliable Software Technologies Corporation UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-43 UNCLASSIFIED FOR OFFICIAL USE ONLY 10932 2 6 3 8 U Cyber Attack Attribution 10933 2 6 3 8 1 U Technical Detail U FOUO Approaches in defending network-based intrusions are categorized as intrusion prevention intrusion detection intrusion tolerance and intrusion response Response mechanisms usually take two approaches localizing the source of the attack using traceback techniques or reducing the intensity of the attack by blocking attack packets 10934 10935 10936 10937 10938 10939 10940 10941 10942 10943 10944 10945 U FOUO To hide their identity network-based intruders seldom attack directly from their own hosts but rather from hosts acting as intermediate stepping-stones or zombies Spoofing the return address in a one-way communications is also a common practice In order to identify the intruder behind these stepping-stones it is necessary to be able to trace through each intermediate host and construct the correct intrusion connection chain Traceback is the term used to describe the technology for reconstructing the connection chain to the original IP host U FOUO There are several different approaches of tracking and tracing attacks via route-based distributed packet filtering some of which include 10946 o U Hop-by-Hop Traceback 10947 o U Backscatter Traceback 10948 o U CenterTrack 10949 o U ICMP Traceback or iTrace 10950 o U Hash-Based IP Traceback 10951 10952 10953 10954 10955 10956 10957 10958 10959 10960 10961 10962 10963 10964 10965 10966 10967 2 6 3 8 1 1 U Hop-by-Hop Traceback U The most common and basic in use today hop-by-hop traceback traces large continuous packet flows that are currently in progress and that originate from spoofed source addresses i e DoS packet flood attack Starting with the Internet Service Provider's ISP's router closest to the victim an ISP administrator uses the diagnostic debugging or logging features of the router to characterize the nature of the traffic and determine the input link of the attack The administrator then moves to the upstream router where the attack packets are coming from This diagnostic procedure and trace backwards is repeated--hop-by-hop--until the source of the attack is ultimately found 2 6 3 8 1 2 U Backscatter Traceback U The backscatter traceback technique makes clever use of the large number of invalid source addresses that are characteristic of contemporary distributed denial-of-service DDoS attacks Once a DDoS attack has been identified routers are configured by the ISP to reject all packets destined for the victim This will result in a slew of destination unreachable error message packets or backscatter that can be routed for capture This technique makes use of the fact that the Internet Address Naming Authority IANA has not allocated several large blocks of IP addresses for global routing UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-44 UNCLASSIFIED FOR OFFICIAL USE ONLY 10968 10969 10970 10971 10972 10973 10974 10975 10976 10977 10978 10979 10980 10981 10982 10983 10984 10985 10986 10987 2 6 3 8 1 3 U CenterTrack U The CenterTrack approach improves traceability by adding an overlay network or auxiliary network formed from the joining of new physical logical connections on top of the existing one The overlay network is optimized for hop-by-hop tracing and analysis because of having only a small number of hops between edge routers Intended DoS flood attack packets can be diverted to the overlay network which is equipped with special-purpose tracking routers 2 6 3 8 1 4 U ICMP Traceback or iTrace U The fundamental concept is that about once in every 20 000 packets a router sends an ICMP traceback message called an iTrace packet to the same destination address as the sampled packet or to an outboard monitor The destination or monitor collects and correlates the tracking information to successfully trace the attack 2 6 3 8 1 5 U Hash-Based IP Traceback U All of the traceback methods described so far have limited capability because each of these techniques requires a large amount of attack traffic to support tracking Arguably the most promising new research approach Hash-Based IP Traceback also known as Single-Packet IP Traceback offers the possibility of making feasible the traceback of single IP packets The fundamental idea is to store highly compact representations of each packet rather than the full packets themselves These compact representations are called packet digests and are created using mathematical functions called hash functions Hash-based IP traceback uses a system known as Source Path Isolation Engine SPIE 10999 U FOUO Using a timing and marking approach current research has been able to develop a partial solution to the traceback problem The ARDA Footfall Project at North Carolina State University is currently evaluating a new method of embedding that works in real-time and spreads the delay across all the packet pairs selected The method is based on actively watermarking the traffic timing so that traffic can be correlated across stepping stones or intermediate hosts and through the network The basic idea is to manipulate the timing in such a way that the traffic is uniquely recognizable by an analysis program Watermarking techniques create a method of traceback that is almost arbitrarily robust to attempts by attackers to perturb traffic timing to avoid traceability It is expected that the approach developed through the Footfall Project will be the first deployable partial solution on DoD networks This technology transition should take place by the end of 2005 Therefore the integration of a partial traceback solution on the DoD network will take place before GIG Technology increment 1 11000 2 6 3 8 2 U Usage Considerations 11001 2 6 3 8 2 1 U Implementation Issues U Route-based traceback is a very labor-intensive technical process and often requires cooperation among bordering ISPs to complete the trace Routers at each hop will need sufficient diagnostic capabilities to follow the trace In addition as in tracing a phone call by the police the attack must remain in progress in order for the trace to be completed back to its origin 10988 10989 10990 10991 10992 10993 10994 10995 10996 10997 10998 11002 11003 11004 11005 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-45 UNCLASSIFIED FOR OFFICIAL USE ONLY 11006 11007 11008 11009 11010 11011 11012 11013 11014 11015 11016 11017 11018 11019 11020 11021 11022 11023 11024 11025 11026 11027 11028 11029 11030 11031 11032 11033 11034 11035 11036 11037 11038 11039 11040 U FOUO There are also policy implications that need to be considered Careful coordination needs to be in place as attacks can flow across administrative jurisdictional and national boundaries Unlike passive defense techniques active traceback can involve privacy laws These laws directly impact automated systems that perform investigations for law enforcement While the legal issues prevent Government use of some available commercial systems private firms use them to gather information or actively react to network intrusions U FOUO The three U S Laws that dictate legal considerations are the Electronic Communications Privacy Act ECPA 18USC2701 the Wiretap Act 18USC2511 and the Trap and Trace Act 18USC3121 Since these laws were not written directly to protect against computer network crime additional case law and interpretation is necessary to determine their exact relationship to traceback U FOUO There are also some less defined areas within the statutes themselves Specifically techniques that involve some form of content monitoring or fingerprinting may violate privacy issues Privacy protects the original packet contents not a digested metric of the packet itself Additionally there are distinctions made between collecting and disclosing to others voluntary versus non-voluntary collection and stored access versus real-time access The bottom line is that a traceback technology solution could violate the law under some conditions U FOUO Unlike actual adversaries legal restrictions and the rights of U S citizens limit the capabilities of Defensive Information Operations DIO services For example a Red Team cannot target public domain servers being used as avenues to place malicious code on DoD hosts However real adversaries do target and exploit public domain servers at will Also even if all legal restraints were lifted robust tools were developed and additional defensive resources were available the ability to respond to attacks would still be challenged by political considerations based on adversarial relationships 2 6 3 8 2 2 U Advantages U Backscatter traceback is a fast and efficient method of countering DDoS flood attacks U An advantage of the CenterTrack approach is that special-purpose tracking and analysis features are not needed on all routers but only on the edge routers and those for special-purpose tracking U All of the probabilistic traceback approaches depend on auditing very sparse samples of large packet flows and thus are well suited for attacks that generate massive packet flows such as DDoS floods 2 6 3 8 2 3 U Risks Threats Attacks U Hop-by-hop traceback of DDoS attacks can be adversely affected due to resource consumption of bandwidth and processing power in the network by the DDoS attack itself UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-46 UNCLASSIFIED FOR OFFICIAL USE ONLY 11041 11042 11043 11044 11045 11046 11047 11048 11049 11050 11051 11052 11053 11054 11055 11056 11057 11058 11059 11060 11061 11062 11063 11064 11065 11066 11067 11068 11069 11070 11071 11072 11073 11074 11075 11076 11077 11078 U Backscatter traceback is heavily dependent upon specific characteristics of DDoS attacks it was defined to defeat Like many other approaches designed to work against DDoS flood attacks its success depends on a large number of attack packets being directed to a victim and is therefore not as effective to subtle attacks As attack methodology continues to advance i e DDoS attack tool that uses randomly selected IP address from valid IANA allocation the backscatter traceback technique will eventually be defeated In addition attacks that do not forge zombie source addresses would also be able to defeat this technique U The CenterTrack approach fails when an attack originates inside an ISP's network In addition high scalability is uncertain for DDoS attacks with many entry points into the ISP's network U The iTrace approach can be defeated or disrupted by sending spoofed iTrace packets Therefore iTrace packets must include an authentication field 2 6 3 8 3 U Maturity U FOUO DoD organizations investigating attacks currently use manual techniques There is no current automated solution to traceback Existing approaches have focused on identifying the set of correlated connections in the connection chain These approaches have overlooked the serialization of those correlated connections thus providing an incomplete solution Wang March 2004 U FOUO The maturity of the various sub-technologies of the Cyber Attack Attribution technology area is rated Early TRL 1-3 2 6 3 8 4 U Standards U FOUO One emerging standard that will help--but not solve the traceback problem--is implementation of the IPv6 protocol Another standard that could significantly reduce the problem would be requiring all routers to place their own unique ID in the protocol of each packet they receive The drawback to this approach is that the routing overhead would increase greatly and all existing hardware would need to be replaced One technique that uses a query approach between routers employs the Intrusion Detection and Isolation Protocol IDIP developed through a Defense Advanced Research Projects Agency DARPA project At this time no standard is being promoted for resolving the traceback gap area 2 6 3 8 5 U Cost Limitations U FOUO Route-based distributed packet filtering for attack prevention and traceback has been widely studied Tracing IP packets with forged source addresses requires complex and often expensive techniques to observe the traffic at routers and reconstruct a packet's real path traveled Tracing becomes ineffective when the volume of attack traffic is small or the attack is distributed U FOUO Currently available Traceback tools that can be used by DoD are primarily Government-off-the-Shelf GOTS Additionally there are a limited number of authorized organizations that can use these tools UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-47 UNCLASSIFIED FOR OFFICIAL USE ONLY 11079 11080 11081 11082 11083 11084 11085 11086 11087 11088 11089 11090 11091 11092 11093 11094 11095 U Policy implications can limit the tracing of attacks that go beyond administrative jurisdictional and international boundaries and will most likely depend upon the trustworthiness cooperation and skill of other ISPs U For the CenterTrack approach an increase in the overall complexity can result in operational errors i e routing updates Also the overhead inherent in creating IP tunnels could amplify a DoS flood's negative effects on the network 2 6 3 8 6 U Dependencies U International agreements will need to be established in order to formalize the cooperation needed to make the techniques effective This may need to include agreements to share traceback technology if the overall level of skill needed to complete a trace is not sufficient 2 6 3 8 7 U Alternatives U FOUO Within DoD the alternatives to traceback using traditional techniques form the basis of the currently deployed Defense-in-Depth approach Until deployable automated traceback can be developed only defensive approaches and manual techniques are available 2 6 3 8 8 U Complementary Techniques U Other research works such as various intrusion detection models data mining-based models and IDSs are complementary to the aforementioned traceback techniques 11099 2 6 3 8 9 U References U Advanced and Authenticated Marking Schemes for IP Traceback by Dawn Song and Adrian Perrig University of California Berkeley DARPA Research Project N6601-99-28913 11100 U The Footfall Project http footfall csc ncsu edu index htm 11101 U A Little Background on Trace Back CSC 774 Network Security Spring 2003 http discovery csc ncsu edu pning Courses csc774 on-trace-back pdf 11096 11097 11098 11102 11103 11104 11105 11106 11107 11108 11109 11110 U The Loop Fallacy and Serialization in Tracing Intrusion Connections through Stepping Stones by Xinyuan Wang North Carolina State University SAC' 04 March 14-17 2004 Nicosia Cypress U Technical Legal and Societal Challenges to Automated Attack Traceback by Susan Lee and Clay Shields Technical ITPro May June 2002 U Tracking and Tracing Cyber Attacks Technical Challenges and Global Policy Issues by Howard F Lipson CMU SEI-2002-SR-009 November 2002 http www cert org archive pdf 02sr009 pdf UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-48 UNCLASSIFIED FOR OFFICIAL USE ONLY 11111 2 6 3 9 U Correlation Technologies 11112 2 6 3 9 1 U Technical Detail U FOUO Correlation technologies are tools that provide the capabilities to perform data aggregation correlation reduction and analysis With the widespread integration of security solutions such as intrusion detection and protection prevention systems into the global networked environment comes an increased need to implement tools that provide for the management of the data collected by these systems 11113 11114 11115 11116 11117 11118 11119 11120 11121 11122 11123 U FOUO Many security solutions generate enormous quantities of data It has become necessary to use applications to perform the comprehensive analysis necessary to correlate security event data in a timely real-time near real-time manner The analysis of this data allows for the identification of the anomalies and trends that are buried within the data These events must then be displayed and reported in the most comprehensive method possible in order to respond immediately to an event 11129 U FOUO The GIG architecture calls for a significant increase in network bandwidth throughout the entire system from the core to the remote wireless endpoints As network bandwidth increases the job of CND becomes more challenging Both the volume of packets inspected by CND technologies and the number of alerts generated by the CND tools increase tremendously For this reason alert correlation becomes increasingly important through each of the GIG IA increments 11130 U As stated by Haines et al 11124 11125 11126 11127 11128 11131 o U Correlation systems take as input the output produced by low-level sensors such as intrusion detection systems firewalls and integrity checkers Correlators issue reports that group together related alerts and events to provide an improved understanding of a suspected cyber attack and to help analysts identify and dismiss false alarms Human administrators use these reports to understand the state of their network and select an appropriate response o U The goal of correlation is to provide high-level reasoning beyond low-level sensor capabilities 11132 11133 11134 11135 11136 11137 11138 11139 11140 11141 11142 11143 11144 11145 U FOUO As a data analysis tool the correlation tool pulls attack reconnaissance and log data from a number of sources e g network and computer sensors NIDS HIDS firewalls packet filtering routers and vulnerability assessment tools It also normalizes data from stovepipe systems correlates prioritizes and reduces that data Using the normalized data the tool generates graphical representations of data and generates reports The normalized data can then be used later for forensics analysis The data presented in the reports would trigger the active response capability to provide immediate mitigation to a highly destructive event UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-49 UNCLASSIFIED FOR OFFICIAL USE ONLY 11146 11147 11148 11149 11150 11151 11152 11153 11154 11155 11156 11157 U FOUO In the current state of the art security vulnerability analysis tools consider individual vulnerabilities independent of one another Moreover they analyze single machines only in isolation from other machines in the network However the interdependency of vulnerabilities and the connectivity of a network make such analysis incomplete While a single vulnerability itself may not pose a significant direct threat to a system a combination of vulnerabilities may Thus even well administered networks are vulnerable to attacks because of the security ramifications of offering a variety of combined services That is services that are secure when offered in isolation nonetheless render the network insecure when offered simultaneously U FOUO Many current tools address vulnerabilities in isolation and in the context of a single host only This can be extended by searching for sequences of interdependent vulnerabilities distributed among the various hosts in a network This approach is called Topological Vulnerability Analysis TVA 11160 U Correlation tools include components to perform data capture agent data collection and storage manager organization and tagging database and a user interface console or webbased The data being manipulated by the system internally should be encrypted 11161 2 6 3 9 2 U Usage Considerations 11162 2 6 3 9 2 1 U Implementation Issues U As correlation technologies are currently in the research and development stage implementation issues have not yet been fully explored It is expected however that there will be some significant obstacles that must be addressed For example some correlation approaches rely on the sensor's ability to learn what normal network traffic is and thus develop the ability to identify and correlate unusual events If the correlation engine requires knowledge of typical adversary behavior this too must be analyzed tailored to the specific network segment and incorporated into the system If the correlation engine requires knowledge of the network architecture or vulnerabilities the capability to readily include this information preferably in a mostly automated manner must be integrated 11158 11159 11163 11164 11165 11166 11167 11168 11169 11170 11171 11172 11173 11174 11175 11176 U Intrusion detection on an encrypted network in itself presents significant challenges that must be addressed before the next step of correlation can be taken U Implementing a collective set of correlation technologies rather than a single one to further enhance analysis capabilities has significant cost integration maintenance and management implications UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-50 UNCLASSIFIED FOR OFFICIAL USE ONLY 11177 11178 11179 11180 11181 11182 11183 11184 11185 11186 11187 11188 11189 11190 11191 11192 11193 11194 11195 11196 2 6 3 9 2 2 U Advantages U The advantage to correlating alert information as opposed to having teams of analysts digging through voluminous near-raw alert data is significant as the bandwidth of the GIG increases It will not be practical to rely on pure human analysis of this data in the future It is critical to CND to have the ability to reduce the overall volume of alert information as well as correlate similar alerts disparate alerts alerts detected by a variety of sensor systems and alerts collected on a variety of different network systems It will be important to be able to correlate alerts across different tiers within the GIG architecture It will be critical to have this information available to the key decision makers at all levels within the GIG in near-real time And eventually the ability to include mission priorities in the correlation process will put the CND analyst in a position to be proactive about protecting the mission rather than reactive U With the assistance of correlation technologies the analyst is better able to quickly assess a current status of the network by focusing on manageable information sets With the assistance of advanced visualization tools this process is further enhanced From this information decisions on response actions can be made and implemented For future iterations of correlation capabilities it is desirable to overlay mission priorities on the correlation analysis to see if the mission is targeted or impacted as a result of a malicious network event or if response actions will impact the mission in an undesirable manner 2 6 3 9 2 3 U Risks Threats Attacks U There are three key risks 11197 o U The first is the user's ability to trust that the data has been correlated accurately 11198 o U The second is the ability to trust that the correlation process has not dropped key alerts o U The third to the ability to trust that the correlation process has not developed false positives 11199 11200 11201 11202 11203 11204 11205 11206 11207 11208 11209 11210 11211 11212 11213 U The only way to address these risks is to continue to invest in correlation research and development to improve these systems U It is conceivable that an adversary could try to distract a correlation system by intentionally triggering alerts and hiding the real attack traffic in the subsequent smokescreen This is something to be addressed by the research community 2 6 3 9 3 U Maturity U As previously stated correlation technologies are currently in the research prototype stage There are no advanced correlation technologies available off-the-shelf today While some COTS sensors have limited data reduction capabilities such as reducing the individual alerts due to a scan true analytical correlation with disparate alerts is not commercially available However alert correlation has been the subject of recent research with proof of concept technologies currently being explored showing promising results Several of these are referenced below UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-51 UNCLASSIFIED FOR OFFICIAL USE ONLY 11214 11215 11216 11217 11218 11219 11220 11221 11222 11223 11224 11225 11226 11227 11228 11229 11230 11231 11232 11233 11234 11235 11236 11237 11238 11239 11240 11241 11242 11243 11244 11245 11246 11247 11248 11249 11250 U Research has shown that the combination of different correlation technologies rather than a single technology can yield even better results This allows the disparate systems to focus on their strengths and compensate for one another's weaknesses U FOUO The maturity of the various sub-technologies of the Correlation technology area is rated Early TRL 1-3 2 6 3 9 4 U Standards U There are no correlation standards at this time 2 6 3 9 5 U Cost Limitations U Correlation technology cost is unknown at this time However one can assume that it would cost in the range of an advanced IDS Some advanced IDSs will include correlation capabilities Costs associated with the manpower to monitor the systems can be a limitation depending on the number of sensors being managed monitored per analyst and the volume of data collected 2 6 3 9 6 U Dependencies U Correlation systems rely in total on the alert information that it can access It is absolutely essential for advanced accurate sensors to precede the implementation of correlation technologies These sensors must be effective in detecting malicious activity on encrypted network segments U Correlation systems also depend on the ability to display the correlated results While some systems can generate reports or visual aids much work can be done to improve current prototypes Ideally correlation results would be fed into a complete situational awareness picture for further analysis 2 6 3 9 7 U Alternatives U The alternative to correlating alert information is to simply increase the overall assurance of a network and prevent attacks from the outset Since this is clearly unrealistic the remaining alternative is to rely on human analysis to draw the correlation relationships This would be a significant challenge with every increasing bandwidth and the sheer volume of network components that must be monitored 2 6 3 9 8 U Complementary Techniques U Again human analysts can correlate information manually to some degree However these capabilities can be improved upon significantly with the proper use of computing mathematical and modeling power 2 6 3 9 9 U References U Adaptive Model-Based Monitoring for Cyber Attack Detection by A Valdes K Skinner Recent Advances in Intrusion Detection RAID 2000 pp 80-92 U A Mission-Impact-Based Approach to INFOSEC Alarm Correlation by P Porras M Fong A Valdes Proceedings Recent Advances in Intrusion Detection Zurich Switzerland October 2002 pp 95-114 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-52 UNCLASSIFIED FOR OFFICIAL USE ONLY 11251 11252 11253 11254 11255 11256 U Probabilistic Alert Correlation by A Valdes K Skinner Recent Advances in Intrusion Detection RAID 2001 U Scyllarus Intrusion Detection Report Correlator and Analyzer by W Heimerdinger DARPA Information Survivability Conference and Exposition Volume 2 April 2003 pp 24-26 U The STAT Toolsuite by G Vigna M Eckmann R A Kemmerer DARPA Information Survivability Conference and Exposition Volume 2 April 2003 pp 46-55 11258 U Validation of Sensor Alert Correlators by J Haines D Ryder L Tinnel S Taylor IEEE Security and Privacy January February 2003 pp 46-56 11259 U http www sdl sri com programs intrusion 11260 U http www cs ucsb edu rsg STAT 11257 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-53 UNCLASSIFIED FOR OFFICIAL USE ONLY 11261 2 6 3 10 U CND Response Actions 11262 2 6 3 10 1 U Technical Detail U FOUO U S Strategic Command USSTRATCOM defines CND Response Actions CND RAs as deliberate authorized defensive measures or activities that protect and defend DoD computer systems and networks under attack or targeted for attack by adversary computer systems networks CND RAs extend DoD's layered defense-in-depth capabilities and increase DoD's ability to withstand adversary attacks 11263 11264 11265 11266 11267 11268 11269 11270 11271 11272 11273 11274 U Response actions are taken as a result of a detected intrusion and can be either automated or manual--requiring a human in the loop to activate the response Response actions are implemented to stop ongoing attacks such as a denial-of-service or to plug already exploited vulnerabilities from future network attack U Response actions can be construed as counter attack when the action reaches beyond the GIG controlled assets to target the source of the attack There are currently notable legal limitations on such actions 11279 U Response actions can be proactive in nature updating a security posture based on external intelligence or other sources or to prioritize mission critical asset protections prior to executing an operations plan By the same token proactive response actions can be targeted against adversary assets in support of an operation This action generally falls under the computer network attack category and will not be discussed further herein 11280 2 6 3 10 2 U Usage Considerations 11281 2 6 3 10 2 1 U Implementation Issues U Clearly the ramifications of response actions can be far reaching especially if the response does not take into consideration mission priorities The actions must be well considered and if there is time and opportunity modeling the response in advance of implementing it can be advantageous In cases where an active attack must be stopped it will not be practical to take the time to do any modeling In such an instance an immediate short-term response can be taken followed by a well-considered longer-term solution that has undergone analysis and in some cases modeling 11275 11276 11277 11278 11282 11283 11284 11285 11286 11287 11288 11289 11290 11291 11292 11293 11294 11295 11296 U While automated response capabilities do exist in a limited capacity in some COTS and research prototype technologies automated response is not currently a widely accepted practice DoD policies and procedures limit or prohibit an automated response in most cases and lack of experience and in-depth knowledge of CND capabilities makes the leadership chain hesitant to fully trust and use automated engines U When the technology becomes available response actions need to be global solutions coordinated across multiple network enclaves rather than localized implementations There are bound to be significant conflicts resulting in temporary loss of mission critical assets otherwise UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-54 UNCLASSIFIED FOR OFFICIAL USE ONLY 11297 11298 11299 11300 11301 11302 11303 11304 11305 11306 11307 11308 11309 11310 11311 11312 11313 11314 11315 11316 11317 11318 11319 11320 11321 11322 11323 11324 11325 11326 11327 11328 11329 11330 11331 11332 11333 11334 11335 11336 U There is discussion between the CND community and the network management community as to who will actually implement the response actions whether it is a CND analyst or a network management operator As the GIG progresses the lines between the two groups will continue to blur and it will be absolutely critical for both to work hand-in-hand continuously In many cases the technologies used to implement the responses will often be the same technologies that either detected or prevented some portion of the attack It is impractical to think that a clean hand-off to the network management group will be possible Response is also frequently an iterative process requiring a series of detected and analyzed intrusion detection alerts followed by more and more refined response actions 2 6 3 10 2 2 U Advantages U Responding to a network attack provides the opportunity for the defenders to stop malicious network events and prevent the adversary from reaching its goals Without implementing some sort of a responsive action an adversary that has gained unauthorized access will have the luxury of time to collect further intelligence about the GIG network assets and see a wealth of sensitive data U The advantage of automated response is that malicious packets can be stopped within seconds of being detected This packet race can be critical in blocking the adversary before more lethal network attacks are launched It is not a perfect solution as the adversary will still be at least one packet ahead of the defenders and this is particularly critical with the most sophisticated adversaries that have the one packet one kill mentality It is far better to prevent the attack in the first place than to have to monitor detect analyze and then respond to unauthorized activity The shorter the time window between detection and response the closer one reaches prevention U The disadvantage to an automated response however is that the impact of the initial response may not be fully analyzed This is why the two-tiered response approach provides additional value Automated response must be resilient to adversary techniques intended to trigger it U Manual response on the other hand requires analysis time and human intervention which can be slow and sometimes inaccurate It does however allow for manual consideration of the mission impact and consultation with the appropriate chain of command 2 6 3 10 2 3 U Risks Threats Attacks U The risk of this technology is that response actions that are not well considered can have a detrimental impact on mission-critical GIG network functionality Loss of functionality can be far reaching and result in significant down time to the user community A negative impact of this sort could cause the user community and the chain of command to lack trust and therefore not use the response technology which would leave the networks vulnerable once again U If the adversary were able to trigger the response technology in some way to also make it untrustworthy or to cause an analyst to disable the capability there would be a negative impact on the GIG In this case the technology would actually provide an additional control surface for the adversary to exploit--something which has been a point of interest in the risk assessment UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-55 UNCLASSIFIED FOR OFFICIAL USE ONLY 11337 11338 11339 11340 11341 11342 11343 11344 11345 11346 11347 11348 11349 11350 11351 11352 11353 11354 11355 11356 11357 11358 11359 11360 11361 11362 11363 11364 11365 11366 11367 11368 11369 11370 2 6 3 10 3 U Maturity U There are available today a handful of CND technologies with integrated response capabilities For example a commercial DoS discovery technology is able to monitor and analyze packets and once a threshold has been crossed alert the operator that a DoS has been detected The technology then recommends a course of action to block the attack which can be implemented either manually or automatically in a neighboring perimeter router U Response capabilities have been the subject of much research within the DoD as noted in the references section below Research prototypes have been developed and they show much promise especially when paired with sophisticated correlation systems The science of launching sophisticated response actions would also benefit tremendously from the capability to include mission-critical network assets plans alternatives and the notion of timing Research into advancing response technologies beyond their present state should yield capabilities and technologies far greater than what is available today for both the DoD and its adversaries U FOUO The maturity of the various sub-technologies of the CND Response Actions technology area is rated Early TRL 1-3 2 6 3 10 4 U Standards U There are no current standards for response actions Any standards for response should be closely tied to those for intrusion detection 2 6 3 10 5 U Cost Limitations U Response technologies may be integral to other CND technologies so the cost of the technology product should be explored as a unit and is expected to be similar to that of other CND technologies Research costs to develop response technologies however are expected to be significant U The usefulness of response technologies will be limited by the ability to centrally manage a set of devices and the number of deployed DoD experts available to operate the systems and make critical and timely decisions involving response actions 2 6 3 10 6 U Dependencies U Response technologies are highly dependent on reliable intrusion detection data which is in turn dependent upon monitoring and analysis capabilities Without these coordinated sophisticated response actions will be unattainable In addition it will be important for the CND analyst to have access to reliable and comprehensive situational awareness data in near real time to make decisions and monitor the effects of response actions This situational awareness data should include operational plans and prioritization of mission-critical assets in a time-based schedule UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-56 UNCLASSIFIED FOR OFFICIAL USE ONLY 11371 11372 11373 11374 11375 11376 11377 11378 11379 11380 11381 11382 11383 11384 11385 11386 11387 11388 11389 11390 11391 11392 11393 11394 11395 2 6 3 10 7 U Alternatives U The alternative to response technologies is a manual process of analyzing intrusion detection information and manually updating the security posture based on engineering judgment This rudimentary approach will give the adversary the advantage of time Equally important the CND analyst responsible for reviewing the intrusion detection data will be more likely to experience fatigue miss critical events or make mistakes recommending and implementing response actions 2 6 3 10 8 U Complementary Techniques U The only complementary technique to response actions is to constantly evaluate and update the security posture of the GIG network devices as a result of perceived or known network threats 2 6 3 10 9 U References U Autonomic Response to Distributed Denial of Service Attacks by D Sterne K Djahandari B Wilson B Babson D Schnackenberg H Holliday and T Reid Proceedings of the 4th International Symposium on Recent Advances in Intrusion Detection RAID October 2001 pp 134-149 U Cooperative Intrusion Traceback and Response Architecture CITRA by D Schnackenberg H Holliday R Smith K Djahandari and D Sterne DARPA Information Survivability Conference and Exposition II Volume 1 June 2001 pp 56-68 U Electronic Quarantine An Automated Intruder Response Tool by P Brutch T Brutch and U Pooch Proceedings of the 1998 IEEE Information Survivability Workshop ISW'98 October 1998 U SARA Survivable Autonomic Response Architecture by S Lewandowski D Van Hook G O'Leary J Haines and L Rossey DARPA Information Survivability Conference and Exposition II Volume 1 June 2001 pp 77-88 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-57 UNCLASSIFIED FOR OFFICIAL USE ONLY 11396 2 6 3 11 U Automated IAVA Patch Management 11397 2 6 3 11 1 U Technical Detail U FOUO Until recently patch management had always been a labor and time-intensive ordeal with little or no support tools Patch management tools are now available that automate much of the process including discovery of reported vulnerabilities and patches scanning systems for vulnerabilities and configuration status assisting in the analysis and decision making process to decide which patches to deploy and when testing proposed patches in controlled environments deploying patches to systems and verifying successful patch deployments 11398 11399 11400 11401 11402 11403 11407 U FOUO Since patch management only addresses software defects that lead to vulnerabilities management tools are being integrated into security and vulnerability management tools that can provide a more complete system management capability These newer tools reduce the amount of human intervention now required with current solutions 11408 2 6 3 11 2 U Usage Considerations 11409 2 6 3 11 2 1 U Implementation Issues U FOUO Best practices in patch management indicate that a thorough analysis of proposed patches must be conducted to assess whether the patch even applies and if so to what systems within the production environment The potential impacts to those systems must be clearly understood and evaluated and a priority assigned to mitigating the vulnerability 11404 11405 11406 11410 11411 11412 11413 11414 11415 11416 11417 11418 11419 11420 11421 11422 11423 11424 11425 11426 11427 U FOUO Vulnerabilities in widely used applications such as Microsoft's Internet Explorer IE would have high priority because of the number of users the pervasive use of IE by other applications and the severity of the attacks that could be mounted against it IE is one of those applications where extensive testing must be performed to understand the impact of the patch in the production environment Fixing one security vulnerability problem could cause others to arise or could cause some functions of IE to stop working U FOUO Patches must be implemented quickly to thwart attacks using discovered vulnerabilities However deploying untested patches in a production environment may prove more costly than the attack All patches should be thoroughly tested before deployment on as many of the release configurations as possible A patch is just that--a quick fix to correct a functional bug or to counter a security vulnerability It is not uncommon for a patch that corrects one problem to cause one or more other problems U FOUO Standard software releases should be periodically re-baselined to avoid patches colliding with each other and to simplify maintaining patch and configuration status UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-58 UNCLASSIFIED FOR OFFICIAL USE ONLY 11428 11429 11430 11431 11432 11433 11434 11435 11436 11437 11438 11439 11440 11441 11442 11443 2 6 3 11 2 2 U Advantages U FOUO Patch management technologies enable the automation of much of the laborintensive aspects of identifying analyzing and deploying patches As the complexity of network systems continues to grow manually-based patch management techniques quickly demonstrated their inability to scale with it Stand-alone patch management products answer the immediate need of businesses to provide some relief in mitigating vulnerabilities Patch management capabilities are being integrated into vulnerability management and system management tools to provide security and administration personnel even more automated capabilities 2 6 3 11 2 3 U Risks Threats Attacks U FOUO Patch management by itself is not a complete security solution It only addresses software defects It needs to be integrated into a system management capability that includes asset inventory vulnerability configuration and policy management According to the vulnerabilities reported from CERT http www cert org stats the number of vulnerabilities that must be addressed by the patch management task has steadily increased through 2002 and is only slightly tapering off as indicated in Figure 2 6-3 U Vulnerabilities Reported from CERT The total vulnerabilities reported 1995-2Q 2004 14 686 4500 4000 3500 3000 2500 Vulnerabilities 2000 1500 1000 500 19 95 19 96 19 97 19 98 19 99 20 00 20 01 20 02 1Q 20 03 -2 Q 20 04 0 Year This figure is U 11444 11445 11446 11447 11448 11449 11450 Figure 2 6-3 U Vulnerabilities Reported from CERT 2 6 3 11 3 U Maturity U FOUO The maturity of the various sub-technologies of the Automated IAVA Patch Management technology area is rated as Emerging TRL 4-6 U The maturity of patch management systems can be seen in the wide variety of products that are currently available The following are examples of point solution products UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-59 UNCLASSIFIED FOR OFFICIAL USE ONLY 11451 o U BigFix - BigFix Enterprise - http www bigfix com 11452 o U Ecora - Ecora Patch Manager - http www ecora com 11453 o U PatchLink Corporation - PatchLink Update - http www patchlink com 11454 o U SecurityProfiling - SysUpdate - http www securityprofiling com 11455 o U Shavlik - Shavlik HFNetChkPro - http www shavlik com 11456 o U St Bernard Software - UpdateEXPERT - http www stbernard com 11457 o U Microsoft - Software Update Services - http www microsoft com 11458 U The following are examples of security management products 11459 o U Citadel Security Software - http www citadel com 11460 o U Configuresoft - Enterprise Configuration Manager - http www configuresoft com 11461 U The following are examples of security configuration management products 11462 o U Altiris - Client Management Suite - http www altiris com products clientmgmt 11463 o U LANDesk Software - LANDesk Management Suite - http www landesk com 11464 o U ManageSoft - Security Patch Management - http www managesoft com solution patchmanagement index xml 11465 11466 o U HP - Novadigm - http www novadigm com 11467 o U Novell partner with PatchLink - ZENworks Patch Management - http www novell com products zenworks patchmanagement 11468 11469 o 11471 11472 11473 11474 11475 11476 11477 11478 11479 U Symantec ON Technology partner with Shavlik - iPatch and iCommand - http www on com 11470 U The following is an example of a vulnerability management product o U Harris Corporation - STAT Scanner - http www stat harris com index asp 2 6 3 11 4 U Standards U FOUO There are no standards on patch management Generally all of the products offer similar capabilities following a de-facto industry best practice 2 6 3 11 5 U Cost Limitations U FOUO A variety of options exist for acquiring patch management products and services Generally there is a per seat price with break points at various quantities or an option to acquire an enterprise-wide license Most vendors also offer a managed service capability UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-60 UNCLASSIFIED FOR OFFICIAL USE ONLY 11480 11481 11482 11483 11484 11485 11486 11487 11488 11489 11490 11491 11492 11493 2 6 3 11 6 U Dependencies U FOUO Patch management systems receive vulnerability and patch information from a number of industry and Government sources Continued on-line access to these systems is required in order to maintain the most current information about patches U FOUO An asset inventory of PCs and servers must be established and maintained that includes an up to date listing of operating system and applications with current patch and service pack status The patch management system must periodically scan the PCs and servers to determine if there have been any changes to the status of the information on file This status information is used during the analysis of a newly discovered patch or security vulnerability to determine which system may be vulnerable what the likely impact will be to the enterprise and what priority should be given to the mitigation of the vulnerability 2 6 3 11 7 U Alternatives U Basically there are two types of patch management architectures available o U Agent-less Agent-less based approach does not require any special software on the target machines This approach typically uses RPC calls to scan machines for status and to deliver patches This approach may result in some machines that cannot use such IT management tools to be patched manually o U Agent-based Agent-based approach use special software delivered to each target system to enable communication with the patch server and to perform operations locally on the targeted machine This approach typically uses TCP IP to communicate with the server and could enable security features such as encryption that may not otherwise be available Devices with limited bandwidth may require the use of agent-based software Fortunately vendors are making applications that support both capabilities 11494 11495 11496 11497 11498 11499 11500 11501 11502 11503 11504 11505 11506 11507 11508 11509 11510 11511 11512 11513 11514 11515 11516 11517 U FOUO Patch management systems are evolving to become an integral part of system management and vulnerability management applications A separate patch management capability may not be needed in the near future 2 6 3 11 8 U Complementary Techniques U FOUO Patch management is not a new concept It is the evolution from a manual discovery and mitigation process to partially automated steps and from discrete patch management tools to integrated security management tools These tools include asset management vulnerability assessment and management policy compliance configuration management and patch management 2 6 3 11 9 U References U Get Ready to Patch by Foley and Hulme InformationWeek 30 August 2004 http www informationweek com story showArticle jhtml articleID 45400083 U Patch Management is a Fast Growing Market by Schroder Colville and Nicolett Gartner 30 May 2003 http download microsoft com download a 2 6 a2625228-9394-4388-8dcfde876ccfa88c Gartner_patch_mgt_fast_growing pdf UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-61 UNCLASSIFIED FOR OFFICIAL USE ONLY 11518 11519 11520 11521 11522 11523 11524 11525 11526 11527 11528 11529 11530 11531 11532 11533 11534 11535 11536 11537 11538 11539 11540 11541 11542 11543 U Patch Management Vendor Overview by Mark Nicolett Colville and Silver Gartner 27 May 2004 U Patching Things Up Emerging Technology CIO Magazine 1 August 2003 http www cio com archive 080103 et_article html U Practical Patch Management NetworkWorldFusion 21 October 2002 http www nwfusion com supp security2 patch html U Robust Patch Management Requires Specific Capabilities by Nicolett and Colville Gartner 18 March 2004 http www knowledgestorm com sol_summary_63613 asp U Security Patches Plugging the Leaks in the Dike by Karen Krebsbach Bank Technology News August 2004 http www banktechnews com article html id 20040802B1GHC6AT U SQL Slammer Lesson Patch Management Is Not Enough by Mark Nicolett and John Pescatore Tech Republic 2 July 2003 http techrepublic com com 5102-6264-5054273 html U Taking Control of Vulnerabilities Citadel Security Software Interview with John Pescatore Gartner Research Interview conducted 27 April 2004 http mediaproducts gartner com gc webletter citadel issue3 gartner1 html U The Need for Patch Management Symantec June 2004 http sea symantec com content displaypdf cfm pdfid 29 U The Power of Optional Agent Arcitecture Advantages of Managing Patches Remotely with UpdateEXPERT St Bernard Software Inc 28 July 2003 http www stbernard com products docs OptionalAgent pdf U Vulnerability and IT Security Management Are Converging by Mark Nicolett Gartner 10 February 2004 U Vulnerability Management Technology Landscape by Mark Nicolett Gartner 11 September 2003 UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-62 UNCLASSIFIED FOR OFFICIAL USE ONLY 11544 11545 11546 2 6 4 U Network Defense and Situational Awareness Gap Analysis U FOUO Table 2 6-2 is a matrix of Network Defense and Situational Awareness technologies described in previous sections The adequacy matrix is based upon 2008 capabilities UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-63 UNCLASSIFIED FOR OFFICIAL USE ONLY Table 2 6-2 U Network Defense Situational Awareness Technology Gap Assessment 11547 11548 This table is U N A N A Unauthorized Malicious Activity Prevention N A N A N A N A Configuration Change N A N A N A N A Information Monitoring N A Information Presentation N A N A Unauthorized Malicious Activity Identification N A N A Unauthorized Malicious Activity Reporting N A N A Data Reduction Correlation N A N A CND Response N A Alert Correlation N A Attack Attribution N A User Activity Profiling N A Network-Based IPS Host-Based IPS N A Network-Based IDS Virus Protection N A Automated Patch Management Honeypots Honeynets Situational Awareness Vulnerability Scanning Firewalls Filtering Routers Network N A Host-Based IDS Protect Monitor Analyze Detect IA Attributes Vulnerability Assessment Reporting Firewalls Host Technology Categories Required Capability RCD attribute N A N A N A N A N A IACND6 IACND7 N A N A N A N A N A N A N A N A N A N A IACND8 IACND9 N A IACND10 N A IACND11 N A UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-64 N A IACND12 N A IACND13 IACND14 UNCLASSIFIED FOR OFFICIAL USE ONLY This table is U N A N A N A N A IACND17 Development Coordination of COAs N A N A N A N A N A N A IACND16 IACND18 IACND20 Modeling Simulation of COAs N A N A N A N A N A Respond Response Actions Recovery Actions N A N A N A N A N A N A N A N A N A N A N A N A N A N A N A N A N A N A N A 11549 UNCLASSIFIED FOR OFFICIAL USE ONLY N A Required Capability RCD attribute IACND19 IACND21 IACND23 N A This table is U 2 6-65 N A CND Response N A Alert Correlation Information Visualization Sharing Attack Attribution IACND15 User Activity Profiling N A Network-Based IPS N A Host-Based IPS N A Network-Based IDS N A Host-Based IDS N A Automated Patch Management Honeypots Honeynets Situational Awareness Vulnerability Scanning Firewalls Filtering Routers Network Unauthorized Malicious Activity Analysis Virus Protection Firewalls Host Technology Categories N A N A N A IACND22 IACND24 UNCLASSIFIED FOR OFFICIAL USE ONLY 11550 11551 11552 11553 11554 11555 11556 2 6 5 U Network Defense and Situational Awareness Recommendations and Timelines U FOUO The following recommendations have been identified in the Network Defense and Situational Awareness Enabler Without these the GIG Vision cannot be fully satisfied The recommendations are organized in the following categories Standards Technology and Infrastructure 2 6 5 1 U Standards U One or more standards on sensor data are needed to address 11557 o U Format of sensor data 11558 o U Semantics of sensor data 11559 11560 11561 11562 11563 2 6 5 2 U Technology U It is unlikely that today's protect technologies alone can stop sophisticated stealthy attacks In order to raise the bar on the sophisticated risk-averse adversary tomorrow's protect technologies must include capabilities such as o U Dynamic protection mechanisms capable of modifying the defensive structure either on-the-fly as a result of an adverse event or in a proactive organized defensive manner o U Adaptive self-learning capabilities that do not rely on previously known attack signatures o U Ability to successfully protect encrypted network segments As current protect technologies are not designed to operate on encrypted network segments additional research and development is needed to develop new capabilities and technologies designed for such an environment 11564 11565 11566 11567 11568 11569 11570 11571 11572 11573 11574 11575 11576 11577 11578 11579 11580 11581 11582 11583 11584 U FOUO In general the Situational Awareness technologies represented by the current capabilities are not scalable to the needs of the GIG More robust tools are needed to automatically collect and correlate a variety of information sources and to augment many of the I W tasks that are now extremely manpower intensive Additional processing requiring automation is the assessment of changes in an adversary's posture and perceived threat intent for all three levels of the Defense-in-Depth security strategy computing environment enclave and network U FOUO The scalability issue with current correlation tools the need for collection capabilities both at the packet level and from metadata sources on a very large enterprise and the need to integrate some form of risk analysis based on current conditions has created several technology gap areas These technology areas are currently being researched and solutions are expected within the GIG Increment 1 time period U FOUO Table 2 6-3 summarizes needs gaps and areas for exploration for Situational Awareness UNCLASSIFIED FOR OFFICIAL USE ONLY 2 6-66 UNCLASSIFIED FOR OFFICIAL USE ONLY Table 2 6-3 U FOUO Summary of Technology Gaps 11585 This table is U FOUO Need Gaps Areas for Exploration Develop and present the situation via GUI The GUI supports all of the other needs listed below 3-D scientific data visualization tools for this application need enhancing Interactive GUI tools and forms need developing specific to this application Application high-level security management and operations Application-specific software tools need to be written for this DoD problem domain Infrastructure mediumlevel security management and operations Research products e g Outpost Network Policy Product from Federally Funded Research and Development Centers FFRDCs need to be extended Security device lowlevel management and operations Many COTS Intrusion Detection Systems IDSs exist Applying them to large-scale DoD enterprise systems is a challenge Ways to effectively present to the user the security configuration and status of the enterprise The GUI needs to allow the user to respond to events Management events would include changes in the network and new requirements Operational events would include alerts problems and failures Managing changes in software to support changes in policy developing CND COAs deploying new CND services and upgrading IAVM processes Operationally performing the IAVM process setting INFOCON levels dynamically coordinating cyber awareness and reactions with other organizations Managing security of web portals and servers access lists in routers database servers modem pools and policy settings in proxy servers Operationally changing routing paths accessibility to domain name servers and the accessibility status of a modem port Managing external-threat intrusion detectors internal-threat sensors and policy settings in firewalls Operationally anal