Security and Compliance in the World of Government

Adam Clater is chief architect of North America public sector at Red Hat

Innovation and compliance standards can make strange bedfellows in federal IT. Developers can often feel as if security checkpoints inhibit their efforts, while those in charge of compliance monitoring may quickly call out development that does not conform to security standards.

» Get the best federal technology news and ideas delivered right to your inbox. Sign up here.

We have seen this play out time and again, most recently with the General Services Administration’s Office of Inspector General report on 18F development, and we likely have not seen the last of these types of disagreements. It is incumbent upon industry and government to work together to solve these roadblocks to innovation and national security.

Setting a Secure Baseline for Government Computing

As part of its role in implementing the Federal Information Security Management Act, the National Institute of Standards and Technology takes an active, public interest in protecting the nation’s information technology assets. Part of that interest today takes form as NIST Special Publication 800-53.

NIST SP 800-53 controls are a collaborative effort of a joint task force including the departments of Defense and Homeland Security, the Office of the Director of National Intelligence, NIST, MITRE and representatives from private industry. Foreign governments, private industry and others frequently look to NIST SP 800-53 as their baseline for security implementations. Of course, additional controls can be layered on top of them, but NIST SP 800-53 represents a globally accepted baseline.

DOD implements NIST SP 800-53 controls as the DOD Secure Technical Implementation Guide, or STIG. This is made publicly available, and many within government and private industry participate in the implementation of NIST SP 800-53 for vendor-supported software. This content is available in an open format referred to as Security Content Automation Protocol. SCAP is yet another standard that we can thank the folks at NIST for developing.

Are you noticing a trend? NIST has provided strong leadership in defining the controls, as well as validating tooling for the implementation of these controls. Vendor implementations of SCAP tooling are certified by NIST and listed at the National Vulnerability Database. Compliance with these NIST standards is key to implementation of FISMA.

For open-source software like the Linux operating system, these controls are actively implemented via the SCAP Security Guide, a collaborative effort that includes contributions from government, academia and private industry. This content is made freely available for the evaluation and remediation of these security controls. In fact, the SCAP Security Guide community maintains content for controls that conform to the DOD STIG, the U.S. Government Configuration Baseline, the Department of Justice Criminal Justice Information Systems, the Payment Card Industry Data Security Standard (PCI-DSS), and others.

‘Compliance’ just another word for ‘bureaucracy’?

As Mark Schwartz, chief information officer at U.S. Citizenship and Immigration Services, noted in his book, “The Art of Business Value”:

“Bureaucracy in an organization often leads to compliance requirements, which in turn generate work items that must be prioritized alongside functional requirements. It is easy to mistake these requirements for waste. Waste is whatever does not add value, and compliance requirements are not concerned with adding direct customer value. This explains the frustration that teams often have when confronted with bureaucracy.”

This perception of compliance can often lead to security as an afterthought of our most important development efforts. Thankfully, there are efforts underway to deploy extensive automation tooling to simplify not only security reporting and remediation but also the amount of manual documentation required to assert that one is “in compliance” with mandated security controls.

The folks at 18F are working in an open-source community called Compliance Masonry in an attempt to alleviate some of the complexities of constructing certification documentation in an automated fashion. The principles of automation and automated documentation are key to solving our security and compliance issues as technology moves through its life cycle.

Compliance requirements are mandated across the federal bureaucracy for a reason—often those building, deploying and maintaining our national infrastructure are not security specialists. They are frequently developers, database administrators or other professionals whose specializations lie elsewhere. Thus, the efforts to distil and document decades worth of security knowledge and define a standard—while automating the implementation and reporting of controls—is a box worth checking.