800-53R5

NOTE: If this is your first time looking at the 800-53, please go to NIST Frameworks and SPs Overview first to get a better understanding of 800-53 among the other NIST publications and frameworks.
You probably want to start with the NIST CSF.

What is it?

  1. "NIST Special Publication 800-53 is an information security standard that provides a catalog of security and privacy controls for all U.S. federal information systems except those related to national security"[1]
    1. Revision 5 was published in Sept. 2020
    2. Revision 4 was officially withdrawn on Sept. 23, 2021[2]
  2. Provides a critical framework
    1. 20 control families
      1. Access Control, Risk Management, etc.
    2. Each family has a set of security controls that can be implemented
      1. In Rev. 4, controls were ordered by Priority, but Rev. 5 instead focuses on customized Risk Assessments to determine control priority.
  3. Flexible framework that allows organizations to tailor controls to their organizations
    1. Achieved through risk assessments
  4. Required for organizations with federal information systems that are not related to national security.
    1. These systems can be operated by the government or contractors working with the government.
  5. What are 800-53A and 800-53B?
    1. They are supporting documents for the SP 800-53 that help users and organizations interpret and action the main document.
    2. 800-53A is basically a guide on conducting Security and Privacy Control Assessments (e.g., audits).
      1. "800-53A provides a set of procedures for conducting assessments of security... and privacy controls employed within federal information systems and organizations."[3]
      2. The procedures are designed to be tailored to an organizations unique needs and risk tolerances.
    3. 800-53B "provides a set of baseline security... and privacy controls for information systems and organizations."[4]
      1. Helps organizations choose an appropriate baseline of security and privacy controls for their system's impact level.
      2. Defines control impact levels relating to the three components of the CIA Triad using the "high water mark" standard, where the highest-rated component defines the impact level of the entire system.
        1. Low-impact systems have low impact across the triad
        2. Moderate-impact systems have at least one component that is rated as moderate, and nothing that is rated high
        3. High-impact systems have at least one component that is rated as high

Biggest functional/organizational differences between Rev. 4 and Rev. 5

  1. The Executive Summary highlights these changes:
    1. Making controls outcome based (e.g. what's the end result) as opposed to impact based (e.g., who is responsible for the work) based
      1. This acknowledges that organizations can be complex with overlapping or separated responsibilities
    2. Integrating security and privacy controls (more on that later)
    3. Adding Supply Chain Risk Management to the list of control families
    4. Separating the controls and the control selection process (e.g., control priority) to encourage communities to use controls that pertinent to them
    5. Move Control Baselines into NIST 800-53B and the Control Selection Process into NIST 800-37 (Risk Management Framework)
    6. Adding clarity to the relationships between;
      1. Controls and requirements
      2. Security controls and Privacy controls
    7. Adding new and updated controls
  2. MITRE created a spreadsheet tracking all updates from Rev.4 to Rev.5
    1. Analysis of updates between 800-53 Rev. 5 and Rev. 4, by MITRE Corp. for ODNI (xlsx)
  3. Biggest thing is Privacy
    1. Privacy is now integrated across the entire document (instead of as a separate control), and the DHS Privacy Compliance process[5] can be used to better understand its impact.
    2. NIST provides a document that maps the Rev.4 Privacy Controls to their appropriate sections in Rev.5[6]
  4. Removal of the "Priority" metric
    1. Change to a "Risk Assessment" model tailored to the organization vs. universal "Priorities"
      1. Rev. 4's broad "Priorities" offered a fixed baseline across organizations, regardless of actual necessity
        1. Easier to deploy for many organizations, but could leave gaps
        2. For more outlier organizations, the priorities could be way off
      2. Rev. 5's "Risk Assessment" is more effortful up front, but provides a much clearer picture of necessity
        1. More overall system awareness and fewer blind spots
  5. General language changes to be more inclusive and translate more easily between other frameworks
    1. More closely aligns with the NIST CSF[7]
    2. Replaced the term "information system" with "system," enabling the controls to be applied to other kinds systems (like IoT, general-purpose, etc.)[8]

What is Privacy?

  1. While "Privacy" is not concisely defined by The Privacy Act of 1974,[9] we're given a definition of PII as a way to define the scope of the act.
    1. "Information about an individual that identifies, links, relates, or is unique to, or describes the individual"
      1. "e.g., a social security number; age; military rank; civilian grade; marital status; race; salary; home/office phone numbers; other demographic, biometric, personnel, medical, and financial information, etc."
    2. The introduction linked above also clearly states various ways to safeguard PII.
  2. DHS offers a compliance process for PII
    1. "The privacy compliance process is an ongoing cycle with four key parts to ensure appropriate oversight"[10]
      1. Privacy Threshold Analysis (PTA)
        1. Analysis determines if a system contains PII and requires additional analysis (i.e., performing a PIA)
        2. PTAs expire periodically
          1. Must be reviewed and re-certified every three years
      2. Privacy Impact Analysis (PIA)
        1. Once any PII is identified, the PIA analysis the breadth and scope by determining:
          1. What PII is being collected
          2. Why it's being collected
          3. How the PII will be handled (e.g. collected, stored, accessed, etc.)
      3. System of Records Notice (SORN)
        1. Federal agencies are required by The Privacy Act of 1974 to provide public notice of PII collection with a SORN.
          1. A System of Records Notice is "a formal document stating the information in the System of Records is collected and identifies what data the agency intends to collect, how the data will be used and safeguarded, who will have access, and other details."[11]
      4. Periodic Reviews
        1. PTAs and PIAs are reviewed every three years to ensure compliance
        2. SORNs are reviewed continually

Understanding the reference tool/controls

  1. RTFM - an Overview
    1. Breaking the document down into sections makes it far more approachable.
      1. Pages 1-27:[12] Abstract, keywords, errata.
      2. Pages 28-33:[13] Introduction to the 800-53, providing context for the rest of the document.
      3. Pages 34-42:[14] Titled The Fundamentals, it's a guide to reading the controls on the following pages.
      4. Pages 43-400: The Controls
      5. Pages 401-492: References, glossary, acronyms, and control summaries.
  2. NIST provides a tool to more easily navigate controls[15]

Notes from the official NIST 800-53 Course (as of 5/24/2024)

NIST 800-53 Orientation

  1. What are Security and Privacy Controls, and how are they different from Requirements?
    1. Requirements are the protection needs for a system or organization, and can vary depending on context
      1. Laws, compliance certifications, etc.
      2. Can be slow to change, and so tend to be broad and non-specific
    2. Security and Privacy Controls are specific measures to address risks and accomplish an organizations security and privacy objectives (e.g., compliance requirements)
      1. Security controls target security issues (e.g. the CIA Triad), and overlap with Privacy controls on privacy and confidentiality (e.g., PII)
        1. What should be noted here is that NIST found privacy so important (or neglected) that they really have to spell it out.
      2. Controls are documented in their respective plans (the security plan and privacy plan)
    3. Requirements can set objectives for an organization, and Controls enable organizations to fulfill those objectives
  2. Purpose of the 800-53
    1. 800-53 provides a comprehensive catalog of security and privacy controls
    2. Supports the RMF "Select" and "Implement" steps
    3. Required in Federal InfoSec settings, but designed to support any organization across any sector
  3. How to read controls
    1. Control Identifier
      1. Formatted XX-Y(Z)
        1. XX = Control family
        2. Y = Control number
          1. The order of controls does not imply importance or relevance to an organization
        3. (Z) = Control Enhancement
        4. e.g., AC-2(3) specifies the Access Control family, the 2nd control (Account Management), and the 3rd control enhancement (Disable Accounts)
      2. ID's and numbers are assigned alphabetically and in order of addition to the framework, and do not denote important
    2. Base Control
      1. Description of the control to be implemented
    3. Organization-Defined Parameters (ODP)
      1. Identifies Assignments and Selections to customize the control to the organization in assignment operations[16]
        1. Additional details on tailoring and applying ODP values is found in 800-53B
      2. Assignments are defined personnel/roles, time periods, conditions, etc.
        1. e.g., AC-2(5) has organizations define how long before an idle account is automatically logged out
      3. Selections offer organizations a choice between different control mods according to their needs
        1. e.g., AC-2(7)(a)[17] has organizations choose between a role- or attribute-based privileged account access scheme
    4. Control Enhancement
      1. Enhance a specific control
      2. Not intended to be selected independently
    5. Discussion
      1. Offers additional information and insight
      2. Often includes example
    6. Related Controls
      1. Controls that may further address a related security or privacy control statement/objective
    7. References
      1. Includes hyperlinks to applicable laws or background information to help organizations implement controls
      2. Not inclusive or complete
  4. Control Families
    1. 20 control families
      1. FIPS 200 identified 17 security-related areas that led to the original control families
        1. Also identifies minimum security requirements
      2. 3 additional control families added since FIPS 200 was published
        1. Program Management (PM), PII Processing and Transparency (PT), and Supply Chain Risk Management (SR)
    2. Control families arranged in alphabetical order of their identifiers when added to the framework
      1. Some identifiers, like CA for Assessment, Authorization, and Monitoring, don't make sense anymore withe new naming, but are maintained to keep families consistent
    3. Appendix C includes a catalog of controls
      1. Identify who implements the control (i.e. Organization and/or System, or if it has been Withdrawn)
        1. If Withdrawn, it mentions which control now incorporates it
          1. Withdrawn control numbers are not reused to maintain consistency within organizations across updates
      2. Also marks which controls provide assurance of security or privacy claims
        1. Critical for determining trust of systems
  5. Controls Implementation approaches
    1. Common (e.g. shared, inheritable)
      1. Tied to a common control provider who is responsible for the implementation
      2. Controls are inheritable across different systems within the organization
        1. e.g. email, EDR, etc.
      3. May centralize services across an organization, improving efficiency and reducing cost
      4. May introduce single points of failure that impact all connected systems
        1. e.g., if the org Exchange server crashes, it would impact the whole org
    2. System-specific
      1. Only the system owner and authorizing official are fully responsible
      2. However, could be used to exploit the organization as a whole
    3. Hybrid
      1. Shared between common-control provider and system owner
        1. Example given is an overarching GRC tool provided at the organization level, but system owners or expected to maintain the tool within their domains
      2. Risk is introduced if the responsibility for implementation and management are unclear
  6. Updates and supporting documents
    1. RMF project site
      1. Additional RMF publications: RMF Publications
    2. 800-53 and 800-53B Baselines - Resources for Implementers
      1. Comments can also be made here.
    3. CPRT (Cybersecurity and Privacy Reference Tools)
      1. A catalog matching the Publications and their datasets.
    4. NIST Computer Security Resource Center | CSRC
      1. NIST's homepage for all things cybersecurity related.
    5. National Online Informative References Program | CSRC
      1. Tools to create mappings between different frameworks (e.g., RMF and ISO 27001).
    6. OSCAL - Open Security Controls Assessment Language
      1. The OSCAL Language is a standardized machine-readable format for information related to security controls and assessments.

Control Families Review

I'm going to define each control family[18] and identify any sample references provided in the training,[19] as well as any interesting snippets from the lecture.
Controls review begins on slide 19.

  1. AC – Access Control: Limit access to information systems and devices by authorized users and supporting tools.
    1. Not the same as PE; specifically about attribute/role-based access control and systems.
    2. Supporting docs
      1. SP 800-162, Guide to Attribute Based Access Control (ABAC) Definition and Considerations | CSRC
      2. SP 800-192, Verification and Test Methods for Access Control Policies/Models | CSRC
  2. AT – Awareness and Training: User awareness training about security risks and controls.
    1. Teaching the same thing year after year does not count
      1. Doesn't reflect changes in technology, security environment, etc.
    2. Supporting docs
      1. SP 800-50, Building an Information Technology Security Awareness and Training Program | CSRC
  3. AU – Audit and Accountability: Maintaining, reviewing, and analyzing effective logs
    1. Important to ensure that PII is not accidentally collected within the logs
    2. However, also critical to ensure the logs are effective in identifying malicious actors and behavior
    3. Ties in closely with IR (Incident Response)
    4. Supporting docs
      1. SP 800-86, Guide to Integrating Forensic Techniques into Incident Response | CSRC
      2. SP 800-92, Guide to Computer Security Log Management | CSRC
  4. CA – Security Assessment and Authorization: Assess and improve security position through planning and continuous monitoring.
    1. This includes things like penetration testing, Plan of Action and Milestones, and policies and procedures to help improvement.
    2. Supporting docs
      1. SP 800-47 Rev. 1, Managing the Security of Information Exchanges | CSRC
      2. SP 800-137, Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations | CSRC
      3. SP 800-137A, Assessing Information Security Continuous Monitoring (ISCM) Programs: Developing an ISCM Program Assessment | CSRC
  5. CM – Configuration Management: Use baseline configurations and controlled changes to help ensure a secure environment.
    1. Establishing a baseline and controlling changes also ensures systems are easier to rebuild or replace should a problem occur.
    2. Supporting docs
      1. SP 800-128, Guide for Security-Focused Configuration Management of Information Systems | CSRC
  6. CP – Contingency Planning: Create plans to ensure operation continuity in the event of an outage.
    1. This includes policy, training, testing, communication channels, backups, and general recovery.
    2. Supporting docs
      1. SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems | CSRC
      2. SP 800-84, Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities | CSRC
  7. IA – Identification and Authentication: Authenticate users and devices.
    1. Supporting docs
      1. Identity & access management | NIST
      2. SP 800-63 series
  8. IR – Incident Response: Policies and procedures for handling security incidents.
    1. Ties in closely with AU (Audit and Accountability)
    2. Supporting docs
      1. SP 800-61 Rev. 2, Computer Security Incident Handling Guide | CSRC
      2. Incident Response | CSRC
  9. MA – Maintenance: Patch all the things and keep up those service contracts.
    1. Important to consider not just deployment, but timely repair or maintenance of systems
  10. MP – Media Protection: Controls to protect, limit access to, and securely dispose of IS media.
    1. Includes controls for how to properly transport media
    2. Additionally, Media Downgrading is the important process of preparing media for wider release by removing sensitive information and ensuring "empty" space is truly empty.
    3. Supporting docs
      1. SP 800-88 Rev. 1, Guidelines for Media Sanitization | CSRC
      2. SP 800-111, Guide to Storage Encryption Technologies for End User Devices | CSRC
  11. PE – Physical and Environmental Protection: Limiting physical access to sensitive systems and protecting environmental controls.
    1. Not just things like locks and doors, but environmental controls and how PII from visitors is handled.
      1. e.g., compromising an HVAC system and shutting it off could overheat a server room.
    2. Supporting docs
      1. SP 800-46 Rev. 2, Guide to Enterprise Telework, Remote Access, and Bring Your Own Device (BYOD) Security | CSRC
      2. SP 800-116 Rev. 1, Guidelines for the Use of PIV Credentials in Facility Access | CSRC
  12. PL – Planning: Controls for developing and implementing security plans.
    1. Baseline Selection (PL-10) and Baseline Configuration (CM-2) are not related, so don't confuse them.
    2. Supporting docs
      1. SP 800-18 Rev. 1, Guide for Developing Security Plans for Federal Information Systems | CSRC
      2. SP 800-160 Vol. 1 Rev. 1, Engineering Trustworthy Secure Systems | CSRC
      3. SP 800-160 Vol. 2 Rev. 1, Developing Cyber-Resilient Systems: A Systems Security Engineering Approach | CSRC
  13. PM – Program Management: Security program management and planning.
    1. Not a FIPS 200 control
    2. Not included in the secure baselines of 800-53B
    3. Supporting docs
      1. SP 800-30 Rev. 1, Guide for Conducting Risk Assessments | CSRC
      2. SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations | CSRC
  14. PS – Personnel Security: Screening, management, and termination of employees access to sensitive information.
    1. Supporting docs
      1. SP 800-181 Rev. 1, Workforce Framework for Cybersecurity (NICE Framework) | CSRC
  15. PT – PII Processing and Transparency: How PII is managed and individuals are notified or alerted.
    1. Not a FIPS 200 control
    2. See the above "What is Privacy?" section to see how the DHS handles PII.
    3. Supporting docs
      1. Privacy engineering | NIST
      2. IR 8062, An Introduction to Privacy Engineering and Risk Management in Federal Systems | CSRC
  16. RA – Risk Assessment: Risk assessments, Threat Hunting, vulnerability management, etc.
    1. Supporting docs
      1. SP 800-30 Rev. 1, Guide for Conducting Risk Assessments | CSRC
      2. SP 800-39, Managing Information Security Risk: Organization, Mission, and Information System View | CSRC
      3. SP 800-60 Rev. 1 Vol 1 and 2
      4. Risk Assessment Tools | NIST
  17. SA – System and Services Acquisition: Regulating system acquisition to better ensure support, maintenance, and security through its life cycle.
    1. Specifically targets Shadow IT, and helps create processes that make sure new systems are vetted to ensure a certain standard of security and support while it's in use.
    2. Supporting docs
      1. SP 800-70 Rev. 4, National Checklist Program for IT Products: Guidelines for Checklist Users and Developers | CSRC
      2. SP 800-154, Guide to Data-Centric System Threat Modeling | CSRC
  18. SC – System and Communications Protection: Security controls for hosts and networks.
    1. Basically network security, including host-based firewalls, host and network isolation, etc.
    2. Supporting docs
      1. SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy | CSRC
      2. SP 800-47 Rev. 1, Managing the Security of Information Exchanges | CSRC
        1. Not specifically mentioned, but feels like it should go here
      3. SP 800-77 Rev. 1, Guide to IPsec VPNs | CSRC
  19. SI – System and Information Integrity: Ensuring the accuracy and reliability of system information.
    1. The I in the CIA Triad
    2. Supporting docs
      1. SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology | CSRC
      2. SP 800-177 Rev. 1, Trustworthy Email | CSRC
  20. SR – Supply Chain Risk Management: Mitigating risks from the supply chain to minimize vulnerabilities.
    1. Not a FIPS 200 control
    2. This feels like it would run hand-in-hand with SA - System and Services Acquisition
    3. Includes things like patches, approved vendor lists and using different vendors, using standard configurations, etc.
    4. Supporting docs
      1. SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations | CSRC

Resources:

Articles

Videos

High Efficiency

Medium Value

Low Efficiency

Unreviewed

Channel: ConvoCourses

This guy has interesting information, but it's more nuanced than a comprehensive course or broad overview

  1. NIST Special Publication 800-53 - Wikipedia ↩︎

  2. nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf ↩︎

  3. NIST Special Publication 800-53 - Wikipedia ↩︎

  4. NIST Special Publication 800-53 - Wikipedia ↩︎

  5. Understanding privacy compliance ↩︎

  6. Mapping: Appendix J Privacy Controls (Rev. 4) to Rev. 5 (xlsx) ↩︎

  7. Mappings: Cybersecurity Framework and Privacy Framework to Rev. 5 (xlsx) ↩︎

  8. NIST Special Publication 800-53 - Wikipedia ↩︎

  9. This "Introduction to The Privacy Act" guide translates The Act into a human-readable format: https://dpcld.defense.gov/Portals/49/Documents/Privacy/2011 DPCLO_Intro_Privacy_Act.pdf ↩︎

  10. Compliance | Homeland Security ↩︎

  11. Introduction to The Privacy Act ↩︎

  12. Note that page count here is not the numbered pages, but the actual count from the title page to the last page of the appendix. ↩︎

  13. 6 total pages. ↩︎

  14. 9 total pages. ↩︎

  15. Cybersecurity and Privacy Reference Tool | CSRC ↩︎

  16. assignment operation - Glossary | CSRC ↩︎

  17. Note that the (a) here is not included in the official control identifier. ↩︎

  18. RiskOptics also did a perfect job of that here: Complete Guide to the NIST Cybersecurity Framework — RiskOptics ↩︎

  19. The training provided search links in their publication database, but think links I provide go straight to the publication page. ↩︎