Compliance: Debunking The NIST-ique of Regulations 

When you are a new Information System Security Officer (ISSO), System Owner or Information Assurance Engineer in the Federal Government IT industry and find yourself responsible for regulatory compliance for a government IT system, there are some very scary phrases that will likely be thrown your way: 

“This system is mission-critical and there is an Authority To Operate (ATO) for it coming due next month.” 

“We’ve got 50 overdue Plan of Action and Milestones (POA&Ms) and 20 failing controls, and the Authorizing Official (AO) wants a status briefing in the morning.” 

“There’s going to be two additional enclaves added to this system, we’re going have to go through the workflow again.” 

Fortunately, there are many resources which can assist you with understanding, implementing and ensuring compliance for your system. Hopefully this blog can be one of them! 

This post will cover the two foundational elements to compliance that everyone responsible for it must understand: 

  1. The Risk Management Framework Process and Workflow 

From a broad, philosophical perspective, all compliance follows a workflow designated by your government agency. There are different approval steps and different approvers for your system for it to have authorization to operate. All sub-steps are arbitrary (e.g. one agency might have three people sign off on an ATO, while another might only have one) but it is essential to understand the underlying six-step RMF process: 

The first necessary step to take is to categorize the nature of your system. This must be done regardless of whether you’re bringing an on-premise, hybrid or cloud system online. Everyone involved with the authorization, operation and accreditation of this system needs to understand the level of security it needs in order to proceed properly. 

The next step is to select the security controls. If you’re operating a cloud system, this is where things will likely get a lot easier. Controls are either hybrid (responsibility is shared), inherited (responsibility lies with the control provider) or you (the ISSO) are responsible for directly implementing them. With a cloud system, you’re likely inheriting most of your controls since the cloud provider (e.g., AWS or Azure) is responsible for maintaining a large amount of the security issues in the shared environment. Please note that there are some excellent resources on the division of security responsibilities and the Shared Responsibility Model provided by almost every cloud provider. Regardless, it is still important to select your controls well: there are more than 18 control families, and they cover all aspects of security. 

After your controls are selected, you will need to implement them. For the cloud, a lot of that implementation will likely take place in a physical environment from where you access your system. For example: if you are operating a cloud system with a high level of risk, you will need to ensure that the access to the endpoint accessing your cloud system is restricted. This will probably mean (hypothetically in this example) stationing that endpoint behind multiple layers of guards, biometric readers and password-protected endpoints. 

Next, the controls need to be assessed after their implementation. This concept is very straightforward, but keep in mind that there are many ways to do it. Some RMF workflows will require only a self-assessment before the authorization decision, while others require multiple independent assessments. Having an accurate assessment stage is crucial: it will be one of the biggest deciding factors for determining if your system is ready to authorize. 

Now we get to the authorization phase. This is where the Authorizing Official will decide whether the system is secure enough to be brought online for a length of time. There are a wide variety of different lengths of authorization. For some agencies, three years is a standard issuance, for others, one year is the maximum length. It is very likely that all of a system’s controls will not be fully compliant when attempting to get the ATO. If a control is not compliant, a Plan of Action and Milestone (POA&M) will need to be written as a plan for bringing that control into compliance. 

Congratulations! You have received your ATO. Now we need to take the final step and monitor the system. This means POA&Ms will be addressed, controls will be made compliant, and documentation will be updated as needed. This should be done on a regular, frequent basis prior to the next ATO date. 

These six steps represent the steps you will need to take to stand up your system, apply the appropriate security controls, make sure they are functional, get your work validated and monitor your system as it operates to ensure compliance. It’s a proven system for enhancing your cybersecurity posture. But it didn’t just appear out of thin air, it was developed as a direct result of the research and regulations undertaken by National Institute of Standards and Technology (NIST). This leads us to the second foundational element of compliance: 

  2. The Regulations 

NIST is the clearinghouse for cyber regulations followed by the federal government. A division of the U.S. Department of Commerce, it is responsible for publishing standards and special publications that serve as benchmarks and foundational guides for federal agencies to regulate cybersecurity activities. Examples of commonly used regulations from NIST include SP 800-53 Rev. 5 the current guide for security control requirements and FIPS 199, the current guide for how to appropriately categorize the amount of risk surrounding certain IT systems. These regulations will inform the steps that you will need to take in your workflow. 

While this is a very high-level look at the two primary factors driving compliance, critical thinking and attention to detail is needed to successfully get into the details. Security personnel must have the ability to contextualize the diverse array of factors driving security needs and bringing standards up to a baseline level of compliance. At E-INFOSOL, we have decades of experience, dozens of certifications and a passion for ensuring that security at your organization is always moving in a positive direction. We love helping our customers get compliant! 

About the Author

Daniel Broder is a Cloud Security Developer at E-INFOSOL. He has a B.A. in Communication Studies from The College of Wooster and an M.S. in Cyber Security from Marymount University. He is the proud father of two amazing kids and loves to travel, listen to music and cook vegan meals when he can.