** JUST TO BE TRANSPARENT, THIS PAGE CONTAINS SPONSORED CONTENT [wink wink nudge nudge - go buy their stuff since they are super awesome]**

Not All NIST 800-171 & CMMC Compliance Documentation Is The Same

Cybersecurity & data protection documentation needs to usable – it cannot just exist in isolation. This means the documentation needs to be written clearly, concisely and in a business-context language that users can understand. By doing so, users will be able to find the information they are looking for and that will lead to cybersecurity and data protection "industry-recognized secure practices" being implemented throughout your organization. Additionally, having clearly-written and concise documentation can be “half the battle” when preparing for an audit or assessment, since it shows that effort went into the program and key requirements can be easily found.

In compliance, there are three (3) key concepts to keep in mind:

1. Words have specific meanings; 
2. If it is not documented, then it does not exist; and
3. Assumptions are a bitch.

1. Words Have Specific Meaning With Cybersecurity Compliance Documentation

Words have specific meanings and your feelings do not matter - what matters is authoritative definitions of the terms. The following content shows definitions from industry-recognized sources for the proper use of these terms that make up cybersecurity & privacy documentation. You can read more about the concepts covered in this section at the Guide To Understanding Cybersecurity & Data Privacy Documentation.

It is disappointing to have to say this, but just because you've seen something used in other organizations or because you found it on the Internet does not mean it is correct. When it comes to cybersecurity compliance, words have specific meaning and it is important to get those terms correct. In reality, these cybersecurity documentation terms have quite different implications and those differences should be kept in mind since the use of improper terminology has cascading effects that can negatively impact the internal controls of an organization.

Cybersecurity, IT professionals, privacy and legal professionals routinely abuse the terms “policy” and “standard” as if these words were synonymous, when they are not! In simple terms, a policy is a high-level statement of management intent that formally establishes requirements to guide decisions and achieve rational outcomes. A policy is intended to come from the CEO or board of directors that has strategic implications. However, a standard is a formally-established requirement in regard to a process, action or configuration that is meant to be an objective, quantifiable expectation to be met (e.g., 8 character password, change passwords every 90 days, etc.). 

• In reality, no one should ever ask for an exception to a policy.
• Exceptions should only be for standards when there is a legitimate business reason or technical limitation that precludes a standard from being followed (e.g., vulnerability scanning exception for a "fragile" application that breaks when scanned by the default scanning profile).
• It is important that if a standard is granted an exception, there should be a compensating control placed to reduce that increased risk from the lack of the required standard (e.g., segment off the application that cannot be scanned for vulnerabilities).

Due to fact that terminology pertaining to cybersecurity documentation is often abused, a simplified concept of the hierarchical nature of cybersecurity documentation is needed to demonstrate the unique nature of these components, as well as the dependencies that exist. The reference model shown below was designed to encourage clear communication by defining cybersecurity documentation components and how those are linked. This model is based on industry-recognized terminology from NIST, ISO, ISACA and AICPA to addresses the inter-connectivity of policies, control objectives, standards, guidelines, controls, assessment objectives, risks, threats, procedures & metrics. This also addresses what SSPs, POA&Ms and secure configurations are and how those integrate into an organization's existing cybersecurity documentation. Click on the image below to download the PDF:

You can visualize the hierarchical nature of these documentation components, where policies are the foundation that everything builds upon:

Cybersecurity Policy

Policies are high-level statements of management intent from an organization’s executive leadership that are designed to influence decisions and guide the organization to achieve the desired outcomes. Policies are enforced by standards and further implemented by procedures to establish actionable and accountable requirements. Policies are a business decision, not a technical one. Technology determines how policies are implemented. Policies usually exist to satisfy an external requirement (e.g., law, regulation and/or contract).

• ISACA Glossary:
• A document that records a high-level principle or course of action that has been decided on.
• The intended purpose is to influence and guide both present and future decision making to be in line with the philosophy, objectives and strategic plans established by the enterprise’s management teams.
• Overall intention and direction as formally expressed by management.
• ISO 704:2009:
• Any general statement of direction and purpose designed to promote the coordinated planning, practical acquisition, effective development, governance, security practices, or efficient use of information technology resources.
• ISO 27000:2016:
• Intention and direction of an organization as formally expressed by its top management.
• NIST Glossary:
• Statements, rules or assertions that specify the correct or expected behavior of an entity.
• A statement of objectives, rules, practices or regulations governing the activities of people within a certain context.
• NIST Glossary (Security Policy):
  • Note 1: System elements include technology, machine, and human, elements.
  • Note 2: Rules can be stated at very high levels (e.g., an organizational policy defines acceptable behavior of employees in performing their mission/business functions) or at very low levels (e.g., an operating system policy that defines acceptable behavior of executing processes and use of resources by those processes).
• Security policies define the objectives and constraints for the security program. Policies are created at several levels, ranging from organization or corporate policy to specific operational constraints (e.g., remote access). In general, policies provide answers to the questions “what” and “why” without dealing with “how.” Policies are normally stated in terms that are technology-independent.
• A set of rules that governs all aspects of security-relevant system and system element behavior.

Cybersecurity Control Objective

Control Objectives are targets or desired conditions to be met. These are statements describing what is to be achieved as a result of the organization implementing a control, which is what a Standard is intended to address. Where applicable, Control Objectives are directly linked to an industry-recognized secure practice to align cybersecurity and privacy with accepted practices. The intent is to establish sufficient evidence of due diligence and due care to withstand scrutiny.

• ISACA Glossary:
• A statement of the desired result or purpose to be achieved by implementing control procedures in a particular process.
• ISO 27000:2016:
• Statement describing what is to be achieved as a result of implementing controls.

Cybersecurity Standard

Standards are mandatory requirements regarding processes, actions and configurations that are designed to satisfy Control Objectives. Standards are intended to be granular and prescriptive to ensure systems, applications and processes are designed and operated to include appropriate cybersecurity and privacy protections.

• ISACA Glossary:
• A mandatory requirement.
• NIST Glossary:
  • Classification of components.
  • Specification of materials, performance, or operations; or
  • Delineation of procedures. 
• A published statement on a topic specifying the characteristics, usually measurable, that must be satisfied or achieved to comply with the standard.
• A rule, condition, or requirement describing the following information for products, systems, services or practices:

Cybersecurity Guideline / Supplemental Guidance

Guidelines are recommended practices that are based on industry-recognized secure practices. Guidelines help augment Standards when discretion is permissible. Unlike Standards, Guidelines allow users to apply discretion or leeway in their interpretation, implementation, or use.

• ISACA Glossary:
• A description of a particular way of accomplishing something that is less prescriptive than a procedure.
• ISO 704:2009:
• Recommendations suggesting, but not requiring, practices that produce similar, but not identical, results.
• A documented recommendation of how an organization should implement something.
• NIST Glossary:
• Statements used to provide additional explanatory information for security controls or security control enhancements.

Cybersecurity Control

Controls are technical, administrative or physical safeguards. Controls are the nexus used to manage risks through preventing, detecting or lessening the ability of a particular threat from negatively impacting business processes. Controls directly map to standards, since control testing is designed to measure specific aspects of how standards are actually implemented.

• ISACA Glossary:
• The means of managing risk, including policies, procedures, guidelines, practices or organizational structures, which can be of an administrative, technical, management, or legal nature.
• ISO 27000:2016:
  • Controls include any process, policy, device, practice, or other actions which modify risk.
  • Controls may not always exert the intended or assumed modifying effect.
• The policies, procedures, practices and organizational structures designed to provide reasonable assurance that business objectives will be achieved and undesired events will be prevented or detected and corrected.
• Measure that is modifying risk:
• NIST Glossary:
• Measure that is modifying risk. (Note: controls include any process, policy, device, practice, or other actions which modify risk.)
• NIST SP 800-53 R5:
• The safeguards or countermeasures prescribed for an information system or an organization to protect the confidentiality, integrity, and availability of the system and its information [security control].
• The administrative, technical, and physical safeguards employed within an agency to ensure compliance with applicable privacy requirements and manage privacy risks [privacy control].

Cybersecurity Procedure

Procedures are a documented set of steps necessary to perform a specific task or process in conformance with an applicable standard. Procedures help address the question of how the organization actually operationalizes a policy, standard or control. Without documented procedures, there can be defendable evidence of due care practices. Procedures are generally the responsibility of the process owner / asset custodian to build and maintain but are expected to include stakeholder oversight to ensure applicable compliance requirements are addressed. The result of a procedure is intended to satisfy a specific control. Procedures are also commonly referred to as “control activities.”

• ISACA Glossary:
• A document containing a detailed description of the steps necessary to perform specific operations in conformance with applicable standards. Procedures are defined as part of processes.
• ISO 704:2009:
• A detailed description of the steps necessary to perform specific operations in conformance with applicable standards.
• A group of instructions in a program designed to perform a specific set of operations.
• NIST Glossary:
• A set of instructions used to describe a process or procedure that performs an explicit operation or explicit reaction to a given event.

Secure Baseline Configurations / Hardening Standard

Secure baseline configurations (e.g., hardening standard) are technical in nature and specify the required configuration settings for a
defined technology platform. Leading guidance on secure configurations tend to come from:

• Center for Internet Security (CIS) Benchmarks;
• Defense Information Systems Agency (DISA) Security Technical Implementation Guides (STIGs); and/or
• Original Equipment Manufacturer (OEM) recommendations.

• NIST Glossary:
• A documented set of specifications for an information system, or a configuration item within a system, that has been formally reviewed and agreed on at a given point in time, and which can be changed only through change control procedures.
• A set of specifications for a system, or Configuration Item (CI) within a system, that has been formally reviewed and agreed on at a given point in time, and which can be changed only through change control procedures. The baseline configuration is used as a basis for future builds, releases, and/or changes.

Risk Register / Plan of Action & Milestones (POA&M)

A POA&M is a “living document” that summarizes control deficiencies from identification through remediation. A POA&M is essentially a risk register that tracks the assignment of remediation efforts to individuals or teams, as well as identifying the tasks and resources necessary to perform the remediation.

• NIST Glossary:
• Risk Register: A repository of risk information including the data understood about risks over time.
• Risk Register: A central record of current risks, and related information, for a given scope or organization. Current risks are comprised of both accepted risks and risk that are have a planned mitigation path (e.g., risks to-be-eliminated as annotated in a POA&M).
• POA&M: A document that identifies tasks that need to be accomplished. It details resources required to accomplish the elements of the plan, milestones for meeting the tasks, and the scheduled completion dates for the milestones.

System Security Plan (SSP) / System Security & Privacy Plan (SSPP)

A SSP/SSPP is a “living document” that summarizes protection mechanisms for a system or project. It is a documentation method used to capture pertinent information in a condensed manner so that personnel can be quickly educated on the “who, what, when, where, how & why” concepts pertaining to the security of the system or project. A SSP/SSPP is meant to reference an organization’s existing policies, standards and procedures and is not a substitute for that documentation.

• NIST Glossary:
• Formal document that provides an overview of the security requirements for an information system and describes the security controls in place or planned for meeting those requirements.

Cybersecurity Risk

Risks represents a potential exposure to danger, harm or loss.* Risk is associated with a control deficiency (e.g., If the control fails, what risk(s) is the organization exposed to?). Risk is often calculated by a formula of Threat x Vulnerability x Consequence in an attempt to quantify the potential magnitude of a risk instance occurring. While it is not possible to have a totally risk-free environment, it may be possible to manage risks by avoiding, reducing, transferring, or accepting the risks.

• ISACA Glossary:
• The combination of the probability of an event and its consequence.
• ISO 704:2009:
• The level of impact on organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, or the Nation resulting from the operation of an information system given the potential impact of a threat and the likelihood of that threat occurring.
• NIST SP 800-53 R5:
  • The adverse impact, or magnitude of harm, that would arise if the circumstance or event occurs; and
  • The likelihood of occurrence.
• A measure of the extent to which an entity is threatened by a potential circumstance or event, and typically is a function of:
• NIST Glossary:
  • The adverse impacts that would arise if the circumstance or event occurs; and
  • The likelihood of occurrence. Information system-related security risks are those risks that arise from the loss of confidentiality, integrity, or availability of information or information systems and reflect the potential adverse impacts to organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, and the Nation.
• A measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of:

Cybersecurity Threat

Threats represents a person or thing likely to cause damage or danger. Natural and man-made threats affect control execution (e.g., if the threat materializes, will the control function as expected?). Threats exist in the natural world that can be localized, regional or worldwide (e.g., tornados, earthquakes, solar flares, etc.). Threats can also be manmade (e.g., hacking, riots, theft, terrorism, war, etc.).

• ISACA Glossary:
• Anything (e.g., object, substance, human) that is capable of acting against an asset in a manner that can result in harm.
• ISO 13335-1:
• A potential cause of an unwanted incident.
• NIST Glossary:
• Threat: Any circumstance or event with the potential to adversely impact organizational operations (including mission,
  functions, image, or reputation), organizational assets, or individuals through an information system via unauthorized
  access, destruction, disclosure, modification of information, and/or denial of service. Also, the potential for a threatsource to successfully exploit a particular information system vulnerability.
• Cyberthreat: Any circumstance or event with the potential to adversely impact organizational operations (including
  mission, functions, image, or reputation), organizational assets, individuals, other organizations, or the Nation through
  an information system via unauthorized access, destruction, disclosure, modification of information, and/or denial of
  service.

Cybersecurity Metric

Metrics provide a “point in time” view of specific, discrete measurements, unlike trending and analytics that are derived by comparing a baseline of two or more measurements taken over a period of time. Analytics are generated from the analysis of metrics. Analytics are designed to facilitate decision-making, evaluate performance and improve accountability through the collection, analysis and reporting of relevant performance related data. Good metrics are those that are SMART (Specific, Measurable, Attainable, Repeatable, and Time-dependent).

• ISACA Glossary:
• A quantifiable entity that allows the measurement of the achievement of a process goal.
• ISO 704:2009:
• A thing that is measured and reported to help with the management of processes, services, or activities.
• NIST Glossary:
• Tools designed to facilitate decision making and improve performance and accountability through collection, analysis, and reporting of relevant performance-related data.

2. When It Comes To A Cybersecurity Assessment / Audit, If It Is Not Documented, Then It Does Not Exist

Walking into an audit/assessment without appropriate evidence of due diligence and due care is a guaranteed way to fail. This goes back to the old adage, "If you fail to plan, then you plan to fail!" Without having evidence of your cybersecurity program, an honest assessor will be left with no recourse but to find all those associated controls deficient, since they cannot take your word for it. If it is not documented, then it doesn't exist to an auditor/assessor.

Evidence artifacts (e.g., written documentation) provides proof of your due care and due diligence activities. For example:

• Example Due Diligence Activities:
• Researching applicable laws, regulations and contractual obligations to define necessary cybersecurity and data protection controls;
• Writing properly-scoped policies, standards, procedures, etc. (e.g., company-specific requirements adhere to compliance obligations);
• Defining what sensitive/regulated data (e.g., CUI, FCI, etc.) is shared with your organization and why (e.g., contract reviews, data flow diagrams, etc.);
• Scoping your environment by documenting where sensitive/regulated data is stored, processed, and/or transmitted on the network (e.g., network diagrams, data inventories, etc.);
• Creating an Incident Response Plan (IRP);
• Creating a Cybersecurity Supply Chain Risk Management (C-SCRM) Plan; and
• Creating a Shared Responsibility Matrix (SRM) to identify roles and responsibilities for all internal and third-party stakeholders.
• Example Due Care Activities:
• Performing ongoing reviews to determine if your cybersecurity program is scoped properly (e.g., changes in laws, regulations, contracts, technologies, etc.);
• Performing annual reviews on policies, standards, procedures, SSPs, etc. to ensure they are accurate and support business operations;
• Performing ongoing reviews of what sensitive/regulated data is and where it is being stored, processed and/or transmitted;
• Validating/updating scoping documentation to ensure it is still accurate;
• Performing testing on IRPs and ensuring incident responders are trained on their roles, as well as updating IRPs when things change; 
• Performing third-party risk assessments to ensure your supply chain is secure and not leaving your organization exposed to unnecessary risk; and
• Validating/updating SRMs as business factors change (e.g., personnel changes, new/different vendors, etc.).

3. Assumptions Are A Bitch When It Comes To Compliance

Since you are on this website, you are clearly interested in complying with NIST 800-171 and CMMC. If you have DFARS or FAR obligations as a prime or sub-contractor, that means NIST 800-171 & CMMC are "must have" requirements. Given that NIST 800-171 only focuses on Confidentiality and Integrity, the entire concept of Availability is out-of-scope and that potentially leaves a gaping hole in your overall cybersecurity and data protection program. Why is this important? Given our experience, there is a high probability that your organization has to comply with more than just NIST 800-171 & CMMC. The reality is that while there are other obligations, only the DoD is really knocking on your door for evidence of compliance. However, that does not mean that you can ignore other statutory, regulatory and/or contractual obligations simply because no one is demanding evidence of compliance. 

This is where assumptions are very dangerous and there is a need to understand and clarify the difference between "compliant" versus "secure" since that is necessary to have coherent risk management discussions. To assist in this process, you can distill requirements into “must have” vs “nice to have” requirements:

• Minimum Compliance Requirements (MCR) are the absolute minimum requirements that must be addressed to comply with applicable laws, regulations and contracts.
• Discretionary Security Requirements (DSR) are tied to the organization’s risk appetite since DSR are “above and beyond” MCR, where the organization self-identifies additional cybersecurity and data protection controls to address voluntary industry practices or internal requirements, such as findings from internal audits or risk assessments.

Secure and compliant operations exist when both MCR and DSR are implemented and properly governed:

• MCR are primarily externally-influenced, based on industry, government, state and local regulations (e.g., NIST 800-171, CMMC, HIPAA, PCI DSS, GLBA, etc.). MCR should never imply adequacy for secure practices and data protection, since they are merely compliance-related.
• DSR are primarily internally-influenced, based on the organization’s respective industry and risk tolerance (e.g., MFA, DLP, enhanced background checks, etc.). While MCR establish the foundational floor that must be adhered to, DSR are where organizations often achieve improved efficiency, automation and enhanced security.

 The bottom line understanding is that when it comes to compliance, you have to take a holistic view of your requirements and implement a risk-based, prioritized approach to addressing those compliance obligations. Not doing so opens your organization up to negligence, which gets into dicey legal territory and possible insurance loopholes where you may void coverage for negligent behavior.

 

  ** SPONSORED CONTENT **

ComplianceForge is an industry-leader in NIST 800-171 compliance documentation and has been evolving their DFARS-specific cybersecurity solutions since 2016. ComplianceForge specializes in cybersecurity compliance documentation and their products include the policies, standards, procedures and POA&M/SSP templates that companies (small, medium and large) need to comply with NIST 800-171. They've been writing cybersecurity documentation since 2005 and their solutions help make NIST 800-171 compliance as easy and as affordable as possible.