How-To Guide: NIST 800-53 (Security & Privacy Controls)

How-To Guide: NIST 800-53: Security and Privacy Controls

The following is a summarized guide on how to use NIST 800-53 in the real world prefaced by a full summary and explanation of the latest revision (5). It's important to understand the document before moving onto its real world application so we will start with the summary of each chapter.

Introduction:

NIST 800-53 provides a comprehensive set of security controls designed to protect information systems and data that is processed, stored, or transmitted by those systems. It places emphasis on federal information systems but may be used elsewhere. This document outlines a structured framework that helps entities establish, implement, and manage security and privacy programs. It covers a broad range of security controls, categorized into families such as access control, audit and accountability, configuration management, and incident response, among others. 

The first revision of this publication was written in 2005 and is subsequently updated to reflect evolving cybersecurity threats and technological advancements. NIST 800-53 serves as a key reference for developing secure information systems and ensuring compliance with federal regulations and guidelines. Its systematic approach helps orgs assess risks, select appropriate security controls, and continuously monitor and improve their security posture to safeguard sensitive information and maintain trustworthiness in their operations. 

Chapter One: Introduction (The Need to Protect Information, Systems, Organizations, and Individuals)

Information systems can range from industrial control systems to weapons systems and everything in between. These platforms all share a common foundation in that they're computers with complex hardware, software and firmware providing capabilities that support essential business functions of any given organization.

Security controls are the safeguards employed within a system to protect the CIA (confidentiality, integrity, and availability) of the system and its information while managing information security risks. Privacy controls are the administrative, technical, and physical safeguards employed within a system to manage privacy risks and to ensure compliance with privacy requirements. These controls are derived from applicable laws, executive orders, directives, regulations, policies, standards, and mission needs to ensure the CIA of information processed, stored, or transmitted and to manage risks to individual privacy.

The selection, design, and implementation of security and privacy controls are important tasks that have significant implications for the operations and assets of organizations as well as the welfare of individuals working for those organizations. Several key questions should be asked when addressing information security and privacy controls:

1) What controls are needed to satisfy security and privacy requirements and to adequately manage mission/business risks or risks to individuals?

2) Have the selected controls been implemented or is there a plan in place to do so?

3) What is the required level of assurance that the selected controls, as designed and implemented, are effective?

These questions should be answered in the context of a risk management process for the organization that identifies, assesses, responds to, and monitors security and privacy risks arising from its data and systems on an ongoing basis. The controls in this framework are recommended for use by orgs to satisfy their infosec and privacy requirements. The control catalog (which we will go over soon) can be viewed as a toolbox containing a collection of safeguards, countermeasures, techniques, and processes to respond to security and privacy risks. These controls serve as part of a well-defined risk management process that supports the organization. The core objective is to manage risks through the selection and implementation of these security and privacy controls.

It's important to mention that the controls are independent of the process employed to select those controls. The combination of a catalog of controls and a risk-based control selection process can help orgs comply with stated security and privacy requirements, obtain adequate security for their information systems, and protect the privacy of individuals.

Requirements for managing security and privacy risks:

• Well-defined security and privacy requirements for systems and orgs

• Use of trustworthy information system components based on hardware, firmware, and software development and acquisition processes

• Rigorous security and privacy planning and system development life cycle management

• The application of system security and privacy engineering principles and practices to securely develop and integrate system components into information systems

• The employment of security and privacy practices that are properly documented and integrated into and supportive of the institutional and operational processes of orgs

• Continuous monitoring of information systems and orgs to determine the ongoing effectiveness of controls, changes in information system and environments of operation, and the state of security and privacy org-wide.

Example: Privacy risks may arise from the processing of personal identifiable information (PII). The catalog of security and privacy controls can be effectively used to protect the org. as well as individuals and information systems from traditional threats and APTs.

Orgs have the responsibility to select the appropriate security and privacy controls, to implement the controls correctly, and to demonstrate the effectiveness of each control in order to satisfy security and privacy requirements. These controls can also be used in developing specialized baselines or overlays for unique or specialized business applications, information systems, threat concerns, and more.

Risk assessments are used to inform the security and privacy control selection process. The selection process results in an agreed-upon set of security and privacy controls addressing specific mission or business needs consistent with the orgs risk tolerance. The process preserves the agility and flexibility that orgs need to address an increasingly sophisticated and hostile threat space.

Chapter Two: The Fundamentals (Structure, Type, and Org. of Security and Privacy Controls)

There is a relationship between requirements and controls. Requirements are generally used to refer to information security and privacy obligations imposed on organizations. It may also be used in a broader sense to refer to an expression of stakeholder protection needs for a particular system or organization. These requirements may be derived from many sources including laws, regulations, policies, directives or risk assessments. All requirements, when applied to a system, help determine the necessary characteristics of the system (taking into account security, privacy, and assurance).

Example: OMB A-130 imposes security and privacy requirements that federal agencies must comply with when managing information resources.

Organizations may use the term capability requirement to describe a capability that the system must provide to satisfy a stakeholder protection need (requirement). Another term used is specification requirements, which refers to system requirements that pertain to particular hardware, software, and firmware components of a system. These are capabilities that implement all or part of a control and that may be assessed as part of testing and validating.

Lastly, statement of work requirements refer to actions that must be performed operationally or during system development (SDLC - System Development Life Cycle).

Controls themselves are safeguards and protection capabilities for achieving security and privacy goals of the org. These are selected and implemented by the org. in order to satisfy system requirements. Controls can be administrative, technical, and/or physical. Sometimes the selection and implementation of a certain control may call for additional specification in the form of derived requirements. Derived requirements or control parameter values may be necessary to provide the appropriate level of implementation detail for a certain control within the SDLC.

Controls are organized into 20 families. Each family contains controls that are related to the specific topic of the family. A two-character identifier uniquely identifies each control family (Example: The ID of AC represents the family of controls surrounding Access Control. Access Control is the Family of controls.)

Families of controls contain base controls and control enhancements. Control enhancements are directly related to their base controls. They're used to add functionality to a base control that requires greater protection than the protection provided by the base control. The need for orgs. to select and implement control enhancements is due to potential adverse impacts or when orgs require additions to the base control functionality or assurance based on risk assessments. The selection and implementation of control enhancements always requires the selection and implementation of the base control. You can't have control enhancements without having a base control already implemented. Enhancements are inherently related to their base control.

Example: Structure of a base control section, a discussion section, a related controls section, a control enhancements section, and a references section. 

Related controls section: Provides a list of controls that impact/support the implementation of a particular control or control enhancement. There is a 2 way relationship.

Control enhancement section: In the AU-4 example, if the control enhancement is selected, the control designation becomes AU-4(1). The (1) indicates that the control enhancement (1) is being implemented on the base control AU-4.

References section: A list of applicable laws, policies, standards, guidelines, websites, and other useful references that are relevant to a specific control or control enhancement.

Further tailoring of controls are done using assignment and selection operations embedded within the controls and enclosed by brackets (In the above example, we can see this in the frequency and record retention requirements set forth by the organization.)

Organizations will use risk assessments and risk tolerance in determining values for control parameters. These control parameters used in the base controls also apply to the control enhancements associated with those controls.

Additional flexibility is achieved via iteration and refinement actions. Iteration allows orgs to use a control multiple times with different assignment and selection values, perhaps being applied in different situations or when implementing multiple policies.

Example: An org. may have multiple systems implementing a control but with different parameters established to address different risks for each system and environment of operation.

Refinement is the process of providing additional implementation detail to a control. It can be used to narrow the scope of a control in conjunction with iteration to cover all applicable scopes.

Example: Applying different authentication mechanisms to different systems.

The combination of assignment and selection operations and iteration and refinement actions when applied to controls provides flexibility to allow orgs to satisfy a broad spectrum of security and privacy requirements. Especially as the org. continues to scale.

Three approaches to implementing controls (in chapter 3):

1 - A common inheritable control implementation approach

2 - A system-specific control implementation approach

3 - A hybrid control implementation approach

The control implementation approach defines the scope of applicability for the control, the shared nature/inheritability of the control, and the responsibility for control development, implementation, assessment, and authorization.

Each control implementation approach has a specific objective and focus that helps orgs select the appropriate controls, implement the controls in an effective manner, and satisfy security and privacy requirements. One specific control implementation approach may achieve cost benefits by leveraging security and privacy capabilities across multiple systems and environments (versus just a single one) of operation.

Common controls are controls whose implementation results in a capability that is inheritable by multiple systems or programs. A control is inheritable when the system or program receives protection from the implemented control, but the control is developed, implemented, assessed, authorized, and monitored by an entity other than the entity responsible for the system or program. That system or program can be mission or business lines, orgs, enclaves, environments of operation, sites, or other systems/programs. 

Implementing controls as common controls can introduce the risk of a single point of failure.

Examples of good candidates for common controls would be physical and environmental protection controls, personnel security controls, and incident response controls. Common controls can include tech-based controls such as ID and authentication controls, boundary protection controls, audit and accountability controls and access controls. The cost of implementing and maintaining such controls can be amortized across multiple systems, org elements, and programs using the common control implementation approach.

Controls not implemented as common controls are implemented as system-specific or hybrid controls. System-specific controls are the primary responsibility of the system owner and the authorizing official. 

System-specific controls can introduce risk if the control implementations are not interoperable with common controls. 

Orgs can implement a control as hybrid if one part of the control is common (inheritable) and the other part is system-specific.

For example, an organization may implement control CP-2 using a predefined template for the contingency plan for all organizational information systems with individual system owners tailoring the plan for system-specific uses, where appropriate. The division of a hybrid control into its common (inheritable) and system-specific parts may vary by organization, depending on the types of information technologies employed, the approach used by the organization to manage its controls, and assignment of responsibilities. The division of a hybrid control into its common (inheritable) and system-specific parts may vary by organization, depending on the types of information technologies employed, the approach used by the organization to manage its controls, and assignment of responsibilities.

Implementing controls as hybrid controls can introduce risk if the responsibility for the implementation and ongoing management of the common and system-specific parts of the controls is unclear.

The determination of selecting which control implementation to select is context-dependent. 

Identifying the control implementation approach can result in significant savings to orgs in implementation and assessment costs and a more consistent application of the controls org-wide.

Typically, the identification of the control implementation approach is straightforward. However, the implementation takes significant planning and coordination. Planning for the approach of a control is best carried out in the system development life cycle and coordinated with the entities providing the control. If the control is to be inheritable, coordination is required with the inheriting entity to ensure that the control meets its needs. It's essential to examine the control parameters when determining if a common control is adequate to mitigate system-specific risks.

Two fundamental concepts that affect trustworthiness of systems are:

1) Functionality: The security/privacy features, functions, mechanisms, services, procedures, and architectures implemented within organizational systems and programs and the environments in which those systems and programs operate.

2) Assurance: The measure of confidence that the system functionality is implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security and privacy requirements for the system (therefore, possessing the capability to accurately mediate and enforce established security and privacy policies).

It's important for orgs to consider the evidence (ex: documentation, artifacts) that will be needed to support current and future control assessments. Such assessments help determine whether the controls are: 

1) implemented correctly

2) operating as intended

3) satisfying security and privacy policies

This enables us to provide essential information for senior leaders to make informed risk-based decisions.

Chapter 3: The Controls (Security and Privacy Controls and Control Enhancements)

The catalog of security and privacy controls provides protection measures for systems, orgs, and individuals. This will become clear in the proceeding example below. Most of the controls in the catalog are policy, technology, and sector-neutral, meaning that the controls focus on the fundamental measures required to protect information and the privacy of individuals. Just because the controls are policy, technology, and sector-neutral does not imply that the controls are policy, technology, and sector-unaware.

Side Note: In the rare cases where specific technologies are referenced in the controls, orgs are cautioned that the need to manage security/privacy risks may go beyond the requirements in a single control associated with a specific technology.

Understanding policies, technologies, and sectors is required so that the controls are relevant when they're implemented. The neutrality present in the control catalog has many benefits. 

It encourages orgs to:

• Focus on the security/privacy functions required for business success and the protection of information and the privacy of individuals - regardless of what technologies are employed

• Analyze each control for its applicability to specific tech, environments of operations, mission/business functions, and communities of interest

• Specify security/privacy policies as part of the tailoring process for controls that have variable parameters

Controls in the catalog are expected to change over time as controls are withdrawn, revised, and added.  Controls may be withdrawn for a number of reasons, including when the function or capability provided by the control has been used in another control or if the control is redundant to an existing control or if the control is deemed to be no longer effective or necessary.

New controls are developed on a regular basis using threat and vulnerability information as well as TTP's (tactics, techniques, and procedures) used by adversaries. There new controls are created based on a better understanding of how to mitigate infosec risks to systems and orgs and to the privacy of individuals arising from information processing. Another reason new controls are created is based on new or changing requirements in laws, executive orders, regulations, policies, standards, or guidelines. 

The objective is to adjust the level of infosec and privacy over time to meet the needs of orgs and individuals. For this reason I implore you to stay up to date with the latest revisions to documents such as NIST 800-53.

Below is an example of a listed control within NIST 800-53 which follows the aforementioned structure. There are over 1,000 controls in NIST 800-53 which you can view here.

I hope this has been informative.

As always, you can reach me on LinkedIn if you have any questions or wish to discuss it with me.

Thank you.