Guide: What Are ODPs in NIST 800-171 Rev 3?

The shift from NIST SP 800-171 revision 2 to revision 3 includes a lot of changes, which we've already covered from a bird's-eye view over in this post.

One of the biggest changes in Rev 3 is the introduction of ODPs, or Organization-Defined Parameters. These are very important for compliance with CMMC moving forward, but they're still something of a mystery to some security professionals, and are worth explaining. What are they, how do you define them, and how do you use them for compliance? Let's talk about it.

What Are Organization-Defined Parameters?

When you think about a risk management or information security framework, your basic concept might come in one of two forms: descriptive and prescriptive.

A prescriptive framework lays out rules and tells you to follow them. It might say something like "you need to limit unsuccessful login attempts to 3, after which the account is locked."

A descriptive framework lays out goals, but leaves the specifics up to you. It might say something like "You need to limit unsuccessful login attempts and implement a restriction on successive attempts."

There are pros and cons to both methods. A prescriptive method is easier to follow, but it's very "letter of the law" in that even if you're in full compliance, if the framework itself is not comprehensive, it can leave gaps in security. It can also present issues for organizations that can't meet all of the rules, for one reason or another.

As the security environment and greater ecosystem changes, the framework needs to be updated, which requires a rapid turnaround time and many frequent iterative version updates. This is something the government is not exactly good at doing. Few have ever accused the government of being agile and responsive.

Descriptive frameworks are more flexible and are able to encompass a greater array of organizations and rules, and can adapt with the environment by their very nature. They're a "spirit of the law" framework, where compliance means meeting security goals, not filling out a configuration checklist.

The downside here is that there's a lot of confusion. Just take the unsuccessful logins example; how many is too many, and what are the restrictions? Is a business that locks an account after 5 attempts tangibly less secure than one that locks after 3? Is a lock-out of an hour worse than a lock-out of a week? Should that lock-out escalate?

Every organization needs to find its appropriate interpretation of these questions, but when there can be dozens or hundreds of such questions for the framework as a whole, it can become very messy.

This is what ODPs are for.

NIST SP 800-171 Rev 3 is a descriptive framework, but ODPs are a semi-prescriptive portion of it. For example, here's what Rev 2 says specifically for login limits:

"Limit unsuccessful logon attempts."

And here's what Rev 3 says:

"Enforce a limit of [organization-defined number] consecutive invalid logon attempts by a user during a [organization-defined time period.

Automatically (Choose one or more: lock the account or node for [organization-defined time period]; lock the account or node until released by an administrator; delay the next logon prompt; notify system administration; take other action) when the maximum number of unsuccessful attempts is exceeded."

Pretty big difference, huh?

This is one security control, enforcing one form of restriction on attempts to breach a system. It has three ODPs built into it. An organization adhering to NIST SP 800-171 must now decide and define what the number of unsuccessful login attempts should be, what amount of time they need to occur in to constitute successive attempts, and what action happens when this limit is reached.

So, for example, you might set it as:

• A maximum of four unsuccessful login attempts
• Within a 10-minute period
• Which locks the account for 1 hour

By deciding on, and documenting, these ODPs, your organization takes the generic, descriptivist NIST SP 800-171, and turns it into a more customized-for-your-organization framework.

Key Facts About ODPs

You have questions, we have answers. We'll dig into this more in a moment, but here are the fast answers to common questions.

ODPs are meant to take a generic, one-size-fits-most framework and convert it into something specific and relevant to your organization. They give you a lot of tangible, specific levers to pull to customize the framework within acceptable limits and make it as effective as it can be for you specifically.

There are valid ranges for ODPs. You can't, for example, decide that the maximum number of unsuccessful login attempts is 2,000. That doesn't really align with the goal of security, and is more a sign of just wanting to avoid having to implement a policy at all. This can jeopardize your eventual audit.

There are guides for valid ODPs. We'll get to this later, but there are baselines you can use as a starting point for what your ODPs should be, or what their valid range is, so you can customize from there instead of from scratch.

There are 97 security controls across NIST SP 800-171 Rev 3. 50 of those controls have ODPs. Since several of them have more than one ODP, there are a total of 88 ODPs in Rev 3. This means a successful implementation of 800-171 requires choosing 88 variables to reflect your organization's risk tolerance.

Have any other questions? Once you're done reading the post, if they haven't been answered, feel free to reach out and ask us directly.

ODPs vs ODVs: What's the Difference?

You may have seen the companion acronym, ODV, tossed around more or less interchangeably with ODP. What is it, and what's the difference between them, if any?

ODPs, as discussed, are parameters that need defining within the overall framework of NIST SP 800-171.

ODVs are the values you choose to specify for those ODPs.

Think of it like a MadLib; an ODP is the blank to be filled in, and the ODV is the word you choose to put in the blank.

The only place this really matters is in the formal documentation. You'll identify the ODP by its number and assign it the value. To keep using password lockouts, invalid logon attempts is Access Control 3.1.8. The ODPs are 03.01.08.a.01, 03.01.08.1.02, and 03.01.08.b. The ODVs are "up to four", "a period of 10 minutes", and "locks the account for an hour and notifies the administrator."

Most people talking about all of this just use ODP to refer to both the gap and the variable, and being ultra-specific doesn't matter outside of the actual documentation, which you'll likely be using a tool to fill out properly regardless. So, don't worry too much about being specific between the two terms.

Who Chooses the ODP?

When you're running through your security and implementing controls, who picks the appropriate value for the ODPs?

There are two answers to this.

The first is: you do. As the organization, you are responsible for defining the organization-defined parameters. Makes sense, right?

But how do you know what a good value is and is not? How do you decide if you should lock an account after 3 attempts, 5 attempts, or 10 attempts?

You could dig into industry-wide best practices. There are generally accepted answers for many (though not all) of the questions raised by ODPs.

On the other hand, that's a lot of research and a lot of work that has undoubtedly already been done by others.

So, the second answer is: The DoD. In a clarification memo, the DoD published a list of the ODPs and what their defined, accepted value ranges are.

For account logon attempts, their specifications are:

• 03.01.08.a.01 – Number of attempts: "At most five (5)"
• 03.01.08.1.02 – In a given time: "Period of five (5) minutes"
• 03.01.08.b – Consequence: "[Selection (one or more): lock the account or node for an at least 15-minute time period; lock the account or node until released by an administrator and notify a system administrator]

This is not all of the answers. The DoD still leaves leeway for customization. "At most 5" means anywhere from 1 to 5, so picking 3 is still valid, but picking 10 is not. Similarly, they provide a list of potential consequences for an account being locked, but you can pick which ones you implement, as long as you implement at least one of them.

The Third Answer

There's a third answer here, but it's a less common case, so it gets its own section.

The DoD defines ODP ranges, but this only applies to organizations that are beholden to the DoD. That's generally anyone with a DFARS 252.204-7012 clause in their contracts. This means anyone outside of the DoD ecosystem doesn't have to use the DoD's defined parameters.

For example, an organization that handles CUI for an agency like NASA would use whatever NASA specifies, if anything, rather than what the DoD sets. Now, currently NASA has not published its own guidance, and it's pretty certain that the DoD's guidance would be more than sufficient, but it's not wholly required.

There are also cases where you might be using NIST SP 800-171 without being part of the ecosystem at all. It's unlikely, but that would give you the full flexibility to set any ODP you want. Even then, sticking to what the DoD lists is probably a good idea, but it's not mandatory.

What Organizations Need to Use ODPs?

Here's the big trick about all of this.

Right now, no one has to use ODPs.

This is because ODPs are part of NIST SP 800-171 Rev 3, but critically, the DoD's DFARS clause and frameworks like CMMC still use NIST SP 800-171 Rev 2. Rev 3 has not yet been made mandatory, and likely won't for quite a while yet.

One day, possibly in the next 1-2 years, the relevant clauses are likely to be amended and the frameworks updated to use Rev 3. When that happens, the use of ODPs will become mandatory, though as with any major change like this, there will doubtless be an on-ramp of at least a year for compliance to become fully mandatory.

This all means that, while it's a good idea to understand ODPs and learn what the settings should be, the actual documentation and submission of ODPs is unnecessary for now.

What to Do as an Organization Today

So, what should you do to navigate all of this today? Here are our recommendations.

First, familiarize yourself with the concept of ODPs. Learning what they are (which this guide should do a good job explaining) puts you in the right state of mind for future compliance.

Second, read through the DoD-specified ODPs. Knowing what the DoD is going to mandate helps you tighten the reins and figure out where to draw the lines.

In fact, many ODPs are still relevant today, even if the specific security controls are different. The one we've been using is a great example; under Rev 2, you need to block unsuccessful logon attempts. How? Well, the Rev 3 documentation is a good and valid way to do it. You just need to implement it and document it in accordance with Rev 2 when you submit your SSP and undergo an audit.

Third, be prepared for the eventual change. Sooner or later, the government is going to update to require Rev 3 instead of Rev 2. Having at least some of the work done, the tools in place, and the documentation ready will streamline your path to that new form of compliance.

We also recommend using a good tool to track and manage all of this. A big part of modern and future risk management and information security frameworks is an increasing lean towards automation and machine-readable documentation. Tools like the Ignyte Assurance Platform are designed with this in mind.

Our platform can track and monitor the status and progress of all of your relevant security controls across a wide range of different frameworks. When you need documentation, it's there for you to retrieve. Implementing and tracking ODPs is a simple matter as well.

To see how it all works with a customized demo, just reach out!