J. Gregory McVerry

  • 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.

    Source: DoD ODP Memo NIST SP 800-171 Rev. 3 Audit - Vulnerability - Incident Response

    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.

    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.

    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.

    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:
    1. Update policies first. Insert DoD ODP values into audit logging, vulnerability management, incident response, training, configuration management, and risk assessment policies.
    2. Update procedures second. Convert each ODP value into a step, trigger, review cadence, escalation point, or evidence requirement.
    3. 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.
    4. 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.
    5. 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.

    Source basis: Department of Defense memorandum, Department of Defense Organization-Defined Parameters for National Institute of Standards and Technology Special Publication 800-171 Revision 3, Attachment A: NIST SP 800-171 Revision 3 ODP Values.

  • 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:

    Auto-generated description: A detailed backup policy infographic outlines eight steps, including defining recovery objectives, deciding on media, encryption requirements, security, regulatory references, lifecycle management, recovery procedures, and testing procedures.

    You need to develop a back up plan:

    Auto-generated description: A flowchart provides a comprehensive guide on planning data backups, covering file identification, risk evaluation, network mapping, and policy development.

    Utilize a 3-2-1 Back Up solution

    Auto-generated description: A 3-2-1 backup strategy infographic details keeping three copies of files on two types of media, with one off-site, emphasizing file identification and emergency readiness.

    Consider the implications of Cloud Back Ups

    Auto-generated description: A guide for evaluating cloud backups, highlighting risks, encryption, phishing-resistant MFA, least privilege, and the importance of updates and testing.

    Make sure to protect your chosen Media types

    Auto-generated description: A comparison chart details the pros, cons, and security features of cloud, hard drive, and removable media types, including external hard drives, flash drives, optical media, and magnetic tape.

    You need to protect your backups

    Auto-generated description: An infographic titled Protect Backups details strategies for reducing data loss risks, listing key areas such as risks, solutions, steps, and the importance of practice drills and patch management.

    Finally you need to test your back ups

    Auto-generated description: A diagram titled Backup Recovery outlines the importance of testing, training, and exercises with a focus on confidentiality, integrity, and availability.

    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

    Auto-generated description: A circular graphic features an image of network cables and connectors, overlaid with an icon of servers connecting to a cloud, accompanied by the text Good Back Ups 21st Century Victory Gardens.

subscribe via RSS