Choose Your Own Adventure: NIST Organization-Defined Parameters (ODPs) & Organization-Defined Values (ODVs)!
If you’re reading this, chances are you’ve already heard of, and are most likely working with NIST, DoD, CMMC, CIS, etc. security controls. If so, you are also likely familiar with the need to complete control statements by filling in some blanks and you are not quite sure how to do that.
That’s that this article is about.
I’ve been tasked to fill in these blanks (the content in the brackets below), so I’ve been living and breathing ODPs and ODVs for the last few months.
Control Statement for AC-6(1)
Authorize access for [Assignment: organization-defined individuals or roles] to:
a. [Assignment: organization-defined security functions (deployed in hardware, software, and firmware)]; and
b. [Assignment: organization-defined security-relevant information].
If you’re like I was — struggling to make sense of it all, even with NIST’s free training, you need a plain-language, practical explanation and demonstration.
I’m writing this because the work in which I’m engaged, migrating systems from Rev 4 to Rev 5, is a valuable experience that I’m eager to share.
Even after reading the definitions and working on a gap analysis, I realized I didn’t fully grasp the “what” and “how” of it all so I begain doing what I do best…researching, asking questions and getting in there and doing the work.
So, let’s cut through the jargon and get to the heart of it. I’ll share the answers to TWO key questions that stumped me about ODPs and security controls:
What are ODPs and ODVs, and how do they relate?
How does an organization know which ODV to assign to an ODP?
By answering these questions, I hope to provide a clear, down-to-earth explanation that will help you confidently navigate the world of NIST controls, ODPs and ODVs.
Just to be sure we’re starting on the same page let me give you a quick background. In a nutshell, NIST has published a new version of security controls (Rev 5) and there are some key differences between them and the old version (Rev 4).
There’s an overwhelming amount of information out there about NIST SP 800–53 Rev5, so I’ll leave it to you to do that research if you need more information.
Let’s get to these parameters and values.
PARAMETERS
First, let’s quickly understand what a parameter is and how we interact with them every day.
Parameters give you flexibility within a confined space. Think of the parameters we experience while driving.
The highway is a system. It has lanes, exits, and rules of the road that everyone must follow.
The speed limit is a parameter within that system by setting a maximum allowable speed for vehicles on a particular road or highway.
The speed limit parameter allows for flexibility within an established system. Drivers can adapt their speed to different conditions (like rain, skill level, or traffic) and personal preferences, all while staying within the legal limits.
Parameters are especially important when someone in a system has a goal and needs to balance behavior management (through parameters) with flexibility to achieve that goal.
Think of the difference between a jungle and a garden.
A jungle has few man-made parameters allowing for a wide range of behaviors which translates into uninterrupted, unpredictable, diversity and growth.
A garden, however, is deliberately pruned and shaped to control behaviors and growth. The goal is a curated, predictable, esthetically pleasing environment.
In both cases, parameters (or lack thereof) shape the outcome.
This balance between parameters and flexibility is relevant to many other systems:
Software Development: Coding standards are parameters that ensure consistency and quality. However, too rigid standards can stifle creativity and innovation. Without coding standards, developers might adopt different styles and practices, leading to a codebase that is difficult to maintain and understand. A balance is needed to produce reliable and functional software that can still evolve and adapt.
Parenting: Rules and expectations are parameters that guide children’s behavior. However, too many rules can stifle independence and creativity. Without guidance and parameters children may struggle to develop essential skills. A balance is needed to provide structure and guidance while allowing for individual growth and exploration.
An Organization Defined Parameter is just like these other parameters: it provides guidance and structure while allowing organizations the flexibility to choose their own path within those boundaries.
This empowers them to tailor their security practices to their specific needs and risk environments.
Here is the NIST definition of an ODP:
The variable part of a control or control enhancement that is instantiated by an organization during the tailoring process by either assigning an organization-defined value or selecting a value from a predefined list provided as part of the control or control enhancement.
I know.
In other words, an ODP is…
The part of a security rule that an organization can customize to fit their needs. They can either fill in the blank with their own value or choose from a list of options. For example:
Passwords must be at least [oranization fills this in] characters long.
The ODP is the blank the sentence, waiting for the right information or value to complete it. NIST provides the sentence structure (the security requirement) but leaves a blank for organizations to fill in based on their specific needs and context.
Organization-Defined Value (ODV):
The ODV is the value or information that fills in the blank. It’s the specific choice an organization makes to tailor the security requirement to their unique situation.
“Passwords must be at least [ 16 ] characters long.”
The organization completes this control requirement with information based on external policy requirements, organizational policies, security risk tolerance, industry requirements, user experience goals, etc.
Now let’s belabor this point with one more example…just to be sure we get it.
In simple terms, the ODP is the question, and the ODV is your organization’s answer.
Example:
Control statement: “Media containing CUI shall be [organization assigned method of protection] when transported outside of a controlled facility.”
- ODP: The bracketed space, representing the method of protection
- ODV: The value/information that fills in the space. Your organization’s choice, such as “encrypted,” “physically secured,” or “accompanied by an authorized individual.”
Control statement: Media containing CUI shall be [ physically secured] when transported outside of a controlled facility
“Organizations” (which in Rev5 can refer to the Tier 1, 2, or 3 entity) determine which values to assign to organization-defined parameters (ODPs) for each security control family based on several key factors:
- External Compliance Requirements (Example: FIPS 140–3 requires specific controls for cryptographic modules)
- Organizational Policies and Procedures (Example: The organization’s security policy mandates that all access control measures must be reviewed annually)
- Risk Management Strategy (Example: The most recent risk assessment reveals that unauthorized access to critical systems is a high-risk area)
- Operational Context (Example: Defense Contractor Environment: In this setting, the information system must handle sensitive contract data and CUI while complying with regulations such as DFARS and NIST SP 800–171)
- Stakeholder Input (Example: IT staff and security professionals recommend more frequent reviews of access controls due to the critical nature of the systems)
NEW POLICY. WHO DIS?
This process applies to any ODP but I’m going to begin with the Policy Control Statement, because we tend to sleep on policy and often pass them off for someone else to do.
I’m not going to get into why this is a BIG MISTAKE right now — ’ll be back with that later.
Understanding the three NIST risk management tiers will assist us in better understanding how the ODPs and ODVs work from a policy perspective.
Again, let’s start with a common example and common language so we can learn faster.
Think of NIST’s risk management tiers like the different levels of rules in your household:
Parent/Guardian Rules (Organization): These are the big-picture rules set by the parents (or guardians). They decide things like curfew times, screen time limits, and household chores. These rules set the overall expectations and guidelines for everyone in the house.
Child/Occupant Rules (Mission/Business Processes): This is where individuals within the household establish rules specific to their areas of responsibility or ownership. For example, a teenager might set rules for their bedroom (like study hours or quiet time), while a younger child might have rules for their play area but still adhering to the overall house rules.
System Rules (Information Systems): Every home has systems that someone in the home “owns” or controls. Think of the kitchen system and the person in charge of cooking or grocery shopping who sets the rules for how the kitchen system will be maintained (when dishes will be washed, when dinner will be served). Additionally, each appliance has its own set of instructions and safety guidelines, and the person responsible for that appliance must follow those instructions to ensure it functions properly and doesn’t pose a risk to the household. Also if you have a home security system, the person who “owns” that system will set the rules for when the alarm will be set at night, who can access the system, what the code will be, etc.
Notice that while each level has its own sphere of influence, the rules should ultimately work together to achieve a harmonious and well-functioning household (or organization). For example, the child’s bedroom rules should not contradict the parent’s overall household rules, and the security system rules should be designed to protect the entire family, including the children in their rooms and the appliances.
Relating this to NIST
Each NIST control family includes a Policy Control Statement. This statement requires a decision about which entity…
Organization-level,
Mission/business-level or
System-level,
…will be responsible for developing, documenting, and disseminating the policy and procedures for that specific control.
This means that either on or more than one of these entities can be accountable for assigning the values in the ODPs in this policy control statement and throughout the control.
Organization Level: Just like parents setting the rules for the whole household, the organization level sets the overall purpose, scope, roles, responsibilities, policies and procedures for the control family, including when and under which circumstances and policies and procedures will be updated.
Mission/Business Process Level: Similar to people other than then parents who live in, this level is akin to a Division in an organization being responsible for primarily tailoring and implementing the organization-level policies to fit the specific needs of their mission or business process.
System Level: Similar to how different appliances in a home (e.g., oven, thermostat) have specific settings and usage guidelines, system owners are responsible for implementing and maintaining the technical security controls on their specific systems. They follow the broader rules set by the organization and tailored by the mission/business process level to ensure that their systems are secure and compliant.
SUMMING IT UP
- Multiple Entities Can Be Responsible: The NIST framework recognizes that responsibility for a particular policy or control might not solely rest with one entity. It could be a shared responsibility between multiple levels, depending on the nature of the control and the organizational structure. However, no NIST control family policy can entirely skip the organization level, as it forms the foundation for all security practices within the organization.
- ODPs (Organization-Defined Parameters): These parameters are placeholders within the NIST control statements that need to be filled in by the organization.
- ODVs (Organization-Defined Values): These values are the information that fills in the placeholder, completing the control statement. They tailor the control to the organization’s specific needs and risk profile.
Policy creation often follows a hierarchical structure, where higher levels create broader policies that apply to everyone, while lower levels create more specific policies for their particular area of responsibility.
- Baseline Security: The organization-level policies establish a baseline level of security that applies to the entire organization. These policies are typically derived from laws, regulations, industry standards, and the organization’s risk management strategy.
- Hierarchy of Controls: Even if a policy is developed and implemented at the mission or system level, it cannot contradict or weaken the organization-level policies. The higher-level policy always takes precedence. This ensures a consistent and minimum level of security across the entire organization.
- Common Controls: Many security controls are considered “common controls” because they apply to all systems and information within the organization. These controls are typically managed at the organization level to ensure consistency and avoid duplication of effort.
- Oversight and Guidance: Even when policies are delegated to lower levels, the organization-level typically maintains oversight and provides guidance to ensure that the policies align with the overall security strategy.
- Risk Management: The decision of which level is responsible for a particular policy is often based on a risk assessment. For example, a system that processes highly sensitive information might require stricter controls and therefore warrant policy development at the system level, in addition to adhering to organization-level policies.
ONE MORE THING
DoD Components and Security Controls
The DoD Tiers are slightly different than the other Tiers I reviewed, but only in that BIG DoD is Tier 1 and its components (e.g., Army, Navy, 4th Estate Organizations) are Tier 2.
- Organization Level (DoD Component): As a DoD component, you’d likely have organization-level policies that align with DoD-wide cybersecurity directives and regulations. These would establish the baseline security posture for your entire component.
- Mission/Business Process and System Level: Even if you adopt a DoD-wide policy (like a common control) for a specific control family, you’d still need to have a policy at the organization level that acknowledges and references the DoD policy. This demonstrates your commitment to adhering to the higher-level security standards.
- Customization: While you might leverage a common control, you could also add additional policies or procedures at the mission/business process or system levels to tailor the control to your specific needs and risk profile. These additional policies would complement the common control, not replace it.
That’s all folks!! Until next time, subscribe to my Cybersecurity YouTube Channel PersonCenteredCyber
