Appendix 2 - NARA_IT_Security_Requirements v7.1.pdf

NARA

IT Security Requirements

NATIONAL ARCHIVES AND RECORDS

ADMINISTRATION

November 22, 2021

Version 7.1

Enterprise Architecture IT Security Requirement Version 7.1

SecA.Requirements.docx 1 11/22/21

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 2 11/22/21

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

SecA.Requirements.docx 3 11/22/21

Table of Contents

1. Introduction 11

2. NARA IT Security Requirements 12

2.1 Access Control Requirements 13

AC-1. Access Control Policy and Procedures 13 AC-2. Account Management 14

AC-3. Access Enforcement 20

AC-4. Information Flow Enforcement 28

AC-5. Separation of Duties 39 AC-6. Least Privilege 39

AC-7. Unsuccessful Login Attempts 43

AC-8. System Use Notification 45 AC-9. Previous Logon (Access) Notification 46

AC-10. Concurrent Session Control 47

AC-11. Session Lock 47

AC-12. Session Termination 48 AC-13. Supervision and Review — Access Control 49

AC-14. Permitted Actions without Identification or Authentication 49

AC-15. Automated Marking 50 AC-16. Security Attributes 50

AC-17. Remote Access 55

AC-18. Wireless Access 58

AC-19. Access Control for Mobile Devices 60 AC-20. Use of External Systems 62

AC-21. Information Sharing 65

AC-22. Publicly Accessible Content 66 AC-23. Data Mining Protection 67

AC-24 ACCESS CONTROL DECISIONS 68

AC-25 REFERENCE MONITOR 69

2.2 Awareness and Training Requirements 70

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

AT-2. Security Awareness Training 71

AT-3. Role-Based Security Training 75 AT-4. Security Training Records 77

AT-5. Contacts with Security Groups and Associations 78

AT-6 Training Feedback. 78

2.3 Audit and Accountability Requirements 78

AU-1. Audit and Accountability Policy and Procedures 78

AU-2. Auditable Events 79

AU-3. Content of Audit Records 82 AU-4. Audit Storage Capacity 83

SecA.Requirements.docx 4 11/22/21

AU-5. Response to Audit Processing Failures 84

AU-6. Audit Review, Analysis, and Reporting 86 AU-7. Audit Reduction and Report Generation 89

AU-8. Time Stamps 90

AU-9. Protection of Audit Information 91

AU-10. Non-Repudiation 93 AU-11. Audit Record Retention 95

AU-12. Audit Generation 96

AU-13. Monitoring for Information Disclosure 98 AU-14. Session Audit 99

AU-15. Alternate Audit Capability 100

AU-16. Cross-Organizational Auditing 100

2.4 Assessment and Authorization Requirements 102

CA-1. Assessment and Authorization Policies and Procedures 102

CA-2. Control Assessments 103

CA-3. Information Exchange 107 CA-4. Security Certification 109

CA-5. Plan of Action and Milestones 109

CA-6. Authorization 110

CA-7. Continuous Monitoring 112 CA-8 Penetration Testing 115

CA-9 Internal System Connections 117

2.5 Configuration Management Requirements 118

CM-1. Configuration Management Policy and Procedures 118

CM-2. Baseline Configuration 120

CM-3. Configuration Change Control 122 CM-4. Security Impact Analysis 126

CM-5. Access Restrictions for Change 127

CM-6. Configuration Settings 129

CM-7. Least Functionality 130 CM-8. System Component Inventory 134

CM-9. Configuration Management Plan 138

CM-10 Software Usage Restrictions 140 CM-11 User-Installed Software 141

CM-12 Information Location 142

CM-13 Data Action Mapping 143

CM-14 Signed Components 143

2.6 Contingency Planning Requirements 144

CP-1. Contingency Planning Policy and Procedures 144

CP-2. Contingency Plan 145 CP-3. Contingency Training 149

CP-4. Contingency Plan Testing 150

CP-5. Contingency Plan Update 152

SecA.Requirements.docx 5 11/22/21

CP-6. Alternate Storage Site 152

CP-7. Alternate Processing Site 154 CP-8. Telecommunications Services 156

CP-9. System Backup 159

CP-10. System Recovery and Reconstitution 162

CP-11 Alternate Communications Protocols 163 CP-12 Safe Mode 163

CP-13 Alternative Security Mechanisms 164

2.7 Identification and Authentication Requirements 164

IA-1. Identification and Authentication Policy and Procedures 164

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

IA-3. Device Identification and Authentication 170 IA-4. Identifier Management 171

IA-5. Authenticator Management 174

IA-6. Authenticator Feedback 181

IA-7. Cryptographic Module Authentication 182 IA-8. Identification and Authentication (Non-NARA Users) 182

IA-9 Service Identification and Authentication 184

IA-10 Adaptive Identification and Authentication 185

IA-11 Re-Authentication 185 IA-12 Identity Proofing 186

2.8 Incident Response Requirements 188

IR-1. Incident Response Policy and Procedures 188 IR-2. Incident Response Training 190

IR-3. Incident Response Testing 191

IR-4. Incident Handling 193 IR-5. Incident Monitoring 199

IR-6. Incident Reporting 200

IR-7. Incident Response Assistance 201

IR-8. Incident Response Plan 202 IR-9. Information Spillage Response 204

IR-10. Integrated Information Security Analysis Team 205

2.9 Maintenance Requirements 206

MA-1. System Maintenance Policy and Procedures 206

MA-2. Controlled Maintenance 207

MA-3. Maintenance Tools 208 MA-4. Non-Local Maintenance 210

MA-5. Maintenance Personnel 213

MA-6. Timely Maintenance 216

MA-7 Field Maintenance 217

2.10 Media Protection Requirements 218

MP-1. Media Protection Policy and Procedures 218

MP-2. Media Access 219

SecA.Requirements.docx 6 11/22/21

MP-3. Media Marking 220

MP-4. Media Storage 220 MP-5. Media Transport 221

MP-6. Media Sanitization 222

MP-7 Media Use 225

MP-8 Media Downgrading 226

2.11 Physical and Environmental Protection Requirements 228

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

PE-2. Physical Access Authorizations 229 PE-3. Physical Access Control 230

PE-4. Access Control for Transmission Medium 234

PE-5. Access Control for Output Devices 234 PE-6. Monitoring Physical Access 235

PE-7. Visitor Control 237

PE-8. Access Records 237

PE-9. Power Equipment and Power Cabling 238 PE-10. Emergency Shutoff 239

PE-11. Emergency Power 239

PE-12. Emergency Lighting 240

PE-13. Fire Protection 241 PE-14. Temperature and Humidity Controls 242

PE-15. Water Damage Protection 243

PE-16. Delivery and Removal 244 PE-17. Alternate Work Site 244

PE-18. Location of System Components 245

PE-19. Information Leakage 245

PE-20. Asset Monitoring and Tracking 246 PE-21. Electromagnetic Pulse Protection 246

PE-22. Component Marking 247

PE-23. Facility Location 248

2.12 Security Planning Requirements 248

PL-1. Security Planning Policy and Procedures 248

PL-2. System Security Plan 249 PL-3. System Security Plan Update 252

PL-4. Rules of Behavior 252

PL-5. Privacy Impact Assessment 253

PL-6. Security-Related Activity Planning 253 PL-7 Security Concept of Operations 253

PL-8 Security and Privacy Architecture 254

PL-9 Central Management 257 PL-10 Baseline Selection 258

PL-11 Baseline Tailoring 258

2.13 Security Program Requirements 259

SecA.Requirements.docx 7 11/22/21

PM-1. Information Security Program Plan 259

PM-2. Senior Information Security Officer 261 PM-3. Information Security Resources 261

PM-4. Plan of Action and Milestones Process 262

PM-5. System Inventory 263

PM-6. Information Security Measures of Performance 263 PM-7. Enterprise Architecture 264

PM-8. Critical Infrastructure Plan 265

PM-9. Risk Management Strategy 265 PM-10. Security Authorization Process 266

PM-11. Mission/Business Process Definition 267

PM-12 Insider Threat Program 268

PM-13 Information Security Workforce 269 PM-14 Testing, Training, and Monitoring 269

PM-15 Contacts with Security Groups and Associations 270

PM-16 Threat Awareness Program 271 PM-17 Protecting Controlled Unclassified Information on External Systems 272

PM-18 Privacy Program Plan 272

PM-19 Privacy Program Leadership Role 274

PM-20 Dissemination of Privacy Program Information 274 PM-21 Accounting of Disclosures 275

PM-22 Personally Identifiable Information Quality Management 276

PM-23 Data Governance Body 278

PM-24 Data Integrity Board 278 PM-25 Minimization of Personally Identifiable Information Used in Testing, Training and Research 279

PM-26 Complaint Management 280

PM-27 Privacy Reporting 280 PM-28 Risk Framing 281

PM-29 Risk Management Program Leadership Roles 282

PM-30 Supply Chain Risk Management Strategy 282

PM-31 Continuous Monitoring Strategy 284 PM-32 Purposing 285

2.14 Personnel Security Requirements 285

PS-1. Personnel Security Policy and Procedures 285 PS-2. Position Categorization 287

PS-3. Personnel Screening 287

PS-4. Personnel Termination 289 PS-5. Personnel Transfer 290

PS-6. Access Agreements 291

PS-7. External Personnel Security 293

PS-8. Personnel Sanctions 293 PS-9. Position Descriptions 294

2.15 Personally Identifiable Information Processing and Transparency Family 294

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

SecA.Requirements.docx 8 11/22/21

PT-2. Authority to Process Personally Identifiable Information 296

PT-3. Personally Identifiable Information Processing Purposes 297 PT-4. Consent 299

PT-5. Privacy Notice 300

PT-6. System and Records Notice 302

PT-7. Specific Categories of Personally Identifiable Information 304 PT-8. Computer Matching Requirements 305

2.16 Risk Assessment Requirements 306

RA-1. Risk Assessment Policy and Procedures 306 RA-2. Security Categorization 307

RA-3. Risk Assessment 308

RA-4. Risk Assessment Update 311 RA-5. Vulnerability Scanning 311

RA-6 Technical Surveillance Countermeasures Survey 316

RA-7 Risk Response 317

RA-8 Privacy Impact Assessments 317 RA-9 Criticality Analysis 319

RA-10 Threat Hunting 320

2.17 System and Services Acquisition Requirements 320

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

SA-2. Allocation of Resources 322

SA-3. System Development Life Cycle 322

SA-4. Acquisition Process 324 SA-5. System Documentation 330

SA-6. Software Usage Restrictions 332

SA-7. User-Installed Software 332 SA-8. Security Engineering Principles 332

SA-9. External System Services 351

SA-10. Developer Configuration Management 355

SA-11. Developer Security Testing 358 SA-12. Supply Chain Protection 363

SA-13. Trustworthiness 364

SA-14. Critical Analysis 364 SA-15 Development Process, Standards, and Tools 364

SA-16 Developer-Provided Training 369

SA-17 Developer Security Architecture and Design 369

SA-18 Tamper resistance and detection 375 SA-19 Component Authenticity 375

SA-20 Customized Development of Critical Components 375

SA-21 Developer Screening 376 SA-22 Unsupported System Components 376

SA-23 Specialization 377

2.18 System and Communications Protection Requirements 378

SecA.Requirements.docx 9 11/22/21

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

SC-2. Application Partitioning 379 SC-3. Security Function Isolation 380

SC-4. Information in Shared Resources 382

SC-5. Denial of Service Protection 383

SC-6. Resource Availability 385 SC-7. Boundary Protection 385

SC-8. Transmission Confidentiality and Integrity 396

SC-9. Transmission Confidentiality 398 SC-10. Network Disconnect 398

SC-11. Trusted Path 399

SC-12. Cryptographic Key Establishment and Management 400

SC-13. Use of Cryptography 402 SC-14. Public Access Protections 402

SC-15. Collaborative Computing Devices 402

SC-16. Transmission of Security Attributes 404 SC-17. Public Key Infrastructure Certificates 405

SC-18. Mobile Code 406

SC-19. Voice Over Internet Protocol 408

SC-20. Secure Name / Address Resolution Service (Authoritative Source) 408 SC-21. Secure Name / Address Resolution Service (Recursive or Caching Resolver) 409

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

SC-23. Session Authenticity 410

SC-24. Fail In Known State 411 SC-25. Thin Nodes 411

SC-26. Decoys 412

SC-27. Operating System-Independent Applications 412 SC-28. Protection of Information at Rest 413

SC-29. Heterogeneity 414

SC-30. Concealment and Misdirection 415

SC-31. Covert Channel Analysis 417 SC-32. System Partitioning 418

SC-33. Transmission Preparation Integrity 419

SC-34. Non-Modifiable Executable Programs 419 SC-35 External Malicious Code Identification 420

SC-36 Distributed Processing and Storage 420

SC-37 Out-Of-Band Channels 422

SC-38 Operations Security 422 SC-39 Process Isolation 423

SC-40 Wireless Link Protection 424

SC-41 Port and I/O Device Access 426 SC-42 Sensor Capability and Data 426

SC-43 Usage Restrictions 428

SC-44 Detonation Chambers 429

SC-45 System Time Synchronization 429

SecA.Requirements.docx 10 11/22/21

SC-46 Cross Domain Policy Enforcement 431

SC-47 Alternate Communications Paths 431 SC-48 Sensor Relocation 432

SC-49 Hardware-Enforced Separation and Policy Enforcement 432

SC-50 Software-Enforced Separation and Policy Enforcement 433

SC-51 Hardware-Based Protection 433

2.19 System and Information Integrity Requirements 434

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

SI-2. Flaw Remediation 435 SI-3. Malicious Code Protection 437

SI-4. System Monitoring 440

SI-5. Security Alerts, Advisories, and Directives 450 SI-6. Security Function Verification 451

SI-7. Software, Firmware and Information Integrity 452

SI-8. Spam Protection 456

SI-9. Information Input Restrictions 457 SI-10. Information Input Validation 457

SI-11. Error Handling 460

SI-12. Information Handling and Retention 460

SI-13. Predictable Failure Prevention 462 SI-14 Non-Persistence 464

SI-15 Information Output Filtering 466

SI-16 Memory Protection 466 SI-17 Fail -Safe Procedures 466

SI-18 Personally Identifiable Information Quality Operations 467

SI-19 De-identification 470

SI-20 Tainting 473 SI-21 Information Refresh 474

SI-22 Information Diversity 474

SI-23 Information Fragmentation 475

2.20 Supply Chain Risk Management 476

SR-1 Policy and Procedures 476

SR-2 Supply Chain Risk Management Plan 477 SR-3 Supply Chain Controls and Processes 479

SR-4 Provenance 480

SR-5 Acquisition Strategies, Tools, and Methods 483

SR-6 Supplier Assessments and Reviews 485 SR-7 Supply Chain Operations Security 486

SR-8 Notification Agreements 486

SR-9 Tamper Resistance and Detection 487 SR-10 Inspection of Systems or Components 488

SR-11 Component Authenticity 488

SR-12 Component Disposal 489

SecA.Requirements.docx 11 11/22/21

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

SecA.Requirements.docx 12 11/22/21 period; and automatically [Selection: locks the account/node for an [Assignment: organization-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.

SecA.Requirements.docx 13 11/22/21

2.1 Access Control Requirements

AC-1. Access Control Policy and Procedures

Privacy LO W AC-1 MO D AC-1 HIGH AC-1

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

SecA.Requirements.docx 14 11/22/21 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 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

LO W AC-2 MO D 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;

SecA.Requirements.docx 15 11/22/21

2. When users are terminated or transferred; and

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

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

SecA.Requirements.docx 16 11/22/21 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 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;

SecA.Requirements.docx 17 11/22/21

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

(c) Are in violation of organizational policy; or

(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

SecA.Requirements.docx 18 11/22/21 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 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.

SecA.Requirements.docx 19 11/22/21

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].

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.

SecA.Requirements.docx 20 11/22/21

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 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

LO W AC-3 MO D 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

SecA.Requirements.docx 21 11/22/21 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.

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

SecA.Requirements.docx 22 11/22/21

(5) Changing the rules governing access control; and

(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:

SecA.Requirements.docx 23 11/22/21

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

(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 informatio n 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.

SecA.Requirements.docx 24 11/22/21

Related Controls: CM-6, SC-39.

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.