Regulatory Compliance Standards and Frameworks

Please, Just Tell Me What to Do

Building Cloud Products for Federal Agencies – Using NIST to Shift Compliance Left

Vendors and Consultants working with Federal Agencies are required to establish secure products and services as tagged to their associated commonly defined security controls (outcomes) and do so using a Cybersecurity Framework mapped to address common cybersecurity-related responsibilities. The most common set of categorized outcomes (a.k.a. Control Families or Control Objectives) is the security controls in NIST SP 800-53 Rev. 5[i], Security and Privacy Controls for Federal Information Systems and Organizations.

Introducing NIST

The National Institute of Standards and Technology (NIST) is part of the U.S. Department of Commerce, established by Congress to remove significant challenges to U.S. industrial competitiveness. Its charter supports the development of industry-led cybersecurity standards and best practices for critical infrastructure. The correct implementation of these standards is required by law, specifically by the Cybersecurity Enhancement Act of 2014 (Public Law 113-274) [ii]. All of NIST adheres to a process of risk management, known as the risk management framework (RMF).

NIST Risk Management Framework (RMF) refers to the risk-based methodology used to implement NIST products for guidance and assessments.

“The Risk Management Framework provides a process that integrates security, privacy, and cyber supply chain risk management activities into the system development life cycle. The risk-based approach to control selection and specification considers effectiveness, efficiency, and constraints due to applicable laws, directives, Executive Orders, policies, standards, or regulations. Managing organizational risk is paramount to effective information security and privacy programs; the RMF approach can be applied to new and legacy systems, any type of system or technology (e.g., IoT, control systems), and within any type of organization regardless of size or sector.” [iii]

The NIST Special Publication 800-53 is not an old standard, though it's had nearly seventeen years to mature and adapt to the cyber threat and supply chain landscape. As Government requirements change, so has the combination of critical resources to help meet those challenges.

Government Contractors and Service Providers must comply with NIST

All United States government acquisitions, contracts, products, materials, and cloud solutions are controlled under the Federal Acquisition Regulation (FAR). FAR is a set of rules governing US federal government procurement, codified at Chapter 1 of Title 48 of the Code of Federal Regulations, 48 CFR 1. FAR covers many of the United States military and NASA's contracts and US civilian federal agencies.

NIST, as an agency, provides resources used to guide and assess the development and operation of all technology such that it suits all applicable government requirements. The Federal Acquisition Regulation (FAR) states:

In acquiring information technology, agencies shall include the appropriate information technology security policies and requirements, including using standard security configurations available from the National Institute of Standards and Technology’s website at http://checklists.nist.gov. Agency contracting officers should consult with the required official to incorporate the appropriate standards. [iv]

This means the level of compliance any entity would be required to implement is factored by the size and complexity of its technology and the controls available to manage its offering. NIST is responsible for that overarching process to determine which standards and at what level any company would reasonably implement guidance to satisfy rules such as those created by FAR and DFARS.

Managing the Risk

NIST Interagency/Internal Report (NISTIR-8170) Approaches for Federal Agencies to Use the Cybersecurity Framework [v] provides steps for implementing the Framework for Improving Critical Infrastructure Cybersecurity (known as the Cybersecurity Framework, CSF). This methodology uses various NIST security and privacy risk management standards, guidelines, and practices. Most NIST Special Publications are partially derived from FIPS 200 [vi] and the moderate security control baseline in SP 800-53B [vii]. This means there are sets of controls that act as an index or matrix to implement other dynamically required standards. The entire catalog of all controls is currently the NIST SP 800-53.

“Cybersecurity Framework Profiles enable agencies to reconcile mission objectives and cybersecurity requirements into the structure of the Cybersecurity Framework Core. This readily translates to the SP 800-53 controls that are most meaningful to the organization. Profiles can be used to tailor initial SP 800-53 baselines into final baselines, as deployed in the RMF Implementation step. Typical Participants: Information Owner/Steward, Information System Owner, Information Security Architect, Information System Security Engineer, stakeholders representing other risk management disciplines (e.g., finance, human resources, acquisition) Primary NIST Documents: NIST Special Publication 800-53, Cybersecurity Framework” ^[viii]

Even for Product and Service organizations with a formal Federal Procurement function, navigating the selection of the correct NIST standards and meeting all necessary assessment criteria is a formidable task. There are more than 450 Agencies^[ix] of the US Federal Government, and just one of their many assignments is the development and implementation of their own industry’s process and technology-specific standards. Each agency is responsible for a program of conformity assessment. ^[x]

A key Federal Government Agency responsible for Conformance is the Joint Authorization Board (JAB). ^[xi] The JAB oversees The Federal Risk and Authorization Management Program (FedRAMP), providing a risk-based approach for adopting and using cloud services. FedRAMP empowers agencies to use modern cloud technologies, emphasizing security and protection of federal information. Another important conformity Agency is the Defense Federal Acquisition Regulation Supplement (DFARS) administered by the Department of Defense (DoD). In conjunction with oversight to legal and DoD-wide policy requirements, entities operating with this agency must implement NIST SP 800-171 Rev. 2, and NIST SP 800-172, Enhanced Security Requirements for Protecting Controlled Unclassified Information. DFARS compliance is recorded via SPRS using NIST SP 800-171A, Assessing Security Requirements for Controlled Unclassified Information. In short, DFARS Rule 2019-D041 means that US Federal Agencies cannot award your contract unless you’ve met with the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-171 DoD Assessment Methodology and have validated that assessment either by a Self-Reported, Supplier Performance Risk System (SPRS) score, or, as certified by a DoD accredited assessor (third party) using the prescribed Cybersecurity Maturity Model Certification (CMMC) Framework. ^[xii]

Both DFARS and FedRAMP assessments rely on control families located in NIST SP 800-53 Rev 5.1 and SP 800-53B and the NIST SP 800-171, which is derived from the 800-53.^[xiii] FedRamp Authorization ^[xiv] and the DFARS Supplement ^[xv] Supplier Performance Risk System (SPRS) leverage a catalog of controls intended to provide consumers and providers with context-specific technical guidance as necessary to mitigate risk. Both NIST standards (800-53 and 800-171) require the reporting organization to provide evidence of their System Security Plans as maintained by their Plans of Action & Milestones (POA&Ms). Assessments diverge relative to their risk, which is reflected in the scope and depth of their assessment requirements. For example, FedRamp is concerned with information stored in Federal Systems, and DFARS is concerned with protecting controlled unclassified information (CUI). They also differ in their reliance on an authorized third-party assessor and their allowance for self-reported v. third-party DoD assessed and scored criteria. Each has distinct rules for revealing and reporting exceptions, for remediation prior to authorization, and the manner of monitoring agreements to resolve issues within a period following the review. (For more detail see Compliance with Cybersecurity and Privacy Laws and Regulations | NIST. ^[xvi]

While mandatory NIST compliance among United States Federal Agencies and their Contractors has been enforced by DFARS since 2017, and FedRamp since 2011, stringent requirements for independently gathered evidence of controls and third-party assurance amped up in 2021. Changes in Federal Law now require relevant NIST Standards to apply across the entirety of the Federal Agency Supply Chain. ^[xvii] 

Compliance under Pressure

Interconnectedness gave rise to Ransomware attacks targeting the global Supply Chain and a substantial portion of US Critical Infrastructure. Newsworthy ransomware attacks include Kaseya, ^[xviii] Colonial Pipeline, ^[xix] beef supplier JBS, and Apple who all garnered attention for their huge payouts. The larger story however could have just as easily been smaller public and private entities reeling from Log4J exploits and no doubt not fully recovered from the monumental SolarWinds attack. ^[xx] While everyone agrees that we must Stop Hackers, most people lack the proficiency. Even if they do know what needs to happen, companies may choose to forgo the steps necessary to mitigate much of their cyber risk. Technical debt is real. Skilled professionals are expensive. Each day the rate, scale, and impact of data breaches combine with harvested social and stolen private information, enabling even greater catastrophic cyber events. Cyberattacks collectively set the stage for the May 12th, 2021, Executive Order on Improving the Nation's Cybersecurity. ^[xxi] Software as a Service or 'SaaS' vendors will face increasing difficulty selling cloud services to Federal and Government entities. ^[xxii]

The relationship between Executive Order 14028, the NIST SP 800-53, and the critical resources necessary to build secure cloud products is highlighted by a few facts.

1. The United States Inspector General determines the overall metrics gathered and used to determine FISMA compliance.
2. NIST, as the agency, provides through research a catalog of controls and an array of resources we, the public, use to meet those legal requirements.
3. While conformity assessments such as FedRAMP and NIST 171 (a.k.a. CMMC 2.0 or SPRS) tailor controls and assign them to baselines, the IG and the President of the United States have now mandated that products as related to any particular Software Bill of Material (SBOM) and any component level vulnerabilities associated to the end-to-end delivery of that service, be remediated prior to and throughout the course of business with the Federal Government.
4. Regardless of passing or not passing the audit, the Federal Acquisition Regulation and Defense Federal Acquisition Regulation Supplement (DFARS) will approve or deny contracts based on their determination of its risk or suitability to government purposes.

As of January 2022, there are four months left before mandatory EO 14028 takes effect. Companies can't afford to waste any more time. ^[xxiii]

The United States, Executive Order 14028, Improving the Nation's Cybersecurity, is an unforgiving directive for Suppliers and Consumers of Cloud-based products. DFARS will require more vendors to attest at higher rates than basic self-scored assessment. By May of 2022, any Vendor selling a technology product can expect Agencies to require evidence of a NIST 171 Assessment and a “Software Bill of Materials” or “SBOM”. The various components used in building software will require evidence to substantiate remediation for all found weaknesses in that product's POA&M. As stated in the EO, “It is analogous to a list of ingredients on food packaging. An SBOM is useful to those who develop or manufacture software, those who select or purchase software, and those who operate the software.” It is important to note that Evidence Collection^[xxiv] is already required by law, and since the enactment of the ‘‘Foundations for Evidence-Based Policymaking Act of 2018’’ adherence to the Inspector General FISMA Reporting Measures v1.1 (cisa.gov) ^[xxv], is no longer a suggestion. When selecting the alignment of NIST SP 800-53 control language towards the validation of a product’s implemented policies, Vendors must prioritize Sec. 4. Enhancing Software Supply Chain Security, stating that “Such guidance shall include standards, procedures, or criteria regarding:

(i) secure software development environments, including such actions as:
(A) using administratively separate build environments.
(B) auditing trust relationships.
(C) establishing multi-factor, risk-based authentication, and conditional access across the enterprise.
(D) documenting and minimizing dependencies on enterprise products that are part of the environments used to develop, build, and edit software.
(E) employing encryption for data; and
(F) monitoring operations and alerts and responding to attempted and actual cyber incidents.
(ii) generating and, when requested by a purchaser, providing artifacts that demonstrate conformance to the processes set forth in subsection (e)(i) of this section.
(iii) employing automated tools, or comparable processes, to maintain trusted source code supply chains, thereby ensuring the integrity of the code.
(iv) employing automated tools, or comparable processes, that check for known and potential vulnerabilities and remediate them, which shall operate regularly, or at a minimum prior to product, version, or update release.
(v) providing, when requested by a purchaser, artifacts of the execution of the tools and processes described in subsection (e)(iii) and (iv) of this section and making publicly available summary information on completion of these actions, to include a summary description of the risks assessed and mitigated.
(vi) maintaining accurate and up-to-date data, provenance (i.e., origin) of software code or components, and controls on internal and third-party software components, tools, and services present in software development processes, and performing audits and enforcement of these controls on a recurring basis.
(vii) providing a purchaser, a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website.
(viii) participating in a vulnerability disclosure program that includes a reporting and disclosure process.
(ix) attesting to conformity with secure software development practices; and
(x) ensuring and attesting, to the extent practicable, to the integrity”

Companies using Cloud Security management software will have an easier time meeting these requirements. EnterpriseGRC Solutions offers that anyone looking to improve their Cloud Product Development health considers SD Elements, offered by Security Compass. Using this product alleviates the burden of proving the completeness and health of the SBOM and involves using NIST and other software frameworks to shift compliance requirements left so they are handled long before they become a barrier to your company earning business with the United States Government.

Excuse me. Can you please shift to the left?

Compliance with NIST is complicated. Compliance requires strategy, training, project management, assessment events, and continuous program monitoring. Borrowing from the Software Industry’s “Shift Left”, compliance must occur prior to and as part of any development project. Compliance must exist in every CI/CD [xxvi] and refresh with each Authorization to Operate, or ATO [xxvii].

The way we deal with constantly evolving sets of regulatory requirements, therefore, is to “Shift Compliance Left”. Different from the initial Shift Left, a practice intended to find and prevent defects early in the software delivery process[xxviii], to Shift the responsibilities for Compliance Left requires a dynamic facility to select only the necessary regulatory and compliance outcomes. Using the actual SBOM, risks associated with the boundaries of a system would include an actual set of configurations and methodologies required by the system’s architecture. Driving off requirements adjusted to the SBOM, the system would generate tasks. With clear and properly scoped requirements, compliance would no longer be or would become less of a barrier to an Agile Software as a Service (SaaS) lifecycle.

To do this effectively, responsibility for implementing control tasks, for just-in-time compliance training, and for continuous monitoring or maintaining of evidence for corresponding controls would happen through a well-organized and OSCAL [xxix] facilitated system. Based on the risks unique to the subject or collective components, the mechanism would apply correct Open Vulnerability and Assessment Language OVAL [xxx] (or JOVAL) in accordance with the Security Content Automation Protocol Validation Program (SCAP)[xxxi] compliance checks. The system would rate, register, and assign a set of required remediations. Programs that are purpose-built to facilitate compliance would assign specific evidence-based tasks and responsibilities. The system would maintain a capability to coordinate the necessary Supply Chain and extend the most current regulatory considerations throughout the lifetime of that product or service. (Ideally.)

Governance Risk and Compliance (GRC) solutions generally meet the needs of most organization-based policy lifecycles. Where these programs routinely fail is in the engineering realm and the rapid continuous deployment of Cloud Products. GRC Systems are notoriously weak where weakness is most often introduced, namely through the Supply Chain and through associated technology-based components that shipped but never had their vulnerabilities addressed.

Consider the massive size and complexity of NIST content and the challenge of applying the correct standards, practices, and regulations by component, data type, and target. Where Shift Left had merely aimed to improve quality by moving associated software vulnerability tasks earlier in the process, what we need today combines Just-in-Time training across the entire Privacy Information Management Systems (PIMS)[xxxii] and captures evidence at every phase of the Product and Service. To Shift Compliance Left involves a means to both forecast what will be required and to capture evidence of applying the right industry guidance to every component as it is served.

Apply a Massive Number of controls in a Myriad of Contexts

We tackle complexity and context through industry verified and uniformly tagged evidence-based tasks that organically tie to each regulatory requirement. We use NIST SP 800-53 Controls as a mediating framework because SP 800-53 offers a risk-based context to tag and map to everything else.

Let’s begin to understand the components of NIST SP 800-53, visiting them in their home at NIST Risk Management Framework | CSRC. NIST (The Agency) maintains Federal Information Security Modernization Act (FISMA) information regarding E-Government Act (Public Law 107-347) and the Office of Management and Budget (OMB) Circular A-130, “Managing Federal Information as a Strategic Resource.” 

When evaluating a product, we take initial steps to explore and available guidance for Security Configuration Settings. [xxxiii] “As part of a holistic risk management strategy and applying the information security concept of defense-in-depth, organizations should employ appropriate configuration settings on commercial information technology products. These products include, for example, mainframe computers, workstations, portable and mobile devices, and network components. Requirements to establish mandatory configuration settings derive from the Federal Information Security Management Act as implemented by FIPS 200 and NIST Special Publication 800-53 (Control CM-6, Configuration Settings), and OMB Policy.”

The following publicly available links provide critical information for organizations implementing authorized configuration settings for all scoped system components:

• Security Content Automation Protocol
• US Government Configuration Baseline

In addition to the control catalog, users should explore the Control Overlay Repository. The control overlays address unique risks and requirements of specialized industries and their systems. NIST Security and Privacy Control Overlay Repository (SCOR) provides stakeholders a “platform for voluntarily sharing control overlays created by subject matter experts to help reduce the duplication of effort and share best practices for the information security and privacy community.” Review the Government-wide Overlay Submissions and NIST-developed Overlay Submissions.

Finally, visit the section titled Downloads. NIST content exists in XML, PDF, CSV, MS Excel, XSLT, and OSCAL.

The Fundamentals of NIST 800-53

Source Matters

No matter what you want to understand about NIST, begin at the COMPUTER SECURITY RESOURCE CENTER. While the Downloads and Notification mechanisms for the SP 800-53 provide the current and complete version-controlled content CSRC serves related information used for scoping, the overlays, all referenced regulatory requirements, related standards, and links to everything necessary in providing a "package" of materials & evidence used for any type of conformity assessment. NIST Special Publications SP 800-53 rev 5 and SP 800-53B (FedRamp) contain additional background, scoping, and implementation guidance. Relative to the growing demands and complexities of the most recent changes to the law and NIST guidance, the CSRC NIST SP 800-53 Revision 5, Security and Privacy Controls for Information Systems and Organizations is the one place where all associated reference content is consistently and continuously updated and mapped. The CSRC interface includes the materials necessary to fully implement control processes as determined by their type of conformity, risk rating (baseline), and technical context.

The 800-53 is part of the six steps in the Risk Management Framework, step two, selecting controls. The process to evaluate the enterprise risk and categorize systems always precedes the selection of controls. Historically, the intended use for NIST SP 800-53 was exclusively Federal Systems, but today this framework is "the catalog" and assessment models "derive" their controls from it. The catalog serves as an index to determine which are the other necessary implementation and assessment standards. These other requirements may appear as related SP, IR, FIPS, or government and US regulations. As part two of the RMF wheel, note that step four, Assessment, uses 800-53B, followed by step five requiring monitoring frameworks such as the 800-137 and the "ConMon" which is associated to the FedRAMP PMO aspects of the 800-53B. Assessment cycles, be they annual or triennial return each year to the FIPS 199 for risk impact analysis and the 800-60 for the proper categorization of systems. 800-53 is part two of the continuous cycle of Government Regulatory Compliance.

The Control Catalog

NIST compliance is a verb. We implement controls through an array of associated and related tasks and then validate their effectiveness and related problems through their testing.

Beneath the Domain and Control, the framework's third tier is identified as its 710 "enhancements", or as in NIST 800-171 as the 110 "requirements". Third-tier objects represent the context-specific detail-level implementation. Information associated with the control's Control ID, or with the enhancement's Enhancement ID includes test plans, exceptions, Plan of Action and Milestone (POA&M) records, findings, and evidence collections. This catalog of extensible and tagged content is consumed by instances of Assessment Plans, System Security Plans, with its item records assigned or unassigned according to tailoring criteria established by the Control Baseline (800-53B) and further refined by the risk profile (800-37), boundaries (800-60), previous audit results (800-137), and the entity-based risk conditions for each assessment. 

The following image is one of the models presented by OSCAL. If this is your main area of interest, take a moment to review this outstanding OSCAL training delivered by NIST on February 2, 2021.  This link will download a PDF from nist.gov Presentation: OSCAL Content - NIST | More at Learning Resources (nist.gov)

NIST 800-53 r5 defines "security control and privacy control" as "The means of managing risk, including policies, procedures, guidelines, practices, or organizational structures, which can be of an administrative, technical, management, or legal nature." Concretely, NIST SP 800-53 r5 has 20 Domains, 298 Controls, 720 Enhancements, and 400 Supporting NISTIR, FIPS, and SP reference documents. 18 out of the 20 “Families” are defined in FIPS 200. Two of the Revision 5 families, PT - PERSONALLY IDENTIFIABLE INFORMATION PROCESSING AND TRANSPARENCY and SR - SUPPLY CHAIN RISK MANAGEMENT exist since the transition from Revision 4 to Revision 5.

“Controls” inherit naming properties from their parent domain/family. In the case of NIST 800-53, these are the 20 Control Families. Within the control families, there are 298 active (as opposed to withdrawn) controls. The number of active v. inactive controls and enhancement changes with each revision. The most recent transition from revision 4 to revision 5 added, withdrew, or substantially altered 268 controls and enhancements. The 800-53B, also known as the FedRAMP v4 is slated to update to 800-53C (FedRAMP v5) in May of 2022 with an increase of 17 or more moderate baseline controls.

Figure: NIST OSCAL: represents the portion of the OSCAL stack as it relates to an OSCAL Assessment Results.

Mapping and Tagging

Due to the proliferation of frameworks required by any one entity, organizations often map and associate similar controls. For example, the array of system-specific requirements found in CIS Benchmarks or DISA STIGS might collectively roll up to Access Control and Configuration Control requirements at the level of NIST 800-53. We map common problems with their similar design, testing, and monitoring tasks, and maintain a dashboard to show the current state and periodic effectiveness of their aggregate environment. NIST documentation provides "crosswalks" and mapping appendixes for this reason. Companies with more detailed cloud service offerings will invest in research teams who can extend that mapping to real-time development and systems management. Generally speaking, regardless of which frameworks we use, there is an objective or control that is measured according to an assessment model. Depending on the depth of your assessment, these control objectives need to tie out to the components of any product or service designed or in use.

Most standards (reference document) have a three-tier high-general, medium-specific, low-context and technology-driven, hierarchy. For each reference document, there are major sections also known as domains or families, followed by controls, and including details known as enhancements or requirements. (See Families) 

Nationally recognized standards are expressed as a schema communicated via XML, JSON, and or YAML. The schema includes the record attributes and their relationship to each other. In the case of SP 800-53, the schema is available via NIST GitHub repository https://github.com/usnistgov and https://github.com/usnistgov/oscal-content.

SP 800-53 Family ID appears as two uppercase letters, more commonly representing two main words of the Family, such as CM for Configuration Management or AC for Access Control. With 298 Control Names, across 20 Families, the array is numbered as [:upper:][:upper:]-[:digit:]. The use of this two-letter dash number notation or Control ID tag is prevalent in STIGS, Baselines, the CSF tools, and frequently appears as mapped in appendixes within all major ISO and NIST publications.

Software and Cloud Vendors have a tall task in keeping their references and notation current, which is why this paper emphasizes using OSCAL and maintaining well-formed tags that correspond to the latest NIST referencing. SP 800-53 Rev 5.1 and SP 800-53B begins as a set of the top-level Control Families, a base hierarchy also used in the organization of SP 800-171 and SP 800 172. In the case of the online SP 800-53, the 20 Control Families link or drill to the current 298 Controls, and their 710 Enhancements. When accounting for previously withdrawn Controls and Enhancements, the full standard has 1189 elements. As of 2021, 182 SP 800-53 Controls and Enhancements are withdrawn and incorporated to other parts of the catalog since release in February of 2005.

The Control ID notation uses two letters from the Family Control Name (for example AC, IR, PT) followed by a dash and a number. Each Control has as few as zero Enhancements and currently as many as 33, as for example enhancements SA-8(33). Enhancements appear as the Control ID followed by no space and a number in parenthesis.

The following table shows Control Families in the SP 800-53 Note that each control family is linked to its CSRC record.

Table 2 NIST 800-53 Rev.5 Control Families (These are linked to their CSRC page)

Deep Dive into SA-8

Let’s review one Control Family and then drill into its related part. Cloud providers should focus on the controls most likely to raise flags in the FAR/DFARS process. A control that has the potential to be overlooked and should not is the SA domain and in particular SA-8 Security and Privacy Engineering Principles. We know that the moderate baseline for FedRAMP and the scope of controls for NIST 171 Assessment haven't caught up with the IG's most recent monitoring mandate. Rather than suffer late in the acquisition process, cloud providers can use Cloud Control Management software (such as Security Compass SD Elements) to assign tasks that enable the evidence and readiness of their secure cloud product.

“SA” System and Services Acquisitions. Observe column headers in Green with the column referencing scoped Control ID and Control Enhancement ID assigned to the SP 800-53B FedRamp Assessment based according to their Baselines for Low Impact, Medium Impact, or High Impact, and for Privacy.

Figure: CSRC Control Family System and Services Acquisition

The CSRC online record SA-8 Security and Privacy Engineering Principles appear as assigned to all Baselines but only one of the thirty-three enhancements associated with evidence collected for the Privacy Baseline, SA-8(33). To conclude these tasks are not necessary would likely lead to issues down the line when attempting to defend the maturity of a cloud product. Building these tasks into a "Shift Left" approach would avoid future problems when asked to defend meeting the new EO 14028 requirements. 

SA-8 is part of the SaaS development lifecycle and includes the stages specification, design, development, implementation, and modification. One can imagine the difficulty in deciding when and how to tag Cloud Product lifecycle tasks. Many of these enhancements are met through the enforcement of engineering rules such as those found in OWASP, ^[xxxiv] CIS Benchmarks, ^[xxxv] or MITRE ATT&CK®. ^[xxxvi]  NIST controls use parameters [] as a convention to convey how they assign by “system”, “[Assignment: organization-defined systems security and privacy engineering principles]”. Each major System undergoes its own control review. Each system has its own SBOM, and each component of the system is part of an inventory. When DCMA (your Government Contract Administrator) requests further evidence of your SBOMB and all associated POA&M and SSP for your cloud offering, reporting such as that provided in SD Elements from Security Compass will most likely save you.

SBOM results in a configuration array, and evidence includes the use of specific SCAP rules enforced and measured according to their current threat models and baseline best practices.

SA-8 offers thirty-three (33) enhancements collectively contributing to the Engineering of a Secure and Private System. All Enhancements include their description and a discussion regarding their risk and implementation. Controls and Enhancements include the attribute “Related To:” which calls out the other parts of the framework representing the SIPOC (Suppliers, Inputs, Process, Outputs, Customers, Requirements) most often associated with this control outcome.

SA-8 Security and Privacy Engineering Principles - The Enhancements

Table 3 SA-8(3) Enhancement Description Discussion and Related Controls

The Problem with "Teaching to-the-test" and Implementing "to-the-scope"

SA-8 Enhancements aggregate as the organization’s overall Engineering Principles Program, Policy, and implementation activity. If this information is scoped exclusively to the needs of a FedRamp PMO's emphasis on assuring the top-level SA-8 control description, and some evidence of Enhancement 33 "Minimization". Implementing "to-the-scope" of an assessment won't accomplish secure and resilient cloud services. Building compliant cloud products mean leveraging all of the applicable best practice guidance associated with the entire Service and Acquisition domain. Software providers should align with NIST's Secure Software Development Framework (SSDF). A robust Cloud Software Development program is a reasonable way to leverage this guidance. The 800-53 points to using the Secure Software Development Framework, SSDF. It falls to the Cloud Offeror to realize that even if this wasn't suggested by their previous year's NIST 171 or FedRAMP audit, this level of tracking will get called as a requirement for earning and maintaining future government contracts.

• Cybersecurity Labeling for Consumer IoT and Software: Executive Order Update and Discussion (December 9, 2021)
• 2nd Public Draft SP 800-161 Revision 1 Workshop (December 1, 2021)
• Executive Order 14028: Guidelines for Enhancing Software Supply Chain Security (November 8, 2021)
• NIST Seeks Comments on Draft Consumer Software Criteria for Labeling (November 1, 2021)
• Draft NIST SP 800-161 Revision 1 (October 28, 2021)
• Improving the Nation’s Cybersecurity: Progress and Next Steps in Carrying Out Executive Order 14028 (October 14, 2021)
• NIST's Secure Software Development Framework (SSDF) Version 1.1 (September 30, 2021)

Given a facilitated GRC system we Shift these compliance targets Left by tagging not only the 33 Enhancements of SA-8, but the array of CIS, DISA, OWASP and other best practices that collectively assure the safety of the entire cloud service environment. It takes a robust system to tag and track the entire Cloud Development Lifecycle. At the very least, we need a product that enables "Select", "Implement", "Assess", "Authorize" and "Monitor" phases of the RMF. For Vendors who need to show their "SBOM" and validation that all components offered are free of vulnerability, an easy choice would be to use a facilitated program such as offered by Security Compass.

The last comment on the example of SA-8, and probably the most significant point about NIST as a body of collective works. NIST intends all control statements as guidance, not taking the place of organic and complete procedures evolved to suit the actual context of organization as they apply reasonable controls to suit their product. Organizations apply a risk framework based on the threats and priorities of their domains of responsibility. Appearing no less than nineteen times in the SP 800-53, NIST states “Simply restating controls does not constitute an organizational policy or procedure.”

“Security controls are seldom put in place as stand-alone solutions to a problem. They are typically more effective when paired with another control or set of controls. Security controls, when selected properly, can have a synergistic effect on the overall security of a system. Each security control in NIST SP 800-53 has a related controls section listing security control(s) that complement that specific control. If users do not understand these interdependencies, the results can be detrimental to the system. ^[xxxvii]

Another critical dependency between NIST SP 800-53 and May 12, 2021, EO Executive Order on Improving the Nation's Cybersecurity^[xxxviii] is the Inspector General FISMA Reporting Measures v1.1 (cisa.gov). ^[xxxix] System Engineering directly affects Supply Chain Risk. Reading the Inspector General’s evidenced-based assessment guidance it is clear that this SA-8 example is now established by precedent as a necessary marker for a company's achievement of reasonable "defined" maturity.

Question 6. “To what extent does the organization utilize an information security architecture to provide a disciplined and structured methodology for managing risk, including risk from the organization’s supply chain (Federal Information Technology Acquisition Reform Act (FITARA), NIST SP 800-39; NIST SP 800-160; NIST SP 800-37 (Rev. 2) Task P-16; OMB M-19-03; OMB M-15-14, FEA Framework; NIST SP 800-53 Rev. 4: PL-8, SA-3, SA-8, SA-9, SA-12, and PM-9; NIST SP 800-163, Rev. 1 CSF: ID.SC-1 and PR.IP-2; SECURE Technology Act: s. 1326)?”

Figure 2 FY 2021 Inspector General Federal Information Security Modernization Act of 2014 (FISMA) Reporting Metrics Version 1.1 Question 6 page 18 (FY 2021 Inspector General FISMA Reporting Measures v1.1 (cisa.gov))

Conclusion

As the Inspector General and the Federal Acquisition Regulation (FAR) raise scrutiny on all government agency contracts for both the Federal Government and Private sectors, we are increasingly compelled to comply with NIST. NIST supplies industry-led cybersecurity standards, the most widely utilized being the NIST SP 800-53 Rev. 5^[xl] Security and Privacy Controls for Federal Information Systems and Organizations. NIST SP 800-53 is the control matrix that references and mediates connection to all of NISTS other products and resources.

NIST requires that any assessment, including those that leverage the SP 800-53, be implemented according to the Risk Management Framework (RMF). Cloud Service Providers (CSP) and Cloud Service Consumers (CSC) share responsibilities to gather or supply an accurate software bill of materials (SBOM), and with that, to acknowledge the detailed level risks associated at every layer and step along each product’s supply chain. The SBOM now ties to the full Cybersecurity Supply Chain Risk Management C-SCRM ^[xli] and must meet with The United States, Executive Order 14028, Improving the Nation's Cybersecurity.

Organizations can plan, release, and maintain Secure Cloud Products by employing a methodology and facilitated system to Shift Compliance Left. Where the US Supply Chain threat landscape is seen as only tending to a more expansive, dangerous, and complex set of obstacles, the proper use of NIST Standards and products such as Security Compass, SD Elements offers hope.

References

[i] Approaches for Federal Agencies to Use the Cybersecurity Framework (nist.gov), page 11
[ii] Cybersecurity Enhancement Act of 2014 signed into law (Public Law No: 113-274) provides for an ongoing, voluntary public-private partnership to improve cybersecurity, and to strengthen cybersecurity research and development, workforce development, and education, and public awareness and preparedness.
[iii] NIST Risk Management Framework | CSRC
[iv] Subpart 39.1 – General FAR (acquisition.gov)
[v] Cybersecurity Framework | NIST
[vi] National Institute of Standards and Technology (2006) Minimum Security Requirements for Federal Information and Information Systems. (U.S. Department of Commerce, Washington, DC), Federal Information Processing Standards Publication (FIPS) 200. https://doi.org/10.6028/NIST.FIPS.200
[vii] SP 800-53B, Control Baselines for Information Systems and Organizations | CSRC (nist.gov)
[viii] Approaches for Federal Agencies to Use the Cybersecurity Framework (nist.gov), page 16
[ix] List of federal agencies in the United States - Wikipedia
[x] Conformity Assessment Resources for Federal Agencies | NIST
[xi] Get Authorized: JAB Authorization | FedRAMP.gov
[xii] CFR-2017-title32-vol6-part2002.pdf (govinfo.gov)
[xiii] SP 800-53 Rev. 5, Security and Privacy Controls for Info Systems and Organizations | CSRC (nist.gov)
[xiv] CSP Authorization Playbook (fedramp.gov)
[xv] Defense Federal Acquisition Regulation Supplement Microsoft Word - 252204.doc (osd.mil), Rev. Jan. 15, 2009)
[xvi] Compliance with Cybersecurity and Privacy Laws and Regulations | NIST
[xvii] Supply Chain Risk Management Practices for Federal Information Systems and Organizations | NIST
[xviii] Kaseya Ransomware Attack: Guidance for Affected MSPs and their Customers | CISA
[xix] Colonial Pipeline: The DarkSide Strikes (congress.gov)
[xx] US Treasury "Significantly Affected" By SolarWinds Cyberattack - Reactionary Times
[xxi] Executive Order on Improving the Nation's Cybersecurity | The White House
[xxii] NIST SP 800-145, The NIST Definition of Cloud Computing, Software as a Service (SaaS), page two
[xxiii] Approaches for Federal Agencies to Use the Cybersecurity Framework | NIST
[xxiv] PUBL435.PS (congress.gov) ‘‘Foundations for Evidence-Based Policymaking Act of 2018’’
[xxv] FY 2021 Inspector General FISMA Reporting Measures v1.1 (cisa.gov)
[xxvi] CI/CD - Wikipedia In software engineering, CI/CD is the combined practices of continuous integration (CI) and either continuous delivery or continuous deployment (CD)
[xxvii] An Authorization to Operate (ATO) is a formal declaration by a Designated Approving Authority (DAA) that authorizes operation of a Business Product and explicitly accepts the risk to agency operations.
[xxviii] Donald Firesmith (23 March 2015). "Four Types of Shift Left Testing". Archived from the original on 2015-09-05. Retrieved 27 March 2015. (As found on https://en.wikipedia.org/wiki/Shift-left_testing)
[xxix] oscal-content/nist.gov/SP800-53/rev5 at master · usnistgov/oscal-content · GitHub
[xxx] Home / Oval Repository (cisecurity.org)
[xxxi] Security Content Automation Protocol Validation Program | CSRC (nist.gov)
[xxxii] ISO - ISO/IEC 27701:2019 - Security techniques — Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management — Requirements and guidelines
[xxxiii] NIST Risk Management Framework | CSRC Security Configuration Settings Security Content Automation Protocol | CSRC (nist.gov) and United States Government Configuration Baseline | CSRC (nist.gov)
[xxxiv] OWASP Foundation | Open Source Foundation for Application Security
[xxxv] CIS Benchmarks (cisecurity.org)
[xxxvi] MITRE ATT&CK®
[xxxvii] An Introduction to Information Security (nist.gov)
[xxxviii] Executive Order on Improving the Nation's Cybersecurity | The White House
[xxxix] FY 2021 Inspector General FISMA Reporting Measures v1.1 (cisa.gov)
[xl] Approaches for Federal Agencies to Use the Cybersecurity Framework (nist.gov), page 11
[xli] Cybersecurity Supply Chain Risk Management | CSRC (nist.gov)