Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

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?

One of the jobs of the National Institute of Standards and Technology is to keep on top of new technologies as they are developed and evolve. This is particularly important for risk management, considering both of the major governmental information security frameworks (FedRAMP and CMMC) are based on NIST publications. Well, as you might imagine, Artificial Intelligence technology is a huge new risk factor.

Earning the CMMC certification is the most important step between many businesses and the wealth of lucrative DoD contracts available across a wide range of industries. If you want your business to take that next step, it can be an excellent idea, but it's not a switch you can flip and have operational right away. These things take time, and time is money. The contracts you want could be gone by the time you're done. Your budget for implementation could run out before the work is finished.

In the past, FedRAMP has used impact levels as a sort of classification system for cloud services that wish to work with the government in some capacity. The impact levels evaluate a cloud service provider (CSP) based on the sort of information they would be handling and the service they would provide to the government. They are classified across three axes: confidentiality, integrity, and availability.

FedRAMP as a program has been through a lot over the years it has existed. Different authorization paths, different requirements and standards, multiple rounds of streamlining and changes; it's been a rocky road. Things are starting to smooth out now that FedRAMP 20x is broadly available, but there's still a lot to learn or to question before you can be fully up to speed. So, let's talk about authorization and where we stand today.

Working on a government contract is a big deal for many businesses. It's also frequently the culmination of months (if not years) of effort in building, architecting, defining, and securing systems meant to handle the sensitive information the government needs you to handle. It would be miserable to miss a step and fail at the finish line, but it's surprisingly not too uncommon that it happens.

CMMC is vast and complex, but when you drill down to the heart of it, it's all about one thing: properly securing CUI. And yet that, in and of itself, is a problem. All CUI needs to be marked, which means if you receive CUI from your agency or prime, it needs to be properly marked. And it means if you produce CUI, you need to mark it properly yourself. How do you know what is and isn't CUI, and how do you mark it properly? What happens if you get it wrong?

When you read through the posts on the Ignyte blog focusing on CMMC, you'll see that just about everything we talk about, unless otherwise specified, refers to CMMC Level 2. This is because it's the impact level that the vast majority of DoD contractors are going to need. CMMC Level 1 is the lowest level, protecting the least sensitive of the sensitive information the government has to offer. If all you're handling is Federal Contract Information (FCI), Level 1 is enough for you.

CMMC is increasingly important for any company that is even tertiary to the Department of Defense and the defense industrial base. Prime contractors are prime targets, but even two, three, four, or more steps down the chain, CMMC may be mandatory. It's all about protecting information, after all. This means a lot of businesses are looking seriously at CMMC, and a lot of high-level executives are being asked to put their names on things they might not understand at a glance.

For most of the history of the FedRAMP program, it has been more or less isolated. Despite sharing much of the same cybersecurity DNA with other frameworks, like CMMC and ISO 27001, no formal reciprocity ever came into being.