NIST Information Security Compliance and DevOps

The goal of this article is to consider how an organization can adopt DevOps methods for delivering software, while also remaining compliant with Federal Information Security Management Act (FISMA)-mandated information security requirements based on National Institute of Standards and Technology (NIST) guidance. For many organizations subject to these requirements, implementing and assessing NIST-recommended security controls in order to achieve an Authorization to Operate (ATO) for new and existing systems has been a bottleneck to releasing software. It may be hard for these organizations to envision using DevOps to increase the frequency of releases while simultaneously complying with information security requirements. However, NIST guidance envisions organizations using iterative software delivery methods, and has described methods that can support an iterative software development process with frequent releases. These include automated continuous monitoring and ongoing authorization to replace the traditional tri-annual big bang certification and authorization of software. Using the NIST Risk Management Framework (RMF) and implementing NIST security controls need not impede a DevOps organization. On the contrary, it should be possible to even more effectively secure information and systems using both.


DevOps in Brief

DevOps is a portmanteau of Development and Operations, and the goal of DevOps is to break down the traditional separation between these two organizational units. Traditionally, the development unit creates and tests new or modified code, which they hand off to the operations unit to deploy onto the servers that they maintain and operate. This has often resulted in a bottleneck, especially if the development side has adopted an Agile and iterative approach to releasing software updates while the operations side has resisted more frequent production releases because of perceived risk. DevOps techniques such as involving operations staff from the start of development, automating tests, using development and test environments that resemble production as much as possible, and releasing changes in small batches are intended to reduce the risks associated with production releases. The foundation of DevOps is the deployment pipeline, which is a set of tools that coordinate and automate most of the code building, testing and deployment steps and is therefore critical for supporting more production releases. By automating deployment steps, operations staff can avoid tedious and error-prone manual software installation and environment configuration steps.


NIST Risk Management Framework (RMF) in Brief

FISMA mandates compliance with the NIST Federal Information Processing Standards (FIPS). NIST FIPS-199 and FIPS-200 require categorizing information systems based on their impact level (Low, Moderate and High), as determined by the information types used by the systems, and implementing the recommended baseline controls for those levels using the security controls catalog found in NIST Special Publication SP 800-53.

The NIST SP 800-37, entitled “Guide for Applying the Risk Management Framework to Federal Information Systems - A Security Life Cycle Approach”, also known more simply as the “RMF,” describes a six-step process for securing information systems. The steps are: Categorize, Select, Implement, Assess, Authorize and Monitor. As the full RMF title implies, it is meant to apply to the entire development lifecycle, which it defines as including initiation, development, implementation, operation/maintenance and disposition. Although this sounds similar to the standard waterfall process, the RMF states that it can be used with any lifecycle process, including water, spiral and Agile. For example, in the supplemental guidance for the Security Control Assessment task of step 2, the RMF states that “when iterative development processes such as Agile development are employed, this typically results in an iterative assessment as each cycle is conducted” (SP 800-37, Rev 1, p.31). This suggests assessing controls as they are implemented, within each iteration, rather than waiting until development of the product is done. The following quote from the RMF is lengthy, but is useful for understanding NIST’s conception of ongoing authorization:

“Authorization termination dates are influenced by federal and/or organizational policies
which may establish maximum authorization periods. Organizations may choose to eliminate the authorization termination date if the continuous monitoring program is sufficiently robust to provide the authorizing official with the needed information to conduct ongoing risk determination and risk acceptance activities with regard to the security state of the information system and the ongoing effectiveness of security controls employed within and inherited by the system” - (SP 800-37, Rev 1, p.36).

With regards to DevOps, if assessments are completed for security controls that are impacted during development of each release within each iteration, and sufficient continuous monitoring is in place for the production version of the application and its environment, then it should be possible to maintain an ongoing authorization for the product without the need to reassess every control for every release. NIST has provided a paper, Supplemental Guidance on Ongoing Authorization: Transitioning to Near Real-Time Risk Management, for organizations interested in implementing this approach.


Potential Issues in Implementing Security Controls in DevOps Environment

DevOps shows a lot of promise in both increasing benefits to customers by more frequent releases of new functionality while actually reducing the risk of each release. Its goal is to make the release process a low-stress event that can be carried out at any time. However, there other units in most organizations that have a stake in IT, other than development and operations, most notably quality assurance (QA) and information security (InfoSec). InfoSec in particular may be averse to frequent releases because of concerns that they may lead to undetected vulnerabilities making it into production. The job of information security in organizations bound by FISMA and NIST requirements is to ensure that the owners of information systems have managed risk by applying the SP 800-53 controls and that an authorizing official (AO) has explicitly accepted the remaining risk. The RMF requires that the authorization for a security system to operate in production be based on an assessment of its security controls and verification that they are properly implemented and operating as intended. The authorization step is often difficult for development teams to pass. Some reasons for this difficulty include:

  • Leaving security assessments until later in the development process leads to discovery of vulnerabilities that could have been avoided or more easily corrected earlier in the process.
  • Not including security control requirements from the start of planning and designing a new system leads to costly changes later in development or failure to achieve an ATO.
  • Lack of communication and coordination between information security teams and the development and operations teams can lead to adversarial relationship if the teams blame each other for security vulnerabilities.
  • Manual security control testing is too slow for the DevOps goal to create more frequent releases.


Techniques and Tools for Overcoming Issues

Organizations seeking to establish a DevOps process that can overcome the difficulties listed above should consider the following techniques and tools to address them:

  • Start assessments and vulnerability scans from the earliest development cycles, rather than leaving them to just prior to release. Scan in all environments including development, QA, pre-production and production.
  • Categorize the system and select security controls before beginning design and development iterations so that they are included in the overall system requirements rather than added on.
  • Dev and Ops are together, so InfoSec needs to join also (as well as QA). Consider embedding a security analyst with the team to identify requirements and develop tests.
  • There are NIST-approved tools for assessing security controls based on the Security Content Automation Protocol (SCAP) protocol: Developers should create automated tests for controls that are implemented within the system and should brainstorm ways to automate assessing controls outside of the system, such as security documentation. NIST suggests using the Open Checklist Interactive Language (OCIL) for standardizing the collection of data for assessments that cannot be automated.