Across various industries including the Department of Defense (DoD), federal service agencies, financial institutions, healthcare and other highly regulated organizations, the National Institute of Standards and Technologies (NIST) 800 53 security framework, is used to describe the security compliance. It is a standard catalog of security controls for protecting organizations’ operations, assets, and users from cyber threats. To be sure that is a broad definition that requires more nuance. However, it’s this broad definition that makes it the basis or framework for various other regulatory and security frameworks like HIPPA, SOC, Cybersecurity Maturity Model Certification CMMC), and various other NIST controls like 800-161 Supply Chain controls to name a few.
Security leaders and practitioners should prioritize understanding this critical framework and its impact on mitigating risk so they can invest in the right security controls.
It’s all in the families: the basics of NIST 800-53
NIST 800-53 was created in 2005 as a common framework to manage and mitigate cybersecurity risks. It was developed in collaboration with government agencies, industry professionals and public input. It is organized into twenty control families with each family aligned to certain attributes of a continuously secured and compliant system. Attributes like continuous monitoring, active defense, incident response, threat monitoring, log analysis, SBOM support, secure software supply chains, repeatability and more. Some of the families and attributes may not be security specific at first glance, but when considered more closely we see how they impact an organization’s security posture, and that security must be a team sport.
For example there is a whole family of controls centered around Maintenance (MA). It includes controls related to equipment, repairs and patching. Patching is an obvious security gap that can be exploited but having broken components in your architecture will affect your organization’s mission just the same.
The Awareness and Training (AT) family of controls is another great example that shows how some topics that seem unrelated to security can impact system performance. An unaware practitioner can harm your system and mission just as much as an expert hacker. Even managers are involved via the Program Management (PM) family which ensures that adequate resources (personnel and budget) are provided for the system. No system can overcome lack of funds to fix system vulnerabilities. Failure to resource security fixes and upgrades will make any system flaw vulnerable to hackers.
The Rosetta Stone of Security frameworks
The Federal Information Security Modernization Act (FISMA) is the law that mandates federal agencies secure federal government information systems. Through that law NIST was designated to create security policies and standards. Thus NIST Guidelines for Security and Privacy for Information Systems and Organizations was born, cataloging a framework for standard security and privacy policies.
Federal Agencies were the first adopters of NIST 800-53, as part of the Risk Management Framework (RMF) which uses its controls as the core guideline for managing security risk throughout a system’s life cycle. The Risk Management Framework tells the narrative of your organization’s relationship to risk through the lens of security controls, risk assessment and mitigation plans. A full RMF package consists of system policies, control responses, and a plan of action and milestones (POAM).
RMF is not the only framework where federal agencies leverage 800-53. The Federal Risk and Authorization Management Program (FedRAMP), which focuses on securing cloud products such as those offered by cloud service providers (CSP) and applications hosted in the cloud must also follow NIST 800-53. So FedRamp approved CSP services with strong inheritance models pass the accreditation on to their customers. The inheritance model shows which security controls are executed by the CSP vs. are the responsibility of the federal agency customer.
Security frameworks are not only for digital environments and systems. Companies’ processes and infrastructure are assessed and validated if they want to do business with the government. The Cybersecurity Maturity Model Certification (CMMC) is another federal security framework used to define if a company has the mechanisms in place to protect federal controlled unclassified (CUI) data. While this initially is impacting the Defense Industrial Base, it will expand to all federal work that needs to use or process federal data. CMMC uses a subset of 800-53 controls documented in NIST 800-171. Another way to say this is that it is a tailoring of the 800-53 controls assuming a moderate baseline and removal of controls that are the responsibility of the federal government. Almost all of the 800-53 control families are included in a company’s assessment with a few exceptions such as the Program Management family. The PM family does not have a direct impact on CUI protection.
Like federal agencies, the DoD adopted the use of 800-53 in its implementation of RMF, replacing the DoD Information Assurance and Accreditation Process (DIACAP) in 2010. This was an effort to use the same cybersecurity standard for DoD and other federal systems. In fact all of the aforementioned 800-53 federal standards also apply to the DoD. The DoD has also created hardening standards for various technology solutions.
Security Technical Implementation Guidance (STIG) is a detailed list of security configuration settings for products like operating systems, applications and databases. For example if you use Microsoft Word, there is a STIG list of settings that you can implement to secure your system. However, if you are using a custom application or one that is not on the approved list of STIGs then you have to use the Application Security and Development STIG. Every STIG check maps to a NIST 800-53 and will help describe control implementation that makes up a DoD RMF package.
Beyond DoD and Government
Healthcare industry security standards also map to NIST 800-53. In the health industry, compliance with Health Insurance Portability and Accountability Act (HIPAA) and Health Information Technology for Economic and Clinical Health (HITECH) are the standards to secure personal health information (PHI). Both of these standards are derived from NIST 800-53 to implement a layered approach in protecting data in the healthcare industry.
HIPAA has Security Rules (Administrative, Physical and Technical) which are comparable to NIST Security Controls. For example, the HIPAA requirement of Workforce Safety maps to 800-53 control families of access control (AC) and Personnel Security (PS). HIPAA’s audit requirements map to the audit and accountability (AU) family in NIST. While HIPAA is primarily concerned with protecting the privacy and security of patients’ health information, HITECH focuses on electronic protected health information (ePHI). For example HITECH Section 13402 specifies that healthcare system encryption methods follow NIST standards and even goes as far to state that if breached data is encrypted that notification may not be required.
In NIST 800-53 System and Communications Protection (SC) SC-12 Cryptographic Key Establishment and Management has a similar requirement to use cryptographic methods to protect data in transit and at rest. These standards apply to healthcare providers, payers and vendors. There is also the Electronic Health Record (EHR) Certification Criteria. In order to achieve a certification, an EHR system must implement privacy and security measures that include access controls and encryption that maps to NIST 800-53 controls.
The financial industry uses 800-53-like standards as well with System and Organization Controls (SOC) and Payment Card Industry Data Security Standards (PCI DSS). SOC reports, ranging from 1-3, are auditing standards used by a variety of organizations, specifically financial institutions to assess their ability to implement security and compliance. SOC 2 reports cover availability, integrity, confidentiality and privacy. These align to controls in NIST 800-53. SOC 2 processing integrity maps to controls in the System and Services Acquisition control family and SOC 2 Confidentiality requirements maps to the data protection requirements in the SC and AC 800-53 control families.
PCI DSS is the standard for credit card payment protection. It overlaps with NIST 800-53 in the areas of access control, data encryption and network security. For example PCI DSS has requirement 10: Track and monitor all access to network resources and cardholder data. This requirement maps to the NIST 800-53 controls AU-2 Audit Events which specifies events that require auditing.
Understanding how different compliance frameworks map to NIST 800-53 allows organizations to manage compliance across different standards. Using this overlap will allow organizations to streamline their security programs and enable purchasing of products across different market segments. Modern compliance architects expertise in how to tell the story of compliance for your products will help organizations
Check out these additional resources to learn about how Tanzu can help you build and deploy secure software that meets your compliance requirements and continuous authorization guidelines:
Whitepaper: Security Outcomes with VMware Tanzu Platform
Blog: Continuous Authorization to Operate (cATO) needs a DevSecOps platform
Webinar: Enhancing Compliance and Security with Tanzu Spring Runtime
eBook: Continuously Secure. Continuously Compliant. Continuously Secure. Continuously Compliant. How the software factory keeps software secure and defect-free
