Appendix 1 - NARA IT Security Requirements.pdf

NARA

IT Security Requirements

NATIONAL ARCHIVES AND RECORDS

ADMINISTRATION

March 9, 2022

Version 7.2

Enterprise Architecture IT Security Requirement Version 7.2

SecA.Requirements.docx i 03/09/22

Version Control

Document version

Description of contents/revisions

Editor

Date

6.0 Revised entire document to

reflect new NIST SP800-

53Rev4 guidance

J. Appleman 11/10/14

6.1 Updated mistyped reference

names in AC, CA and CM sections

J. Appleman 07/16/16

6.2 Update CA-6 requirement for

continuous authorization J. Appleman 09/22/16

6.3 Update AC-2e to reflect NARA

policy J Appleman 12/29/16

6.4 Updated PL-4, PL-4c, and PL-

4(1) to reflect NARA policy J Appleman 01/19/17

6.5 Updated SI-2c to reflect

requirement established in the

SI Methodology

J Appleman 01/25/17

6.6 Updated AC-2j, AC-2(3), RA-

5d, SC-28, AP-2, AR-2, AR-8, DI-1, DI-1c

J Appleman 03/22/17

6.7 MP-3a, CP-8, PE-11, PL-9, SA-

11, SA-12(1), SA-15, SA-34,

SI-3, DI-1

J Appleman 04/20/17

6.8 SC-28 J Appleman 05/09/17

6.9 CA-5 changed “yearly” to

“monthly”

J Appleman 01/09/18

6.10 PE-8 changed “SSP-defined” to

“annually”, AU-11(1) removed

“a minimum of 5 years for

Sources And Methods

Intelligence information”, AC-

12 changed “SSP-defined conditions or trigger events requiring session disconnect” to

“within 30 minutes of inactivity”.

J Appleman 03/20/18

6.11 Updated RA-5 and SI-2

remediation timeframes

J Appleman 07/09/18

6.12 Updated AT-3 J Appleman 09/14/18

6.13 RA-5(5) J. Appleman 10/01/18

SecA.Requirements.docx ii 03/09/22

6.14 IA-5 J Appleman 11/01/18

6.15 IA-5 J Appleman 11/01/18

6.16 RA-5d and SI-2c: incorporated

BOD 19-02 requirements

J Appleman 05/06/19

6.17 PL-2(3) added moderate J Appleman 06/18/19

6.18 RA-5d and SI-2c: updated the

critical requirement

J Appleman 09/12/19

7.0 All sections to 800-53rev5

guidelines and controls J Appleman 2021

7.1 Updated AU-2, AU-3, AU-8

and AU-11 with M-21-31 required language

J Appleman 11/22/21

7.2 Updated IA-5(1)(h) J Appleman 03/09/22

SecA.Requirements.docx iii 03/09/22

Table of Contents

1. Introduction 1

2. NARA IT Security Requirements 2

2.1 Access Control Requirements 2

AC-1. Access Control Policy and Procedures 2

AC-2. Account Management 4

AC-3. Access Enforcement 10

AC-4. Information Flow Enforcement 18

AC-5. Separation of Duties 28

AC-6. Least Privilege 29

AC-7. Unsuccessful Login Attempts 33

AC-8. System Use Notification 35

AC-9. Previous Logon (Access) Notification 36

AC-10. Concurrent Session Control 37

AC-11. Session Lock 37

AC-12. Session Termination 38

AC-13. Supervision and Review — Access Control 39

AC-14. Permitted Actions without Identification or Authentication 39

AC-15. Automated Marking 40

AC-16. Security Attributes 40

AC-17. Remote Access 45

AC-18. Wireless Access 48

AC-19. Access Control for Mobile Devices 50

AC-20. Use of External Systems 52

AC-21. Information Sharing 55

AC-22. Publicly Accessible Content 56

AC-23. Data Mining Protection 57

AC-24 ACCESS CONTROL DECISIONS 58

AC-25 REFERENCE MONITOR 59

2.2 Awareness and Training Requirements 60

AT-1. Security Awareness and Training Policy and Procedures 60

AT-2. Security Awareness Training 61

AT-3. Role-Based Security Training 64

AT-4. Security Training Records 67

AT-5. Contacts with Security Groups and Associations 67

AT-6 Training Feedback. 68

2.3 Audit and Accountability Requirements 68

AU-1. Audit and Accountability Policy and Procedures 68

AU-2. Auditable Events 69

AU-3. Content of Audit Records 71

AU-4. Audit Storage Capacity 73

SecA.Requirements.docx iv 03/09/22

AU-5. Response to Audit Processing Failures 73

AU-6. Audit Review, Analysis, and Reporting 76

AU-7. Audit Reduction and Report Generation 79

AU-8. Time Stamps 80

AU-9. Protection of Audit Information 80

AU-10. Non-Repudiation 83

AU-11. Audit Record Retention 85

AU-12. Audit Generation 86

AU-13. Monitoring for Information Disclosure 88

AU-14. Session Audit 89

AU-15. Alternate Audit Capability 90

AU-16. Cross-Organizational Auditing 90

2.4 Assessment and Authorization Requirements 92

CA-1. Assessment and Authorization Policies and Procedures 92

CA-2. Control Assessments 93

CA-3. Information Exchange 97

CA-4. Security Certification 99

CA-5. Plan of Action and Milestones 99

CA-6. Authorization 100

CA-7. Continuous Monitoring 102

CA-8 Penetration Testing 105

CA-9 Internal System Connections 107

2.5 Configuration Management Requirements 108

CM-1. Configuration Management Policy and Procedures 108

CM-2. Baseline Configuration 109

CM-3. Configuration Change Control 112

CM-4. Security Impact Analysis 115

CM-5. Access Restrictions for Change 117

CM-6. Configuration Settings 118

CM-7. Least Functionality 120

CM-8. System Component Inventory 124

CM-9. Configuration Management Plan 128

CM-10 Software Usage Restrictions 130

CM-11 User-Installed Software 131

CM-12 Information Location 132

CM-13 Data Action Mapping 133

CM-14 Signed Components 133

2.6 Contingency Planning Requirements 134

CP-1. Contingency Planning Policy and Procedures 134

CP-2. Contingency Plan 135

CP-3. Contingency Training 139

CP-4. Contingency Plan Testing 140

CP-5. Contingency Plan Update 142

SecA.Requirements.docx v 03/09/22

CP-6. Alternate Storage Site 142

CP-7. Alternate Processing Site 144

CP-8. Telecommunications Services 146

CP-9. System Backup 148

CP-10. System Recovery and Reconstitution 151

CP-11 Alternate Communications Protocols 153

CP-12 Safe Mode 153

CP-13 Alternative Security Mechanisms 154

2.7 Identification and Authentication Requirements 154

IA-1. Identification and Authentication Policy and Procedures 154

IA-2. Identification and Authentication (NARA Users) 156

IA-3. Device Identification and Authentication 160

IA-4. Identifier Management 161

IA-5. Authenticator Management 164

IA-6. Authenticator Feedback 171

IA-7. Cryptographic Module Authentication 172

IA-8. Identification and Authentication (Non-NARA Users) 172

IA-9 Service Identification and Authentication 174

IA-10 Adaptive Identification and Authentication 175

IA-11 Re-Authentication 175

IA-12 Identity Proofing 176

2.8 Incident Response Requirements 178

IR-1. Incident Response Policy and Procedures 178

IR-2. Incident Response Training 179

IR-3. Incident Response Testing 181

IR-4. Incident Handling 182

IR-5. Incident Monitoring 189

IR-6. Incident Reporting 189

IR-7. Incident Response Assistance 191

IR-8. Incident Response Plan 192

IR-9. Information Spillage Response 194

IR-10. Integrated Information Security Analysis Team 195

2.9 Maintenance Requirements 196

MA-1. System Maintenance Policy and Procedures 196

MA-2. Controlled Maintenance 197

MA-3. Maintenance Tools 198

MA-4. Non-Local Maintenance 200

MA-5. Maintenance Personnel 203

MA-6. Timely Maintenance 206

MA-7 Field Maintenance 207

2.10 Media Protection Requirements 208

MP-1. Media Protection Policy and Procedures 208

MP-2. Media Access 209

SecA.Requirements.docx vi 03/09/22

MP-3. Media Marking 210

MP-4. Media Storage 210

MP-5. Media Transport 211

MP-6. Media Sanitization 212

MP-7 Media Use 215

MP-8 Media Downgrading 216

2.11 Physical and Environmental Protection Requirements 218

PE-1. Physical and Environmental Protection Policy and Procedures 218

PE-2. Physical Access Authorizations 219

PE-3. Physical Access Control 220

PE-4. Access Control for Transmission Medium 224

PE-5. Access Control for Output Devices 224

PE-6. Monitoring Physical Access 225

PE-7. Visitor Control 227

PE-8. Access Records 227

PE-9. Power Equipment and Power Cabling 228

PE-10. Emergency Shutoff 229

PE-11. Emergency Power 229

PE-12. Emergency Lighting 230

PE-13. Fire Protection 231

PE-14. Temperature and Humidity Controls 232

PE-15. Water Damage Protection 233

PE-16. Delivery and Removal 234

PE-17. Alternate Work Site 234

PE-18. Location of System Components 235

PE-19. Information Leakage 235

PE-20. Asset Monitoring and Tracking 236

PE-21. Electromagnetic Pulse Protection 236

PE-22. Component Marking 237

PE-23. Facility Location 238

2.12 Security Planning Requirements 238

PL-1. Security Planning Policy and Procedures 238

PL-2. System Security Plan 239

PL-3. System Security Plan Update 242

PL-4. Rules of Behavior 242

PL-5. Privacy Impact Assessment 243

PL-6. Security-Related Activity Planning 243

PL-7 Security Concept of Operations 243

PL-8 Security and Privacy Architecture 244

PL-9 Central Management 247

PL-10 Baseline Selection 248

PL-11 Baseline Tailoring 248

2.13 Security Program Requirements 249

SecA.Requirements.docx vii 03/09/22

PM-1. Information Security Program Plan 249

PM-2. Senior Information Security Officer 251

PM-3. Information Security Resources 251

PM-4. Plan of Action and Milestones Process 252

PM-5. System Inventory 253

PM-6. Information Security Measures of Performance 253

PM-7. Enterprise Architecture 254

PM-8. Critical Infrastructure Plan 255

PM-9. Risk Management Strategy 255

PM-10. Security Authorization Process 256

PM-11. Mission/Business Process Definition 257

PM-12 Insider Threat Program 258

PM-13 Information Security Workforce 259

PM-14 Testing, Training, and Monitoring 259

PM-15 Contacts with Security Groups and Associations 260

PM-16 Threat Awareness Program 261

PM-17 Protecting Controlled Unclassified Information on External Systems 262

PM-18 Privacy Program Plan 262

PM-19 Privacy Program Leadership Role 264

PM-20 Dissemination of Privacy Program Information 264

PM-21 Accounting of Disclosures 265

PM-22 Personally Identifiable Information Quality Management 266

PM-23 Data Governance Body 268

PM-24 Data Integrity Board 268

PM-25 Minimization of Personally Identifiable Information Used in Testing, Training and Research 269

PM-26 Complaint Management 270

PM-27 Privacy Reporting 270

PM-28 Risk Framing 271

PM-29 Risk Management Program Leadership Roles 272

PM-30 Supply Chain Risk Management Strategy 272

PM-31 Continuous Monitoring Strategy 274

PM-32 Purposing 275

2.14 Personnel Security Requirements 275

PS-1. Personnel Security Policy and Procedures 275

PS-2. Position Categorization 277

PS-3. Personnel Screening 277

PS-4. Personnel Termination 279

PS-5. Personnel Transfer 280

PS-6. Access Agreements 281

PS-7. External Personnel Security 283

PS-8. Personnel Sanctions 283

PS-9. Position Descriptions 284

2.15 Personally Identifiable Information Processing and Transparency Family 284

PT-1. Personally Identifiable Information Processing and Transparency Policy and Procedures 284

SecA.Requirements.docx viii 03/09/22

PT-2. Authority to Process Personally Identifiable Information 286

PT-3. Personally Identifiable Information Processing Purposes 287

PT-4. Consent 289

PT-5. Privacy Notice 290

PT-6. System and Records Notice 292

PT-7. Specific Categories of Personally Identifiable Information 294

PT-8. Computer Matching Requirements 295

2.16 Risk Assessment Requirements 296

RA-1. Risk Assessment Policy and Procedures 296

RA-2. Security Categorization 297

RA-3. Risk Assessment 298

RA-4. Risk Assessment Update 301

RA-5. Vulnerability Scanning 301

RA-6 Technical Surveillance Countermeasures Survey 306

RA-7 Risk Response 307

RA-8 Privacy Impact Assessments 307

RA-9 Criticality Analysis 309

RA-10 Threat Hunting 310

2.17 System and Services Acquisition Requirements 310

SA-1. System and Services Acquisition Policy and Procedures 310

SA-2. Allocation of Resources 312

SA-3. System Development Life Cycle 312

SA-4. Acquisition Process 314

SA-5. System Documentation 320

SA-6. Software Usage Restrictions 322

SA-7. User-Installed Software 322

SA-8. Security Engineering Principles 322

SA-9. External System Services 341

SA-10. Developer Configuration Management 345

SA-11. Developer Security Testing 348

SA-12. Supply Chain Protection 353

SA-13. Trustworthiness 354

SA-14. Critical Analysis 354

SA-15 Development Process, Standards, and Tools 354

SA-16 Developer-Provided Training 359

SA-17 Developer Security Architecture and Design 359

SA-18 Tamper resistance and detection 365

SA-19 Component Authenticity 365

SA-20 Customized Development of Critical Components 365

SA-21 Developer Screening 366

SA-22 Unsupported System Components 366

SA-23 Specialization 367

2.18 System and Communications Protection Requirements 368

SecA.Requirements.docx ix 03/09/22

SC-1. System and Communications Protection Policy and Procedures 368

SC-2. Application Partitioning 369

SC-3. Security Function Isolation 370

SC-4. Information in Shared Resources 372

SC-5. Denial of Service Protection 373

SC-6. Resource Availability 375

SC-7. Boundary Protection 375

SC-8. Transmission Confidentiality and Integrity 386

SC-9. Transmission Confidentiality 388

SC-10. Network Disconnect 388

SC-11. Trusted Path 389

SC-12. Cryptographic Key Establishment and Management 390

SC-13. Use of Cryptography 392

SC-14. Public Access Protections 392

SC-15. Collaborative Computing Devices 392

SC-16. Transmission of Security Attributes 394

SC-17. Public Key Infrastructure Certificates 395

SC-18. Mobile Code 396

SC-19. Voice Over Internet Protocol 398

SC-20. Secure Name / Address Resolution Service (Authoritative Source) 398

SC-21. Secure Name / Address Resolution Service (Recursive or Caching Resolver) 399

SC-22. Architecture and Provisioning for Name / Address Resolution Service 399

SC-23. Session Authenticity 400

SC-24. Fail In Known State 401

SC-25. Thin Nodes 401

SC-26. Decoys 402

SC-27. Operating System-Independent Applications 402

SC-28. Protection of Information at Rest 403

SC-29. Heterogeneity 404

SC-30. Concealment and Misdirection 405

SC-31. Covert Channel Analysis 407

SC-32. System Partitioning 408

SC-33. Transmission Preparation Integrity 409

SC-34. Non-Modifiable Executable Programs 409

SC-35 External Malicious Code Identification 410

SC-36 Distributed Processing and Storage 410

SC-37 Out-Of-Band Channels 412

SC-38 Operations Security 412

SC-39 Process Isolation 413

SC-40 Wireless Link Protection 414

SC-41 Port and I/O Device Access 416

SC-42 Sensor Capability and Data 416

SC-43 Usage Restrictions 418

SC-44 Detonation Chambers 419

SC-45 System Time Synchronization 419

SecA.Requirements.docx x 03/09/22

SC-46 Cross Domain Policy Enforcement 421

SC-47 Alternate Communications Paths 421

SC-48 Sensor Relocation 422

SC-49 Hardware-Enforced Separation and Policy Enforcement 422

SC-50 Software-Enforced Separation and Policy Enforcement 423

SC-51 Hardware-Based Protection 423

2.19 System and Information Integrity Requirements 424

SI-1. System and Information Integrity Policy and Procedures 424

SI-2. Flaw Remediation 425

SI-3. Malicious Code Protection 427

SI-4. System Monitoring 430

SI-5. Security Alerts, Advisories, and Directives 440

SI-6. Security Function Verification 441

SI-7. Software, Firmware and Information Integrity 442

SI-8. Spam Protection 446

SI-9. Information Input Restrictions 447

SI-10. Information Input Validation 447

SI-11. Error Handling 450

SI-12. Information Handling and Retention 450

SI-13. Predictable Failure Prevention 452

SI-14 Non-Persistence 454

SI-15 Information Output Filtering 456

SI-16 Memory Protection 456

SI-17 Fail-Safe Procedures 456

SI-18 Personally Identifiable Information Quality Operations 457

SI-19 De-identification 460

SI-20 Tainting 463

SI-21 Information Refresh 464

SI-22 Information Diversity 464

SI-23 Information Fragmentation 465

2.20 Supply Chain Risk Management 466

SR-1 Policy and Procedures 466

SR-2 Supply Chain Risk Management Plan 467

SR-3 Supply Chain Controls and Processes 469

SR-4 Provenance 470

SR-5 Acquisition Strategies, Tools, and Methods 473

SR-6 Supplier Assessments and Reviews 475

SR-7 Supply Chain Operations Security 476

SR-8 Notification Agreements 476

SR-9 Tamper Resistance and Detection 477

SR-10 Inspection of Systems or Components 478

SR-11 Component Authenticity 478

SR-12 Component Disposal 479

SecA.Requirements.docx 1 03/09/22

1. Introduction

As expressed in the IT Security Domain Model, NARA has the following three major sources of

IT security requirements:

● Needs for IT Security determined by NARA’s risk profile and based upon an analysis of

NARA’s business and IT risk assessments;

● Needs for IT security specifically mandated by or implied by Federal laws, directives and guidelines; and

● Needs for IT security specifically stated by or implied by NARA’s IT Security Policies.

This release of NARA’s IT Security Architecture documents security requirements mandated by

FIPS 200, Minimum Security Requirements for Federal Systems. The security controls expressed in this publication represents NISTS’s specification for minimum security requirements that must be met by Federal Agencies. The NIST 800 Series of computer security guidelines are published under the authority of the Federal Information Security Management Act (FISMA) of

2002. The security controls specified by NIST Special Publication 800-53 are intended to safeguard the confidentiality, integrity and availability of information as required under FISMA.

The use of these controls is mandatory for federal systems in accordance with Office of

Management and Budget (OMB) Circular A-130 (OMB A-130) and the provisions of the Federal

Information Security Modernization Act (FISMA), which requires the implementation of minimum controls to protect federal information and systems. This document identifies the security and privacy controls needed to manage risk and to satisfy the security and privacy requirements in FISMA, the Privacy Act of 1974 (PRIVACT), OMB policies (e.g., OMB A-

130), and designated Federal Information Processing Standards (FIPS), among others. It accomplishes this objective by providing a comprehensive and flexible catalog of security and privacy controls to meet NARA’s current and future protection needs based on changing threats, vulnerabilities, requirements, and technologies.

It is important to recognize OMB and NIST documents referenced in the IT Security

Architecture are guidance documents or templates to be used by agencies to develop their own security architectures. They are not final products tailored for NARA and should not be directly utilized by NARA developers.

For example, NIST Special Publication 800-53 describes the following access controls on unsuccessful login attempts:

“The system enforces a limit of [Assignment: organization-defined number] consecutive invalid access attempts by a user during a [Assignment: organization-defined time period] time period; and automatically [Selection: locks the account/node for an [Assignment: organization-

SecA.Requirements.docx 2 03/09/22 defined time period], delays next login prompt according to [Assignment: organization-denied delay algorithm.]] when the maximum number of unsuccessful attempts is exceeded.”

The IT Security Architecture uses the above criteria to develop NARA’s own control objectives.

These are then used to develop policies, requirements, mechanisms, and specifications used to implement the control. This provides a single, consistent source of NARA-wide policy and prevents each organization from developing individual interpretations of Federal guidance.

NARA system developers should utilize NARA’s IT Security Architecture for their security requirements. NARA system developers should not independently develop their own security requirements based on their individual interpretations of federal guidance.

For reference purposes, all of NARA’s tailoring to the NIST controls are maintained in square brackets (e.g., “[“ and “]”).

2. NARA IT Security Requirements

The IT Security Requirements are derived from the controls identified in NIST Special

Publication (SP) 800-53 for unclassified systems and classified systems. The requirements for classified systems were formerly derived from Director of Central Intelligence Directive (DCID)

6/3, but have since been merged into the Rev. 4 version of the NIST SP 800-53. NIST SP 800-

53 represents the specific requirements that must be met to implement the control to the required level for confidentiality, integrity, and availability.

Most of the requirements apply to all of NARA or to all systems. These will be stated as

“NARA shall…” or “Each system shall…” as appropriate. Other requirements only apply to systems at a moderate or high level of confidentiality, integrity or availability. These requirements will be qualified as being “For high availability systems” or “For moderate integrity systems” or something similar. A few of the requirements are not mandated for any particular system, but can be implemented where data is “deemed by the NARA System Owner to require additional protection” to enhance a particular security control. While no system is required to enhance security beyond the minimum required levels, if stronger security is desired, it may be enhanced using these controls and control enhancements. Additional requirements that apply to classified systems will be noted as such. NARA systems designated as High Value

Assets (HVA) must implement the NARA High Value Asset (HVA) Security Requirements

Overlay. Systems determined to have PII data must implement the NARA Personally Identifiable

Information (PII) Security Requirements Overlay.

2.1 Access Control Requirements

AC-1. Access Control Policy and Procedures

Privacy LOW AC-1 MOD AC-1 HIGH AC-1

SecA.Requirements.docx 3 03/09/22

AC-1. For all data, the NARA Office of Information Services (I) shall:

AC-1a. Develop, document and disseminate, to NARA personnel:

1. A NARA wide access control policy that:

(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among NARA entities, and compliance; and

(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and

2. Procedures to facilitate the implementation of the access control policy and associated access controls; and

AC-1b. The NARA Chief Information Security Officer (CISO) manages the development, documentation, and dissemination of the access control policy and procedures; and

AC-1c. Review and update the current:

1. Access control policy [at least annually] and following an assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and

2. Access control procedures [at least annually] and following an assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines.

Discussion: Access control policy and procedures address the controls in the AC family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of access control policy and procedures.

Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies reflecting the complex nature of organizations.

Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure.

Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to access control policy and

SecA.Requirements.docx 4 03/09/22 procedures include assessment or audit findings, security incidents or breaches, or changes in laws, executive orders, directives, regulations, policies, standards, and guidelines.

Simply restating controls does not constitute an organizational policy or procedure.

Related Controls: IA-1, PM-9, PM-24, PS-8, SI-12.

Control Enhancements: None.

References: [OMB A-130], [SP 800-12], [SP 800-30], [SP 800-39], [SP 800-100], [IR

7874].

AC-2. Account Management

LOW AC-2 MOD AC-2 (1) (2) (3) (4) (5)

(13)

HIGH AC-2 (1) (2) (3) (4) (5) (11) (12) (13)

AC-2. For all data, the NARA System Owner shall:

AC-2a. Define and document the types of accounts allowed and specifically prohibited for use within the system (i.e., individual, group, system, application, guest/anonymous, and temporary);

AC-2b. Assign account managers;

AC-2c. Require [SSP-defined prerequisites and criteria] for group and role membership;

AC-2d. Specify

1. authorized users of the system,

2. group and role membership, and

3. access authorizations (i.e., privileges) and other [SSP-defined] attributes (as required) for each account;

AC-2e. Require approvals by system owner or the system's designated approving official for requests to create accounts;

AC-2f. Create, enable, modify, disable, and remove system accounts in accordance with NARA

804, Information Technology (IT) Systems Security;

AC-2g. Monitor the use of accounts;

AC-2h. Notify account managers, system ISSO and NARA ISM within two weeks:

1. When accounts are no longer required;

2. When users are terminated or transferred; and

3. When individual system usage or need-to-know changes;

SecA.Requirements.docx 5 03/09/22

AC-2i. Authorize access to the system based on:

1. A valid access authorization;

2. Intended system usage; and

3. Other attributes as required by the system functions;

AC-2j. Review accounts compliance with account management requirements [monthly for privileged users; and at least annually for all others].

AC-2k. Establish a process for reissuing shared/group account credentials (if deployed) when individuals are removed from the group.

AC-2l. Align account management processes with personnel termination and transfer processes.

Discussion: Examples of system account types include individual, shared, group, system, guest, anonymous, emergency, developer, temporary, and service. Identification of authorized system users and the specification of access privileges reflect the requirements in other controls in the security plan. Users requiring administrative privileges on system accounts receive additional scrutiny by organizational personnel responsible for approving such accounts and privileged access, including system owner, mission or business owner, senior agency information security officer, or senior agency official for privacy. Types of accounts that organizations may wish to prohibit due to increased risk include shared, group, emergency, anonymous, temporary, and guest accounts.

Where access involves personally identifiable information, security programs collaborate with the senior agency official for privacy to establish the specific conditions for group and role membership; specify authorized users, group and role membership, and access authorizations for each account; and create, adjust, or remove system accounts in accordance with organizational policies. Policies can include such information as account expiration dates or other factors that trigger the disabling of accounts. Organizations may choose to define access privileges or other attributes by account, type of account, or a combination of the two. Examples of other attributes required for authorizing access include restrictions on time of day, day of week, and point of origin. In defining other system account attributes, organizations consider system-related requirements and mission/business requirements. Failure to consider these factors could affect system availability.

Temporary and emergency accounts are intended for short-term use. Organizations establish temporary accounts as part of normal account activation procedures when there is a need for short-term accounts without the demand for immediacy in account activation. Organizations establish emergency accounts in response to crisis situations and with the need for rapid account activation. Therefore, emergency account activation may bypass normal account authorization

SecA.Requirements.docx 6 03/09/22 processes. Emergency and temporary accounts are not to be confused with infrequently used accounts, including local logon accounts used for special tasks or when network resources are unavailable (may also be known as accounts of last resort). Such accounts remain available and are not subject to automatic disabling or removal dates. Conditions for disabling or deactivating accounts include when shared/group, emergency, or temporary accounts are no longer required and when individuals are transferred or terminated. Changing shared/group authenticators when members leave the group is intended to ensure that former group members do not retain access to the shared or group account. Some types of system accounts may require specialized training.

Related Controls: AC-3, AC-5, AC-6, AC-17, AC-18, AC-20, AC-24, AU-2, AU-12, CM-5, IA-2, IA-4, IA-5, IA-8, MA-3, MA-5, PE-2, PL-4, PS-2, PS-4, PS-5, PS-7, PT-2, PT-3, SC-7, SC-12, SC-13, SC-37.AC-2(1) AUTOMATED SYSTEM ACCOUNT MANAGEMENT. For data requiring moderate or high confidentiality, the NARA System Owner shall employ automated mechanisms to support the management of system accounts.

Discussion: Automated system account management includes using automated mechanisms to create, enable, modify, disable, and remove accounts; notify account managers when an account is created, enabled, modified, disabled, or removed, or when users are terminated or transferred;

monitor system account usage; and report atypical system account usage. Automated mechanisms can include internal system functions and email, telephonic, and text messaging notifications.

AC-2(2) AUTOMATED TEMPORARY AND EMERGENCY ACCOUNT MANAGEMENT.

For data requiring moderate or high confidentiality, the system shall automatically disable temporary and emergency accounts after [a period not to exceed 15 days for unclassified systems or 72 hours for classified systems].

Discussion: Management of temporary and emergency accounts includes the removal or disabling of such accounts automatically after a predefined time period rather than at the convenience of the system administrator. Automatic removal or disabling of accounts provides a more consistent implementation.

Related Controls: None.

AC-2(3) DISABLE ACCOUNTS. For data requiring moderate or high confidentiality, the system shall disable accounts within [a period not to exceed 7 days for unclassified systems or 2 days for classified systems] when the accounts:

(a) Have expired;

(b) Are no longer associated with a user or individual;

(c) Are in violation of organizational policy; or

SecA.Requirements.docx 7 03/09/22

(d) Have been inactive for [a period not to exceed 90 days for unclassified systems or

30 days for classified systems].

Discussion: Disabling expired, inactive, or otherwise anomalous accounts supports the concepts of least privilege and least functionality which reduce the attack surface of the system.

Related Controls: None.

AC-2(4) AUTOMATED AUDIT ACTIONS. For data requiring moderate or high confidentiality, the system shall automatically audit account creation, modification, disabling, and removal actions and shall notify, as required, appropriate individuals.

Discussion: Account management audit records are defined in accordance with AU-2 and reviewed, analyzed, and reported in accordance with AU-6.

Related Controls: AU-2, AU-6.

AC-2 (5) INACTIVITY LOGOUT. For data requiring moderate and high confidentiality, the

NARA System Owner shall:

● Require that users log out when [15 minutes of inactivity have occurred]

● Determine normal time-of-day and duration usage for system accounts;

● Monitor for atypical usage of system accounts; and

● Report atypical usage to designated NARA officials.

Discussion: Inactivity logout is behavior- or policy-based and requires users to take physical action to log out when they are expecting inactivity longer than the defined period.

Automatic enforcement of inactivity logout is addressed by AC-11.

Related Controls: AC-11.

AC-2(6) DYNAMIC PRIVILEGE MANAGEMENT. For data deemed by the NARA

System Owner to require this additional confidentiality protection, the system shall implement [an SSP defined dynamic privilege management capabilities].

Discussion: In contrast to access control approaches that employ static accounts and predefined user privileges, dynamic access control approaches rely on runtime access control decisions facilitated by dynamic privilege management, such as attribute-based access control. While user identities remain relatively constant over time, user privileges typically change more frequently based on ongoing mission or business requirements and the operational needs of organizations. An example of dynamic privilege management is the immediate revocation of privileges from users as opposed to requiring that users terminate and restart their sessions to reflect changes in privileges.

Dynamic privilege management can also include mechanisms that change user

SecA.Requirements.docx 8 03/09/22 privileges based on dynamic rules as opposed to editing specific user profiles. Examples include automatic adjustments of user privileges if they are operating out of their normal work times, if their job function or assignment changes, or if systems are under duress or in emergency situations. Dynamic privilege management includes the effects of privilege changes, for example, when there are changes to encryption keys used for communications.

Related Controls: AC-16.

AC-2(7) PRIVILEGED USER ACCOUNTS. For data deemed by the NARA System

Owner to require this additional confidentiality protection, the NARA System Owner shall:

(a) Establish and administer privileged user accounts in accordance with a role-based access scheme that organizes system and network privileges into roles;

(b) Monitor privileged role assignments;

(c) Monitor changes to roles or attributes; and

(d) Revoke access when privileged role or attribute assignments are no longer appropriate.

Discussion: Privileged roles are organization-defined roles assigned to individuals that allow those individuals to perform certain security-relevant functions that ordinary users are not authorized to perform. Privileged roles include key management, account management, database administration, system and network administration, and web administration. A role-based access scheme organizes permitted system access and privileges into roles. In contrast, an attribute-based access scheme specifies allowed system access and privileges based on attributes.

Related Controls: None.

AC-2(8) DYNAMIC ACCOUNT MANAGEMENT. For data deemed by the NARA System

Owner to require this additional confidentiality protection, the system shall create, activate, manage, and deactivate [SSP-defined system accounts] dynamically.

Discussion: Approaches for dynamically creating, activating, managing, and deactivating system accounts rely on automatically provisioning the accounts at runtime for entities that were previously unknown. Organizations plan for the dynamic management, creation, activation, and deactivation of system accounts by establishing trust relationships, business rules, and mechanisms with appropriate authorities to validate related authorizations and privileges.

Related Controls: AC-16.

AC-2(9) RESTRICTIONS ON USE OF SHARED AND GROUP ACCOUNTS. For data deemed by the NARA System Owner to require this additional confidentiality protection, NARA shall only permit the use of shared/group accounts that meet [SSP-defined conditions for establishing shared/group accounts].

SecA.Requirements.docx 9 03/09/22

Discussion: Before permitting the use of shared or group accounts, organizations consider the increased risk due to the lack of accountability with such accounts.

Related Controls: None.

AC-2(10) [Withdrawn: Incorporated in AC-2k].

AC-2(11) USAGE CONDITIONS. For data requiring high confidentiality, the system shall enforce [SSP-defined circumstances and/or usage conditions] for [SSP-defined system accounts].

Discussion: Specifying and enforcing usage conditions helps to enforce the principle of least privilege, increase user accountability, and enable effective account monitoring. Account monitoring includes alerts generated if the account is used in violation of organizational parameters. Organizations can describe specific conditions or circumstances under which system accounts can be used, such as by restricting usage to certain days of the week, time of day, or specific durations of time.

Related Controls: None.

AC-2(12) ACCOUNT MONITORING FOR ATYPICAL USAGE. For data requiring high confidentiality, the NARA System Owner shall:

(a) Monitor system accounts for [NARA-defined atypical use]; and

(b) Reports atypical usage of system accounts to system operators, ISSO and IS.

Discussion: Atypical usage includes accessing systems at certain times of the day or from locations that are not consistent with the normal usage patterns of individuals. Monitoring for atypical usage may reveal rogue behavior by individuals or an attack in progress. Account monitoring may inadvertently create privacy risks since data collected to identify atypical usage may reveal previously unknown information about the behavior of individuals.

Organizations assess and document privacy risks from monitoring accounts for atypical usage in their privacy impact assessment and make determinations that are in alignment with their privacy program plan.

Related Controls: AU-6, AU-7, CA-7, IR-8, SI-4.

AC-2(13) DISABLE ACCOUNTS FOR HIGH-RISK INDIVIDUALS. For data requiring moderate and high confidentiality, the NARA System Owner shall disable accounts of individuals within [SSP-defined time period]of discovery of [SSP defined risks].

Discussion: Users who pose a significant security and/or privacy risk include individuals for whom reliable evidence indicates either the intention to use authorized access to systems to cause

SecA.Requirements.docx 10 03/09/22 harm or through whom adversaries will cause harm. Such harm includes adverse impacts to organizational operations, organizational assets, individuals, other organizations, or the Nation.

Close coordination among system administrators, legal staff, human resource managers, and authorizing officials is essential when disabling system accounts for high-risk individuals.

Related Controls: AU-6, SI-4.

AC-3. Access Enforcement

AC-3(14)

Privacy

LOW AC-3 MOD AC-3 HIGH AC-3

AC-3. For all data, the system shall enforce approved authorizations for logical access to the system and system resources in accordance with NARA applicable access control policies.

● The NARAnet GSS shall provide multifactor access control as a common control for remote and local access to the network. The authentication capability shall be available to externally hosted systems, which restrict access to NARA account holders.

● Multifactor access mechanisms shall include credentials from HSPD 12 compliant PIV cards.

● Users with elevated security privileges shall access the system using a multifactor authentication mechanism that complies with applicable federal directives and NARA policy.

● Minor applications receive access enforcement as a service from the General Support

System of which they are a part.

● If the security plan of a minor application requires auditing of the actions of users with elevated security privileges, those users shall authenticate using multi-factor mechanisms.

● Minor applications which contain PII enforce assigned authorizations for controlling access to the system in accordance with applicable policy

Discussion: Access control policies control access between active entities or subjects (i.e., users or processes acting on behalf of users) and passive entities or objects (i.e., devices, files, records, domains) in organizational systems. In addition to enforcing authorized access at the system level and recognizing that systems can host many applications and services in support of mission and business functions, access enforcement mechanisms can also be employed at the application and service level to provide increased information security and privacy. In contrast to logical access controls that are implemented within the system, physical access controls are addressed by the controls in the Physical and Environmental Protection (PE) family.

SecA.Requirements.docx 11 03/09/22

Related Controls: AC-2, AC-4, AC-5, AC-6, AC-16, AC-17, AC-18, AC-19, AC-20, AC-21, AC-22, AC- 24, AC-25, AT-2, AT-3, AU-9, CA-9, CM-5, CM-11, IA-2, IA-5, IA-6, IA-7, IA-

11, MA-3, MA-4, MA-5, MP-4, PM-2, PS-3, PT-2, PT-3, SA-17, SC-2, SC-3, SC-4, SC-12, SC-

13, SC-28, SC-31, SC-34, SI-4, SI-8.

AC-3(1) [Withdrawn: Incorporated into AC-6].

AC-3(2) DUAL AUTHORIZATION. For data deemed by the NARA System Owner to require this additional confidentiality protection, the system shall enforce dual authorization for [SSP defined privileged commands and/or other SSP-defined actions].

Discussion: Dual authorization, also known as two-person control, reduces risk related to insider threats. Dual authorization mechanisms require the approval of two authorized individuals to execute. To reduce the risk of collusion, organizations consider rotating dual authorization duties. Organizations consider the risk associated with implementing dual authorization mechanisms when immediate responses are necessary to ensure public and environmental safety.

Related Controls: CP-9, MP-6.

AC-3(3) MANDATORY ACCESS CONTROL. For data deemed by the NARA System Owner to require this additional confidentiality protection, the system shall enforce [SSP-defined mandatory access control policy] over the set of covered subjects and objects specified in the policy, and where the policy:

(a) The policy is uniformly enforced across all subjects and objects within the boundary of the system;

(b) A subject that has been granted access to information is constrained from doing any of the following;

(1) Passing the information to unauthorized subjects or objects;

(2) Granting its privileges to other subjects;

(3) Changing one or more security attributes (specified in the SSP-defined policy) on subjects, objects, the system, or system components;

(4) Choosing the security attributes and attribute values (specified in the SSP-defined policy) to be associated with newly created or modified objects; or

(5) Changing the rules governing access control; and

SecA.Requirements.docx 12 03/09/22

(c) Specifies that [SSP-defined subjects] may explicitly be granted [SSP-defined privileges (i.e., they are trusted subjects)] such that they are not limited by any defined subset (or all) of the above constraints.

Discussion: Mandatory access control is a type of nondiscretionary access control. Mandatory access control policies constrain what actions subjects can take with information obtained from objects for which they have already been granted access. This prevents the subjects from passing the information to unauthorized subjects and objects. Mandatory access control policies constrain actions that subjects can take with respect to the propagation of access control privileges; that is, a subject with a privilege cannot pass that privilege to other subjects. The policy is uniformly enforced over all subjects and objects to which the system has control. Otherwise, the access control policy can be circumvented. This enforcement is provided by an implementation that meets the reference monitor concept as described in AC-25. The policy is bounded by the system

(i.e., once the information is passed outside of the control of the system, additional means may be required to ensure that the constraints on the information remain in effect).

The trusted subjects described above are granted privileges consistent with the concept of least privilege (see AC-6). Trusted subjects are only given the minimum privileges necessary for satisfying organizational mission/business needs relative to the above policy. The control is most applicable when there is a mandate that establishes a policy regarding access to controlled unclassified information or classified information and some users of the system are not authorized access to all such information resident in the system. Mandatory access control can operate in conjunction with discretionary access control as described in AC-3(4). A subject constrained in its operation by mandatory access control policies can still operate under the less rigorous constraints of AC-3(4), but mandatory access control policies take precedence over the less rigorous constraints of AC-3(4). For example, while a mandatory access control policy imposes a constraint that prevents a subject from passing information to another subject operating at a different impact or classification level, AC-3(4) permits the subject to pass the information to any other subject with the same impact or classification level as the subject.

Examples of mandatory access control policies include the Bell-LaPadula policy to protect confidentiality of information and the Biba policy to protect the integrity of information.

Related Controls: SC-7.

AC-3(4) DISCRETIONARY ACCESS CONTROL. For data deemed by the NARA System

Owner to require this additional confidentiality protection, the system shall enforce a [SSP-defined Discretionary Access Control (DAC) policy] over the set of covered subjects and objects specified in the policy, and where the policy specifies that a subject that has been granted access to information can do one or more of the following:

(a) Pass the information to any other subjects or objects;

SecA.Requirements.docx 13 03/09/22

(b) Grant its privileges to other subjects;

(c) Change security attributes on subjects, objects, the system, or the system’s components;

(d) Choose the security attributes to be associated with newly created or revised objects;

or

(e) Change the rules governing access control.

Discussion: When discretionary access control policies are implemented, subjects are not constrained with regard to what actions they can take with information for which they have already been granted access. Thus, subjects that have been granted access to information are not prevented from passing the information to other subjects or objects (i.e., subjects have the discretion to pass). Discretionary access control can operate in conjunction with mandatory access control as described in AC-3(3) and AC-3(15). A subject that is constrained in its operation by mandatory access control policies can still operate under the less rigorous constraints of discretionary access control. Therefore, while AC-3(3) imposes constraints that prevent a subject from passing information to another subject operating at a different impact or classification level, AC-3(4) permits the subject to pass the information to any subject at the same impact or classification level. The policy is bounded by the system. Once the information is passed outside of system control, additional means may be required to ensure that the constraints remain in effect. While traditional definitions of discretionary access control require identity-based access control, that limitation is not required for this particular use of discretionary access control.

Related Controls: None

AC-3(5) SECURITY-RELEVANT INFORMATION. For data deemed by the NARA System

Owner to require this additional confidentiality protection, the system shall prevent access to

[SSP defined Information] except during secure, non-operable system states.

Discussion: Security-relevant information is information within systems that can potentially impact the operation of security functions or the provision of security services in a manner that could result in failure to enforce system security and privacy policies or maintain the separation of code and data. Security-relevant information includes access control lists, filtering rules for routers or firewalls, configuration parameters for security services, and cryptographic key management information. Secure, non-operable system states include the times in which systems are not performing mission or business-related processing, such as when the system is offline for maintenance, boot-up, troubleshooting, or shut down.

Related Controls: CM-6, SC-39.

SecA.Requirements.docx 14 03/09/22

AC-3(6) [Withdrawn: Incorporated into MP-4 and SC-28].

AC-3 (7) ROLE-BASED ACCESS CONTROL. For data deemed by the NARA System Owner to require this additional confidentiality protection, the system shall enforce a role-based access control policy over defined subjects and objects and controls access based upon [SSP-defined roles and users authorized to assume such roles].

Discussion: Role-based access control (RBAC) is an access control policy that enforces access to objects and system functions based on the defined role (i.e., job function) of the subject.

Organizations can create specific roles based on job functions and the authorizations (i.e., privileges) to perform needed operations on the systems associated with the organization-defined roles. When users are assigned to specific roles, they inherit the authorizations or privileges defined for those roles. RBAC simplifies privilege administration for organizations because privileges are not assigned directly to every user (which can be a large number of individuals) but are instead acquired through role assignments. RBAC can also increase privacy and security risk if individuals assigned to a role are given access to information beyond what they need to support organizational missions or business functions. RBAC can be implemented as a mandatory or discretionary form of access control. For organizations implementing RBAC with mandatory access controls, the requirements in AC-3(3) define the scope of the subjects and objects covered by the policy.

Related Controls: None.

AC-3 (8) REVOCATION OF ACCESS AUTHORIZATIONS. For data deemed by the NARA

System Owner to require this additional confidentiality protection, the system shall enforce the revocation of access authorizations resulting from changes to the security attributes of subjects and objects based on [SSP-defined rules governing the timing of revocations of access authorizations].

Discussion: Revocation of access rules may differ based on the types of access revoked. For example, if a subject (i.e., user or process acting on behalf of a user) is removed from a group, access may not be revoked until the next time the object is opened or the next time the subject attempts to access the object. Revocation based on changes to security labels may take effect immediately.