-
Patching your People with Rev Three ODPs
I don’t have a naughty nature, so I will refrain from ODP puns and discuss how Patching your People through your Security Training program needs to evolve with the transition to NIST-SP-800-177 Rev 3 from Rev 2.
NIST SP 800-171 Revision 3 introduces both theoretical and operational changes to the Awareness and Training family. Over the years the emphasis on training becomes stronger and stronger while we spend more assuming breach and expecting systems have already failed. We know over 80% of breaches begin with your people. Revision three of NIST-SP-800 171 went beyond the general requirements found in Revision 2. Revision 3 replaces the general awareness requirement with security literacy training.
This new theoretical definition seeks to emphasize that personnel must not only complete security information training but must understand and be able to apply foundational security knowledge.
Literacy as Security or GRC = General Reading Comprehension
Scholars and nerds have used the word “literacy” for differentiating applied knowledge and contrasting this with declarative knowledge for a long time. Basically knowing and doing = literacy. Sylvia Scribner in her 1984 piece “Literacy in Three Metaphors” kicked off the trend and argued literacy does not have a single, context-free essence. She analyzed three metaphors:
- Literacy as adaptation — the skills needed to function effectively in everyday life.
- Literacy as power — the capacity to analyze conditions and act upon them.
- Literacy as a state of grace — literacy as intellectual, cultural, or personal development.
The first metaphor finds a home wit compliance and NIST. Under the adaptation model, literacy allows functioning in a particular social and technological environment.
Think about stuff like:
- security literacy
- health literacy
- financial literacy
- scientific literacy;
- information literacy
- digital literacy
In 1999 the National Research Council published, “Being Fluent with Information Technology.” The committee deliberately preferred fluency over basic “computer literacy.” It described information-technology fluency as having three interconnected components:
- contemporary skills — the ability to use current technological tools
- foundational concepts — understanding the enduring principles underlying technology
- intellectual capabilities — the ability to reason about information, manage complexity, solve problems, and adapt knowledge to new situations
The NIST definition included in NIST-SP-800-53, which spawned the revision to 171, best aligns with theoretical constructs similar to Yoram Eshet-Alkalai’s,“Digital Literacy: A Conceptual Framework for Survival Skills in the Digital Era,” which was published in 2004.
Folks would make academic careers writing pieces debating if we really meant technology fluency or literacy (technically my PhD was from the New Literacies Research Lab…we really stretched the metaphor).
Training Roots
The emphasis gets placed on functioning effectively, not possessing declarative knowledge alone. NIST baked this functional definition of security literacy in long-standing awareness-and-training model in SP 800-50 and SP 800-16.The original NIST SP 800-16 (1998) contains a section expressly titled “3.1 Definition and Purpose.” which defines IT security literacy as:
“An individual’s familiarity with—and ability to apply—a core knowledge set…needed to protect electronic information and systems.” definition fits squarely within these broader educational traditions.
It defined IT security literacy as familiarity with and the ability to apply a core knowledge set needed to protect information and systems.The first version of SP 800-50 contained descriptive definitions in Chapter 2, although it did not use “literacy training” as a principal formal term. It distinguishes the learning continuum as following awareness, training, education, and professional development
NIST publication Concept Meaning NIST SP 800-53 Rev. 5 — AT-2 Literacy Training and Awareness Foundational security and privacy learning for system users, delivered initially, recurrently, and when changes or events require it. Users learn why security matters, what actions they must take, and how to respond to suspected incidents. NIST SP 800-50 Rev. 1 — Appendix B Awareness Training The foundational cybersecurity or privacy training program for all personnel. It helps learners understand their role in protecting information, cybersecurity, and privacy-related assets. SP 800-50 Rev. 1 expressly notes that this is called “literacy” training in SP 800-53 Rev. 5. NIST SP 800-16 — Chapters 2–3 Security Basics and Literacy An individual’s familiarity with—and ability to apply—a core knowledge set needed to protect electronic information and systems. Security literacy represents the transition between passive awareness and specialized, role-based training. CyberDI Security Literacy The ability to understand and apply foundational security knowledge so a person can recognize risk, protect information and systems, and take the correct action in context. Literacy in Action
This concept of security literacy training gets operationalized through role based training. This now reflects a more lifecycle approach. Revision 2 required organizations to make managers, system administrators, and users aware of security risks and applicable security requirements; train personnel to perform their assigned security duties and provide awareness training on recognizing and reporting potential insider-threat indicators. Revision 3 incorporates the former standalone insider-threat requirement into this broader literacy requirement rather than eliminating it.
The assessment objectives in NIST-SP-800-171a call for some evidence of measuring a users’ knowledge and identifies continuing awareness activities that reinforce literacy. These can include advisories, login messages, videos, webinars, and other awareness events.The revisions also call for specific content. A training must address the actions users are expected to take to maintain security. Rev 3 includes explicit requirements to train employees to respond to incidents and protect CUI. They must continue, like Rev 2 to recognize and report indicators of insider threats. Revision three does explicitly add social engineering and social mining as required content.
Awareness and Training: CMMC Rev. 2 to Rev. 3 Crosswalk Rev. 2 Requirement Rev. 2 Focus Rev. 3 Requirement Rev. 3 Focus Change 3.2.1 Ensure managers, system administrators, and users understand the security risks associated with their activities and the applicable policies, standards, and procedures. 03.02.01 — Literacy Training and Awareness Provide and periodically update security literacy training. Training includes recognizing and reporting insider threats, social engineering, and social mining. Expands general awareness into recurring security literacy training with defined content, update requirements, and event-driven training. 3.2.2 Ensure personnel are trained to perform their assigned information security duties and responsibilities. 03.02.02 — Role-Based Training Provide training before personnel receive access or perform assigned security roles, and repeat training at an organization-defined frequency and following specified changes or events. Adds explicit timing, frequency, role-based content, and training-update requirements. 3.2.3 Provide security awareness training on recognizing and reporting indicators of insider threat. 03.02.03 — Withdrawn and incorporated into 03.02.01 Insider-threat recognition and reporting are included within Literacy Training and Awareness under 03.02.01. The requirement is retained but consolidated with general security literacy training rather than maintained as a separate requirement. Security Literacy and Organizational Defined Parameters
One of the biggest changes to the training family involves frequencies and triggers. Under Revision 2 an organization assigned frequency and just needed to prove the rules got followed. In Rev 3 the annual requirement remains but specific triggers for content update were added to organizational defined parametersOverall, the change from Revision 2 to Revision 3 moves awareness and training from a relatively static, compliance-oriented activity toward a continuous, role-sensitive learning program. Organizations must now define training frequencies and triggering events, periodically review and update course content, and revise training after events such as system changes, audit findings, incidents, changes in threats, or changes to applicable requirements. The practical expectation is no longer satisfied merely by assigning an annual awareness course and retaining a completion record.
Organizations should be able to demonstrate that training is timely, relevant to their environment and CUI-handling practices, appropriate to each person’s responsibilities, reinforced through continuing awareness activities, and effective in developing the knowledge personnel need to recognize risks and act securely.
NIST SP 800-171 Rev. 2 and NIST SP 800-171 Rev. 3.
NIST SP 800-171 Rev. 3 — 03.02.01 Literacy Training and Awareness ODPs Requirement Objective Organization-Defined Parameter Assigned Value 03.02.01 03.02.01.a.01 Frequency after initial security literacy training Annually 03.02.01 03.02.01.a.02 Events requiring additional security literacy training - Significant changes
- Incidents or breaches
- Legal, regulatory, or contractual changes
- Audit or assessment findings
- Material threat changes
03.02.01 03.02.01.b.01 Frequency for reviewing and updating security literacy training content Annually 03.02.01 03.02.01.b.02 Events requiring security literacy training content updates - Significant changes
- Incidents or breaches
- Legal, regulatory, or contractual changes
- Audit or assessment findings
- Material threat changes
Updating your Security Training Program
If you have a mature Awareness and Training Program for your organization you can easily update for NIST-SP-800-171 rev 3. You need to add new content around social engineering and mining, and update your plans to account for ODP triggers.Need to begin formulating a real security training program beyond the annual video you make staff suffer through?
- Start with your risk assessment. Your employees must get trained on the risks to CUI in your system. You can not develop a compliant training without first conducting a risk assessment
- Identify all the learning objectives you want to cover in your program. I expand beyond the security literacy domain and think about all controls that could benefit from training. For example, take removable media. At a minimum employees should sign an Acceptable Use Policy they understand how to handle removable media. That’s training.
- Then decide which role must demonstrate they met the objective.
- Next map all the training you currently provide* Then crosswalk against the objectives to make sure they all get met* Create any custom content to fill in the holes
- Develop a flexible plan that allows you to deliver just in time awareness training.
Feel free to check out and remix my training matrix.
The list of potential classes in my example aligns more with a mid-size company. You can collapse much of the content into a single learning event. For example you could require specific certs and CEUs for role based training. Your social media mining might get covered in the general training for all employees.
You would delete my row of content and add the current training you require. Mark off what objectives get hit, and then fill in the holes by revising content or making new lessons.
-
Updated the “Is it CUI” decision tree again with feedback from Discord. Added a a contract review step once unmarked files are stored in systems meant for Controlled Unclassified Information.
-
Updated draft of “Is it CUI?” Flowchart.
-
Very early draft of a CUI marking decision tree. Not an export lawyer. Welcome feedback.
-
Draft of Scoping Decision Tree
-
What Goes into Your System Security Plan?
Folks often bemoan compliance or security as paperwork and checkbox exercises, but that misses the point of Document Control. Policies, plans, and procedures exist to ensure your business does work in ways that meet laws and regulations. They also exist to describe how you get the job done and stay profitable. Too often we create these governance tools as an afterthought to prove they exist.
Consider your document control using an AS9100 lens. For those not in Aerospace manufacturing, where ISO 9001 an AS9100 often live, your Policies, Plans, and Procedures dictate how an organization creates, approves, distributes, and retires quality-critical information.
So What Goes into Your System Security Plan?
Your System Security Plan (SSP) must communicate the critical information about how your organization meets the requirements of NIST-SP-800-171.
Most importantly your SSP must provide value to you and your team (which might include just you).
At KNC Strategic Services we break the SSP down into two parts. The front matter, which includes all the diagrams and evidence required by Security Assessment controls and a spreadsheet of implementation statements written at the objective level.
Flavors of an SSP
We often see different types of SSPs. Those that explain procedures in the control statements and those that point to other documentation. Some companies try to do both. Some may define most procedures in their SSP. This really depends on the size of your team and the scope of your environment. A small company utilizing a file share service or a managed enclave might not want to have a ton of documents to manage. A medium or large manufacturer who must meet multiple frameworks might have existing Document Control procedures. They can keep their SSP always in compliance and not need to update it for any procedural change.
Smaller micro businesses may have even less documentation. Remember your System Security Plan serves a plan. You use it as a governing document. A company can include all your definitions, identify controls, and spell out procedures directly in the SSP. In fact a two person company dealing with 14 policies, 14 plans, and umpteen forms and Standard Operating Procedures leaves them less secure. Do they really need a password policy or just spell it out in the SSP?
In the first example when a requirement that has an objective which states you must DEFINE a “thing” you would write, Spacely Sprockets defines X as, “insert definition.” Then in the next objective, “We enforce the thing in our SOP Y “
In the second example when an objective states you must DEFINE a “thing” you would write, “ Spacely Sprockets defines X. The definition is maintained in Document Y.” Then in the next objective, “We enforce the thing in our SOP Z “
In the last example when an objectives n the second example when an objective states you must DEFINE a “thing” you would write, “ Spacely Sprockets defines X as, “insert definition.” Then in the next objective, “We enforce the thing by doing Y”
Which Flavor is Better
Chocolate, Vanilla, or burnt Wildberry? The choice belongs to you. Many assessors like the ease of having procedures spelled out in the SSP. Many small IT firms like having all the steps they take in one plan. As long as you have a robust traceability matrix how you arrange things in the bowl should not matter.
At KNC Strategic Services we follow the second approach and point to documentation. As a C3PAO DIBCAC does our assessments. Folks who come out of the Government and get trained on 53/RMF often use this model. The Government has a large scope, and don’t exactly meet the definition of small business
Some companies do try and do both. This can get dangerous. Now you have to ensure all your implementation statements match in your policies and procedure and also in your SSP control statement. Document drift presents a compliance risk. Though LLMs, commonly referred to as AI, might mitigate and/or exacerbate this issue.
If your company consists of just you, it can feel odd to send yourself a change request ticket, have yourself evaluate the risk and security implications, get yourself to approve the ticket, update the ticket when the change gets done, then mark the change closed.
Procedures get done by humans, even if written by AI. Keep them useful.
Utilizing AI
You can really harness AI to create documentation and run compliance checks against evidence. Yet you can also burn through tokens and create spreadsheet columns you never fill which become problems come assessment time.
As part of your Document Control you should have spelled out policy on AI policy and procedure generation. You can offload the cognitive task of writing, but not the contractual risk.
AI likes to get wordy. You will create overly complicated procedures not meant for a small business without strong human oversight. You will end up with forms that have a thousand columns. Do let machines invent new workflows. You will not do them.
I have found this system works best for me.
- Have a Policy, Plan, or Procedure template file employees must use in their model. You might add sensitivity labels if the document should not leave your approved AI boundary.
- Create a boundary diagram and a data flow diagram. The more detailed and accurate of an image you provide of system boundaries the better your results.
- Create the Policies, these just describe the regulations you meet and rarely change. Your goal is concise vagueness describing the specific regulations you meet.
- Inventory your Procedures. How do you currently do stuff? Have you written these things down or does it fall in the “Institutional Knowledge Bucket”?
- Upload any documentation from vendors such as SRMs, implementation guides, or installation steps.
- Draft your NIST-SP-800-171a implementation statements.
- Even if you uploaded NIST-SP-800-171a, the CMMC Assessment Procedures, and the Level One and Level Two scoping guides, go one control statement at a time. AI will straight make up objectives and new compliance requirements. Go slow to go fast.
- Create or revise procedures to make sure the implementation statements happen. Do this close to the ground. Procedure must provide value and help get the job done.
- Create a Plan for each Domain Family. Upload any relevant SOPs and the implementation statements. Ask AI to craft a plan
- Delete all the extra kruft you do not need
- Have Plans approved.
You may have your own system, and AI can create governance documents. Agents can keep all this aligned and gather evidence to ensure the SOPs get followed, but they can’t lead. Having document control matters so much more than checking a box for compliance.
You need to create systems that help you do business better.
-
alright @manton still no web ring plug-in…we gotta find a community member to fix that.
-
Policies, Plans, and Procedures, What's the Dif?
In terms of CMMC many organization feel overwhelmed by documentation and do not always understand the distinction between policy, plans, and procedure. Yet we often get lost in the effort to meet compliance requirements and forget that the “G” in GRC stands for governance The documentation your company uses in cybersecurity should be the documentation on HOW you govern your company and thus rely on practices you put in place.
They need to have merit and functionality for your employees.
Policy
Policies provide a formal statement of organizational intent and management direction. In terms of CMMC these policies usually point to a control family and say what requirements you will meet.
NIST describes security policy as defining the objectives and constraints of the security program. It generally answers “what” and “why,” rather than “how,” and is normally written so it is not dependent on a specific technology.
A policy should establish:
- The organization’s security objective.
- Who and what are covered.
- Mandatory requirements.
- Assigned authorities and responsibilities.
- Rules for exceptions and enforcement.
- Review and approval requirements.
The policy establishes the rule, but it does not explain every administrative step for creating an account.
In NIST SP 800-53, many control families begin with a requirement to develop, review, train for and update a family-level policy and procedures. This has translated down into NIST-SP-800-171. People have one policy per control. The policy governs the relevant controls, while the procedures facilitate their implementation.
Plan
A plan translates policy and requirements into an organized implementation approach. They explain who does the what.
Plans are normally broader than procedures. They coordinate:
- People.
- Responsibilities.
- Resources.
- Technology.
- Schedules.
A plan may describe how the organization intends to achieve an outcome, but it usually does not contain steps people take
Your Cybersecurity Program may have some of the following plans
- System Security Plan.
- Security and Privacy Assessment Plan.
- Continuous Monitoring Strategy or Plan.
- Contingency Plan.
- Incident Response Plan.
- Configuration Management Plan.
- Plan of Action and Milestones.
- Security Training Plan.
In your plan you explain the structured process for preparing, categorizing, selecting, implementing, assessing, authorizing, and continuously monitoring security and privacy controls. Plans provide the organized documentation needed to carry out those activities.
For example your Configuration Management Plan might establish:
- The Change Control Board membership.
- Which systems and configuration items are controlled.
- Change categories.
- Approval responsibilities.
- Baseline-management approach.
- Required security-impact analysis.
- Emergency-change process.
- Configuration monitoring and reporting.
- Review cadence.
The plan explains how configuration management gets organized in your organization., but a separate procedure may explain exactly how to submit and approve a change ticket. Some companies, to cut down on total documentation, may combine plans and procedures.
ISO/IEC 27001 does not require every organization to use a document literally titled “Plan.” Instead, it requires appropriate documented information demonstrating that required processes are planned, implemented, controlled, monitored, and improved. So many CMMC companies with previous ISO work may not have the plans found in RMF.
Therefore, under ISO, planning information may appear in different documentation that you can map back to your policies.
Procedure
A procedure explains how personnel perform a specific activity consistently. These documents provide steps people take to enact a plan aligned to your policy,
A good procedure should be sufficiently detailed so a qualified person can perform the activity without inventing the process.
It typically identifies:
- Trigger or frequency.
- Responsible role.
- Required access and tools.
- Inputs or prerequisites.
- Sequential steps.
- Decision points.
- Required approvals.
- Records and evidence produced.
- Escalation conditions.
- Exceptions.
- Completion criteria.
How do they fit?Consider incident response:
Policy
Let us consider incident response. Cybersecurity incidents, regardless if CUI got compromised, must get immediately, investigated, contained, documented, and reported to external authorities when legally or contractually required.
Plan
The Incident Response Plan identifies:
- Incident-response team members.
- Incident categories and severity levels.
- Communication channels.
- Reporting responsibilities.
- External reporting requirements.
- Available technical resources.
- Coordination with legal counsel and service providers. *Testing and exercise schedule.
Procedure
A suspected CUI incident procedure operationalizes the plan for every day users
- How the user reports the event.
- Who opens the incident ticket.
- How the device is isolated.
- How logs and forensic images are preserved.
- Who determines whether CUI or covered defense information was involved.
- How the 72-hour DFARS reporting deadline is tracked.
- Who submits the report.
Overall a document should not be classified solely by its title. Its function and content determine what it it acts as a policy, plan, or procedure. A Plan could have many documents. Procedures can get used to meet the requirement of numerous policies. A document called a “policy” that contains only step-by-step instructions is operationally a procedure, while a document called a “procedure” that only states executive requirements may actually be functioning as policy.
work cited: complianceforge.com/start-her…
-
Building for the Future: Utilizing Rev 3 ODPs in your Rev 2 Assessment Scope
Do all NIST-SP-800-171 requirements need continuous monitoring? Which ones are annual? Which controls are monthly? Weekly?
Right now an organization seeking CMMC certification can decide on which requirements get met by controls that need a defined cadence. As you make these decision you might want to look ahead to the future.
NIST SP 800-171 Revision 3 introduced organization-defined parameters, or ODPs, that require organizations to define specific values such as logging events, review frequencies, remediation timelines, and incident reporting triggers. While your CMMC Assessment scope is based on NIST SP 800-171 Revision 2, you can utilize the ODPs to start preparing for a future state.
The Department of Defense memorandum on Organization-Defined Parameters for NIST SP 800-171 Revision 3 states that DoD has defined the organization-defined paramater values as policy in preparation for implementing NIST SP 800-171 Revision 3 as the minimum requirement for contractors. In Rev 2 contractors had more flexibility to define ODPs. They acted more as placeholders to be filled in by each contractor without a common baseline. In Rev 3, these ODP values provide default policy expectations for how frequently certain security activities occur, what events must be logged, how quickly issues must be reported, and how vulnerabilities must be remediated.
Starting with Auditing and Incident Response requirements provides a great launching point to begin transitioning to NIST-SP-800-171 rev 3.
Skip ahead to the Goodies
1. Audit logging ODPs
The audit logging ODPs define what must be logged, how often the logging event set must be reviewed, how quickly audit logging failures must be addressed, how often logs must be reviewed, and timestamp precision..
Topic Requirement ODP Identifier Assignment Text DoD ODP Value Event logging 3.3.1 Event Logging 03.03.01.a Organization-defined event types At a minimum and where applicable: authentication events; security-relevant file and object events; exports/writes/downloads to digital media; imports/uploads from digital media; user and group management events; privileged/special rights events; admin or root-level access; privilege/role escalation; audit and security-relevant log data access; system reboot/restart/shutdown; print to device; print to file; and application initialization. Event logging review 3.3.1 Event Logging 03.03.01.b Organization-defined frequency At least every 12 months and after any significant incidents or significant changes to risks. Audit logging process failure 3.3.4 Audit Logging Process Failure 03.03.04.a Organization-defined time period Near real time or as soon as practicable upon discovery. Audit logging process failure response 3.3.4 Audit Logging Process Failure 03.03.04.b Organization-defined additional actions Document the failure and resolution; troubleshoot; repair/restart the audit logging process; and report as an incident if applicable. Audit record review and analysis 3.3.5 Audit Record Review and Analysis 03.03.05.a Organization-defined frequency At least weekly. Audit timestamp precision 3.3.7 Time Stamps for Audit Records 03.03.07.b Organization-defined granularity of time measurement A granularity of one second or smaller. Related audit/logging ODPs outside the Audit family
Several ODPs outside the Audit and Accountability family still affect logging governance. These are useful for SSP cross-references and evidence planning.
Topic Requirement ODP Identifier DoD ODP Value Security functions involving audit settings 3.1.5 System Access Authorization 03.01.05.b.01 Security functions include, at a minimum and if applicable, configuring settings for events to be audited and managing audit information. Security-relevant information involving audit data 3.1.5 System Access Authorization 03.01.05.b.02 Security-relevant information includes, at a minimum and if applicable, audit information. Physical access log review 3.10.2 Physical Access Monitoring and Review 03.10.02.b.01 Review physical access logs at least every 45 days. Physical access log event-based review 3.10.2 Physical Access Monitoring and Review 03.10.02.b.02 Review physical access logs upon significant, novel incidents, or significant changes to risks. 2. Vulnerability scanning and vulnerability management ODPs
The vulnerability management ODPs establish a minimum cadence for vulnerability monitoring and scanning, define remediation timelines by risk level, and require scan content to be updated shortly before scans run.
Topic Requirement ODP Identifier Assignment Text DoD ODP Value Vulnerability monitoring and scanning frequency 3.11.2 System Vulnerability Management 03.11.02.a Organization-defined frequency At least monthly, or when there are significant incidents or significant changes to risks. Vulnerability remediation timelines 3.11.2 System Vulnerability Management 03.11.02.b Organization-defined response times 30 days from discovery for high-risk vulnerabilities, including critical and high; 90 days from discovery for moderate-risk vulnerabilities; and 180 days from discovery for low-risk vulnerabilities. Vulnerability scan content update 3.11.2 System Vulnerability Management 03.11.02.c Organization-defined frequency No more than 24 hours prior to running the scans. Related vulnerability ODPs outside 3.11.2
These additional ODPs are not limited to vulnerability scanning, but they directly support vulnerability governance, flaw remediation, or supply-chain vulnerability disclosure.
Topic Requirement ODP Identifier DoD ODP Value Security functions involving vulnerability scanning 3.1.5 System Access Authorization 03.01.05.b.01 Security functions include establishing vulnerability scanning parameters. Security-relevant vulnerability information 3.1.5 System Access Authorization 03.01.05.b.02 Security-relevant information includes threat and vulnerability information. Network scanning tools for least functionality 3.4.6 System Configuration 03.04.06.b Guidance states organizations should employ network scanning tools, intrusion detection and prevention systems, and endpoint protection technologies to identify and prevent prohibited functions, protocols, ports, and services. System flaw remediation 3.14.1 System Flaw Remediation 03.14.01.b Install security-relevant software and firmware updates within 30 days for high-risk flaws, 90 days for moderate-risk flaws, and 180 days for low-risk flaws. Supply chain vulnerability disclosure 3.17.3 Supply Chain Security Requirements 03.17.03.b At a minimum, establish processes to ensure suppliers disclose significant vulnerabilities and significant incidents. 3. Incident response ODPs
The incident response ODPs define the speed of internal reporting, who receives incident information, how often incident response capabilities are tested, and when incident response training must occur.
Topic Requirement ODP Identifier Assignment Text DoD ODP Value Incident reporting timeframe 3.6.2 Incident Tracking and Reporting 03.06.02.b Organization-defined time period Near real time or as soon as practicable upon discovery. Incident reporting authorities 3.6.2 Incident Tracking and Reporting 03.06.02.c Organization-defined authorities All applicable personnel and entities as specified by the contract, and in accordance with any incident response plan notification procedures. Incident response testing frequency 3.6.3 Incident Response Testing 03.06.03 Organization-defined frequency At least every 12 months. Initial incident response training timeframe 3.6.4 Incident Response Training 03.06.04.a.01 Organization-defined time period 10 days for privileged users; 30 days for all other roles. Recurring incident response training frequency 3.6.4 Incident Response Training 03.06.04.a.03 Organization-defined frequency At least every 12 months. Incident response training content review 3.6.4 Incident Response Training 03.06.04.b.01 Organization-defined frequency At least every 12 months. Incident-triggered IR training content update 3.6.4 Incident Response Training 03.06.04.b.02 Organization-defined events Significant, novel incidents, or significant changes to risks. Related incident-triggered ODPs outside the IR family
Rev. 3 uses incidents and risk changes as triggers across multiple families. These related ODPs are important because an incident may require more than containment and reporting; it may also trigger reassessment, retraining, reconfiguration, rescreening, documentation updates, and supplier follow-up.
Topic Requirement ODP Identifier DoD ODP Value Security literacy training triggered by incidents 3.2.1 Security Literacy Training 03.02.01.a.02 Significant, novel incidents, or significant changes to risks. Security literacy content update triggered by incidents 3.2.1 Security Literacy Training 03.02.01.b.02 Significant, novel incidents, or significant changes to risks. Role-based training triggered by incidents 3.2.2 Role-Based Security Training 03.02.02.a.02 Significant, novel incidents, or significant changes to risks. Role-based training content update triggered by incidents 3.2.2 Role-Based Security Training 03.02.02.b.02 Significant, novel incidents, or significant changes to risks. Audit logging failure may become incident 3.3.4 Audit Logging Process Failure 03.03.04.b Report as an incident if applicable. Baseline configuration update after incidents 3.4.1 Baseline Configuration 03.04.01.b At least every 12 months and after any significant incidents or significant changes occur. System configuration review after incidents 3.4.6 System Configuration 03.04.06.c At least every 12 months, when system functions/ports/protocols/services change, and after significant incidents or significant changes to risks. Authenticator change after incident 3.5.12 Authenticator Management 03.05.12.e.02 After a relevant security incident or any evidence of compromise or loss. Personnel rescreening after incident 3.9.1 Screening and Rescreening 03.09.01.b Rescreen when there is a significant incident or change in status related to an individual. Physical access log review after incident 3.10.2 Physical Access Monitoring and Review 03.10.02.b.02 Significant, novel incidents, or significant changes to risks. Risk assessment update after incident 3.11.1 Risk Assessment 03.11.01.b At least every 12 months, or when there are significant incidents or significant changes to risks. Vulnerability scan after incident 3.11.2 System Vulnerability Management 03.11.02.a At least monthly, or when there are significant incidents or significant changes to risks. Security requirements assessment after incident 3.12.1 Security Requirements Assessment 03.12.01 At least every 12 months, or when there are significant incidents or significant changes to risks. Policy and procedure review after incident 3.15.1 Policy and Procedure Development 03.15.01.b At least every 12 months, or when there are significant incidents or significant changes to risks. SSP review after incident 3.15.2 System Security Plan 03.15.02.b At least every 12 months, or when there are significant incidents or significant changes to risks. Rules of behavior review after incident 3.15.3 Rules of Behavior 03.15.03.d At least every 12 months, or when there are significant incidents or significant changes to risks. SCRM plan review after incident 3.17.1 Supply Chain Risk Management Plan 03.17.01.b At least every 12 months, or when there are significant incidents or significant changes to risks. Supplier incident disclosure 3.17.3 Supply Chain Security Requirements 03.17.03.b Suppliers must disclose significant vulnerabilities and significant incidents. Integrating Rev 3 ODPs into Rev 2 assessments
The biggest implementation mistake is treating ODPs as one-time text entries in an SSP. These values should become operational requirements that appear consistently across policies, SOPs, ticketing workflows, reporting templates, technical configurations, and evidence repositories. When writing an SSP for a Rev 2 assessment you need to define your procedures. By setting your time frames to Rev 3 you begin to future proof your scope for updates to CMMC.
Implementation sequence:- Update policies first. Insert DoD ODP values into audit logging, vulnerability management, incident response, training, configuration management, and risk assessment policies.
- Update procedures second. Convert each ODP value into a step, trigger, review cadence, escalation point, or evidence requirement.
- Map tools to each value. Identify where the value is enforced or evidenced, such as SIEM queries, audit logs, vulnerability scan reports, EDR alerts, IR tickets, training records, or SSP review logs.
- Align evidence collection. Create recurring evidence tasks for weekly audit review, monthly vulnerability scanning, annual IR testing, annual policy reviews, and event-driven updates after significant incidents or risk changes.
- Close the loop after incidents. Treat significant incidents as triggers for training updates, vulnerability scans, risk assessments, configuration reviews, SSP updates, and policy/procedure reviews.
-
-
MAM versus MDM: Data and Device Protections
A lot of organization who rely on Mobile Device Management are starting to understand the risks of Bring Your Own Device.
Watching the Stryker Incident where Intune erased personal devices managed by employers has put the issue in stark contrast.
Mobile Device Management is not enough to secure data.
Mobile Device Management (MDM) and Mobile Application Management (MAM) are both enterprise tools used in mobile security controls.
They operate at different layers of data flows. In environments subject to NIST SP 800-171, both MDM and MAM get used to control how mobile devices and apps access sensitive data.
MDM allows administrators to configure, monitor, and secure the entire device, including OS settings, encryption, and remote wipe capabilities.
MAM focuses only on enterprise apps and the business data inside them, using app-level policies like restricting copy/paste or wiping corporate data from an app.
You need to protect the device and the data.
In NIST 800-171 environments, the key requirement for data is cryptography protecting CUI must use FIPS-validated cryptographic modules. When vendors claim “FIPS MAM,” they mean their app container uses FIPS-validated libraries. The MAM isn’t itself “FIPS.”
So with Microsoft Intune MAM App Protection Policies, your container involves App-level MAM policies and SDK/app wrapping. This uses FIPS-validated modules from the OS. When devices run in FIPS mode, Intune apps inherit those modules.
First descope BYOD. If you can’t remember:
MDM = device trust MAM = data protection
You need both.
-
Big Announcement
The DIB CS Program is OPEN for new companies. The outreach and onboarding functions have transitioned to DC3.
DIB Companies, with or without an FCL, working with CUI, can apply at DC3.DIB.CSRegistration@us.af.mil
-
CyberDI's Customizable CMMC and Export Control Curriculum
Proud to Announce CyberDI’s Awareness and Training Programs to meet your CMMC requirements and improving a culture of security
CyberDI Awareness and Training Program
-
CMMC Tool Sets
-
CMMC, Backups, and FedRAMP
Why do back ups live in the Media Protection family?
Ransomware threatens your business everyday, and backups help to inoculate your systems. Why do back ups get such a small mention in NIST.SP.800-171r2?
NIST explains in NIST-SP-800-171r2 they pulled “CP-9, System Backup” into the Media Protection family because the Contingency Planning family did not get included in 800-171’s requirement set.
The Government does not care about your disaster recovery and contingency planning. NIST-SP-800-17 protects the confidentiality of the customer’s data, not keep your business afloat.
Backups and CUI
CUI still is designated as CUI even when encrypted. Encryption, when it is a FIPS Validated implementation, is sufficient protection of the CUI when outside of the organizations physical or digital control boundaries.
resource: dodcio.defense.gov/Portals/0…
-Q8. Is encrypted CUI still considered to be CUI? B-A8. In accordance with 32 CFR Part 2002, CUI remains controlled until it is formally decontrolled. As such, encrypted CUI data retains the control designation given to the plain text counterpart. While it is true that certain risks (e.g., transmission across unsecured, "common carrier" networks) may be accepted for cipher text that would not be accepted for plain text, this does not mean the original, controlled information, nor the data (plain or cipher text) representing it, is considered decontrolled.
171 Requirements
Only one requirement explicitly mentions backups, “3.8.9 — Protect the confidentiality of backup CUI at storage locations.”
Organizations can reply on FIPS encryption and employ cryptographic mechanisms or alternative physical controls to protect the confidentiality of backup information if the backups store, process, or transmit CUI.
NIST guidance calls our protecting system level and and user information. “Backed-up information containing CUI may include system-level information and user-level information. System-level information includes system-state information, operating system software, application software,and licenses. User-level information includes information other than system-level information.”
171 Requirements about securing media used for backups
While only one explicit requirement for protecting back up exists. Other 171 apply to the media you use for backups.
3.8.1 — Protect system media containing CUI (paper and digital).
3.8.2 — Limit access to CUI on system media to authorized users.
3.8.3 — Sanitize or destroy media containing CUI before disposal or reuse.
3.8.4 — Mark media containing CUI with appropriate markings.
3.8.5 — Control access/accountability for media during transport outside controlled areas.
3.8.6 — Use cryptographic mechanisms to protect CUI on digital media during transport (unless physically safeguarded).
3.8.7 — Control the use of removable media on system components.
3.8.8 — Prohibit portable storage devices with no identifiable owner.
171 Requirements for securing back up data
Other security requirements require you to protect the data often contained in a back up
3.13.8 — Protect CUI from unauthorized disclosure during transmission
3.13.10 — Establish and manage cryptographic keys
3.13.11 — Use FIPS-validated cryptography when protecting CUI confidentiality
3.13.16 — Protect the confidentiality of CUI at rest
Scoping Your Backups
For a CMMC assessment you only need to worry about backing up your CUI environments. You 100% as a business should have disaster recovery and contingency plans. Well deployed and tested backup systems prevent ransomware. Outside of MFA, investing in backups provides some of the greatest security for a company.
Do you use cloud back ups? If you deploy cloud back ups, and these include CUI environments do you need to choose a FedRAMP authorized or equivalent service? Is a cloud back up provider outside of your boundary control? Can you then encrypt backups and store that cipher text at rest?
For most CUI, if you encrypt your backups with validated FIPS encryption before going to the cloud that is sufficient. No FedRAMP needed. But…for Specified CUI like ITAR/Export controlled, there are some restrictions on what clouds or countries it can be stored in, even in encrypted form. Vendors may require you to choose their FedRAMP solution regardless of your data sovereignty requirements.
Choosing a FedRAMP authorized solution usually have much higher costs. Many cloud providers do not offer a FedRAMP service, but they may license software to run on prem.
Can you segment off your CUI backups? Many vendors include backup as part of their product solution. Maybe you have a cloud backup solution for out of boundary assets and a different solution for your CUI enclave.
You have alternatives to using FedRAMP cloud based solutions. Just make sure to properly scope your backups of CUI environments, but choosing FedRAMP authorized cloud back ups will be accepted by an assessor.
Back Up Best Practices
Just because CMMC does not require a back up or contingency plan you may want to take the opportunity to ensure you follow best practices.
You need to develop a back up policy:
You need to develop a back up plan:
Utilize a 3-2-1 Back Up solution
Consider the implications of Cloud Back Ups
Make sure to protect your chosen Media types
You need to protect your backups
Finally you need to test your back ups
Creating Disaster Recovery and Contigency Plans
You do not need to worry about disaster recovery for CMMC compliance. You do, however, need to worry about good back ups if you care about the security of company. Utilize the momentum of CMMC to develop and test your disaster recovery. As you do document evidence for your System Security Plan
-
AI For Security S ecurity For AI
A good intro to the risks, challenges, and opportunities
-
Many people are confused by the Cross tenant collaboration and the new Microsoft UX:
gcch-m365-webinar-connect-collaborate-create-june-2025-complete.pdf
-
Adding sensitivity labels to SharePoint: learn.microsoft.com/en-us/pur…
unlabeled filed continue to be protected with current SharePoint permissions for the user, even though the files have left original SharePoint boundary
COOL!
-
Adding cross posting to Blue Sky
-
People keep asking, “What they can do?”
How can they help
If you are a small business owner one of the best things you can do is make sure you have a good backup and recovery plan
Good back ups are the Victory Gardens of the 21st Century
-
Many companies are now hearing more and more about Multi-Factor Authentication. In fact for most small businesses you can no longer get insurance, let alone cyber coverage, without ensuring MFA gets used for all sensitive data.
Really if you can turn on Multi-Factor Authentication. You should
-
-
Certified CMMC Assessor: Spinning the Wheels of Trust in Much Bigger Systems
Certified CMMC Assessors click into place as just another cog in a much larger system that already exists.
Every objective that a CCA examines must already be legally met by Organization Seeking Certification. CMMC introduced no new requirements on Federal contractors. When people often complain about the cost of CMMC they do not mean the actual assessment but refer more to meeting the requirements a CMMC assessment measures.
After the continued exfiltration of data and failed self assessments A third party validation of the system security plan was added to increase the trustworthiness of systems designed to process, store, and transmit Controlled Unclassified Information.
According to NIST a system is a series of elements or components that together have a shared identity working towards a goal within the constraints of a specific environment and the requirements of the outcome.
Organization Seeking Certification engineer security in their systems through systems security engineering. Originally the Government placed trust in organizations seeking certification. However recent evidence calls into doubt the trustworthiness of self reporting. The lack of trust in System Security Plans in turns cast doubt on the trustworthiness of the overall security engineered into a system.
So through CMMC a third party assessment was added to assess trustworthiness and increase trust in the supply chain.
Trust and Trustworthiness
A CCA serves as the verification and validation method to assure with confidence that federal contractors protect the confidentiality of Controlled Unclassified Information. A CCA verifies the trustworthiness of the evidence an organization seeking certification includes in their System Security Plan. You validate that their tests to ensure the trustworthiness of their systems proves the Organization Seeking Certification
Trust is a belief that an entity meets certain expectations and can be relied upon. The terms belief and can imply that trust may be granted to an entity whether the entity is trustworthy or not. A trustworthy entity is one for which sufficient evidence exists to its claimed trustworthiness.
Verification and Validation of the System Security Plan
As a Certified CMMC Assessor you verify and validate that an Organization Seeking Certification meets the security requirements of NIST-SP-800-171. In order for a System Security Plan to be trustworthy the OSC must have a demonstrated ability to satisfy expectations of protecting Controlled Unclassified Information
Since trustworthiness is something demonstrated, you verify and validate the evidence that supports a claim or judgment of the CMMC practices being met.
As a Certified CMMC Assessor you also serve a dual role of trust. As a trained assessor the Government can put trust in your assessment. As a Certified assessor the Organization Seeking Certification can trust your credentials. Trust is value judgment based on authority and evidence.
In terms of Cybersecurity Maturity Model Certification program this means you examine the SSP and validate each CMMC practice to ensure there is sufficient evidence of trustworthiness in the claims being made by the Organization Seeking Certification.
A CCA validates the trustworthiness of each claim an Organization Seeking Certification makes about meeting the security requirements assessment of NIST-SP-800-171 to protect the confidentiality of Controlled Unclassified Information.
This means the verification and validation of each assessment objective. As an assessor you have to make sure the evidence is sufficient and adequate enough to ensure that each of the 110 security requirements has enough depth and breadth that the claims made in the System Security Plan can be trusted.
Your role in the system is to increase the assurance that the Nation’s controlled Unclassified Information gets protected. According to NIST,
Assurance is a complex and multi-dimensional property of the system that builds over time. Assurance must be planned, established, and maintained in alignment with the system throughout the system life cycle.
In your roles of dual trust as a CCA you help to build assurances in the overall supply chain system. You also verify the evidence an OSC includes in a System Security Plan and validate how an organization establishes the trustworthiness of these claims in the trustworthy context.
Trustworthy Context
The trustworthiness context involves decision making and evidence based demonstrations that a system security plan can be trusted to protect the confidentiality of Controlled Unclassified Information. The Organization documents how they develop and maintain their assurances of meeting the security requirements of NIST-SP-800-171 and how they demonstrate how the assurance is satisfied. A CMMC Certified Assessor verifies and validates the System Security Plan as a decision-making context.
When the Organization Seeking Certification writes how they meet the security requirements of each NIST-SP-800-171 objective they create an assurance case. This demonstrates how they cover the objective with enough depth and breadth to ensure we can trust the assurance case.
As a CCA you will verify and validate the evidence in System Security Plans with a variety of quality. An effective SSP acts as an assurance case playbook. First a claim is derived from from security objectives Then the OSC connects to and documents credible and relevant evidence that substantiates the claims. Often the evidence get validated through ongoing testing and good system development life cycle practices. Basically Say What you do, explain how you do it, and prove it gets done. Have an assurance case for every assessment objective.
Organizations with strong cyber hygiene present a compelling assurance case for all 325 objectives in NIST-SP-800-171.The result provide a statement that adequate security has been achieved and driven by stakeholder needs and expectations. Strong Systems Security Engineering helps to strengthen security and reduce the effort on validating and verifying assurance cases.
-
Hanging at Converge Security and learning about Conway’s Law at the Keynote addresds
-
Developing a Rubric to Assess Policies and Procedures for CMMC Compliance
People panic when it comes to policy and procedures and CMMC. Rightfully so. Compliance with NIST-SP-800-171 at a miminum requires fourteen different policies and fourteen different procedures. Probably More. In fact NIST recommends 39 different plans, policies, and procedures for 171 compliance.
While policy and procedures are not explicitly assessed by CMMC practices a majority of assessment artifacts imply the need for policy and procedures through explicit mention of document based specifications.
Yet few people write policy and procedures. Even less do it well.
To help you in creating compliant policy I have developed a series of “self-assessment” checklists for each Domain of CMMC.
Why Policy
Policy defines the governance of the systems you engineer to protect the confidentiality of Controlled Unclassified Information. Let us examine configuration management.
Overall configuration management policy communicate senior management’s expectations to the company. A good policy, regardless of domain must have specific, measurable, and confirmable objectives. Policies providea top-down approach to define what is required and what is not permitted with configuration management.
While policy defines the objectives for what must get done, procedures describe how the policy objectives get met through specific actions and results. Configuration Management procedures describe the methodology and tasks for each activity that supports implementation of Configuration Management policy.
As a company meeting CMMC requirements you should document your configuration management policy and procedures during your planning phase. In fact NIST-SP-800-171 requires you to regulary review all policies and procuedres.
What makes a Good Congifuration Management Policy
You can not check CMMC Assessment guides for help with writing configuration managment. You will not find your answers in NIST-SP-800-171, but 171 will tell you where to look,
In the back of NIST-SP-800-171 you will find Appendix E. This lists all the security controls the government assumes you do or controls they assume only apply to the federal government. These controls came from NIST-SP-800-53.
The very first base control of every family in NIST-SP-800-53 is policy and procedures. If you look at NIST-SP-800-53a you can find a list of requirements for compliant policy. This provides a wonderful tool for you to assess your current policy.
As a tool however it is hard to read.
Why A Configuration Management Policy Rubric
Self-assessment works in improving technical writing skills. We know from decades of research that theese metacognitive, or thinking about thinking, guides help to improve outcomes.
To design these rubrics I went through the objectives of each Policy and Procudure for each Family in NIST-SP-800-53. This information is required but not assessed for NIST-SP-800-171 nor assessed for CMMC but required evidence for a CMMC assessment.
Organization Defined Parameters
In order to be technology agnostic and provide a more holisitic approach NIST rarely defines rules around roles, events, and freqencies. Instead your policy and procedures must have clear organization defined parameters that get enforced in policy and procudures
In NIST-SP-800-53a these ODPs get explicitly defined and displayed in a table with the requirements but off set with grey shading. These requirements are just NFOd in NIST-SP-800-171.
The Requirements in NIST-SP-800-53a then spell out what should go into each policy
I tried to take this information and turn it into a checklist a company can use to evaluate their configuration management policy.
subscribe via RSS