Compliance Is Not Security. Compliance Scales Security.
BY GREG ELIN
To all of us all of hoping to have better IT and cybersecurity, let’s get one thing straight: Compliance is not security.
Compliance scales security. Compliance is so critical to scaling security, we often mistake compliance as just another aspect of security and make compliance just another responsibility of our security teams. And that always ends in tears.
Being good at something is not the same as being good at scaling something. Security professionals are way too busy guarding secrets and fighting threats to be in a good mental space to undertake the outreach and continuous engagement that is central to sharing and scaling practices.
When you do compliance, you want someone who spends their days thinking about sharing and increasing, not someone who spends their days thinking about guarding and limiting.
When we recognize that compliance is about scaling, it makes sense that compliance has its own tools and needs to move with the same or faster velocity as software production. Otherwise, our ability to scale our security practices forever lags behind the pace of our production and pace of black hats exploiting missing patches and misconfigurations.
Compliance is the discipline of verification at scale
Compliance is the technique humans have developed to attest and verify the safety of systems that are significantly more complex than humans can individually inspect and judge. Compliance is a systematic set of practices for supply-chain management and information sharing to provide confidence that a large, complex system performs as planned.
It is as difficult to inspect every line of code and interaction in a modern software application as it is to inspect every inch of building material and mechanisms in a modern office building.
Zoning laws, building codes, and inspectors functioning properly enable multiple parties to simultaneously and independently develop real-estate at the scale of cities with confidence the buildings don’t crumble. Similarly, IT standards, policies, and auditors functioning properly enable multiple parties to develop software at the scale of our organization activities with the confidence they don’t fail and common exploits don’t jeopardize our data.
Increasing security and resiliency matters, but it’s a skill with limited impact if it can’t be scaled to the full scope of organization activities.
Compliance people are not security people
What makes compliance different from security also makes compliance people different from security people. Believing security specialists can perform the work of compliance specialists makes as much sense as believing football centers can play quarterback.
Security people
- protect and defend valued assets
- keep secret and limit access
- stand guard and practice paranoia
- operate (normatively) behind locked doors with privileged access
Compliance people
- promote and expand use of valued practice
- share and distribute information
- perform outreach and practice engagement
- operate (normatively) in the open
Organizations that confuse the subject matter of security (defense) with the subject matter of compliance (scaling verification) mistakenly assign the lead role of compliance to people who operate behind locked doors and guard secrets for a living. The results are the same as running a welcome center from a watch tower. Compliance happens, but happens slowly with secondary priority to daily security activities.
Having an open door and doing active outreach are the table stakes for a proper enterprise compliance operation. Real wins come from compliance teams studying how software teams work in order to make cybersecurity practices work easily for those teams.
Organizations that understand the underlying purpose and benefit of compliance assign compliance to specialized teams that have scaling as their first priority, who strive daily to build culture, processes, and tools that make verification invaluable and routine throughout the supply chain and organization.
Compliance tools are not security tools
In the compliance space where I am most familiar, FISMA and federal government IT, the routine mis-assigning of compliance to security has also led to mis-aligning the cybersecurity tool ecosystem exclusively around the use case of privileged security personnel monitoring production from the NSOC (Network Security Operations Center).
For example, security teams at many government agencies use the popular Nessus configuration and vulnerability scanner to test servers and hand off thick reports of potential security and compliance issues to developers and system administrators. The security staff actively refuse anyone else in the organization direct use of the software to do their own scans. They fear developers unfamiliar with the tool’s power will scan and break production systems. Scanning is performed on systems under development only when the systems are about to be deployed into production. In short, security people naturally see the software as their tool because it was designed and optimized for their use and purchased with their budget.
Such thinking is understandable, but outdated. Modern development teams use virtualization and Infrastructure as Code software like Chef, Docker, and Ansible to work entirely in computing environments that can be re-created automatically in minutes or seconds with a single command. Limiting use of compliance scanning software to security teams only keeps scanning a rare and special ritual, reduces iteration cycles, and reinforces developer’s security-is-not-my-job attitude. It creates more work for security and developers, not less.
Tools like enterprise network scanners get the endpoint verification scaling right by automating the inspection of thousands of devices. But they get the organizational verification scaling wrong by focusing so intently on production where errors and shortcomings are the most costly to fix.
It’s no surprise developers, project managers, and customers fail to address security and compliance during development when they have so few tools for doing so.
The NIST Risk Management Framework (NIST RMF) tells us risk management is a whole organization activity. Yet few if any compliance products focus on Organization (Tier 1) or Mission / Business Processes (Tier 2) as described by NIST RMF.
With the exception of code analyzers, security and compliance tooling ignores all portions of the System Development Life Cycle until things get close to deployment. The focus on deployed technology is a problem for managing risk when 14 of the 18 NIST RMF Security Control Families are Management or Operational.
I’m not saying current compliance tools are bad. I’m suggesting their current scope misses much of the domain of compliance. Their narrow scope limits their impact on scaling security practices in our organization.
Security practices can’t be effectively scaled generating documentation by hand and throwing thick reports over silo walls. We need compliance tools and artifacts that embrace online organizations, employees collaborating in real-time, and structured data’s reusability over word documents.
Below are some new tools shipping the kind of features that better support scaling with how software is being developed in 2015. (Disclosure: GovReady is my company and I contribute to Control Masonry and OpenSCAP.)
- Control Masonry, created by the General Services Administration’s Agile IT delivery shop 18F, provides repository-friendly, reusable structured data to bring compliance closer to code so developers can attest to and verify security controls as part of development.
- OpenSCAP, a NIST-certified SCAP-scanner developed by RedHat and now a larger community project on GitHub, offers open source licensing and SCAP-Security-Guide provides restriction-free machine-processable security content that together removes licensing and purchasing as a barrier to the habit of scanning throughout the organization.
- GovReady Toolkit, a bash shell utility for accessing and integrating OpenSCAP with developer tasks, provides developer- and automation-friendly command line syntax in the style of git and vagrant to flatten developer learning curve of configuration scanning.
- Chef’s audit mode, a recently released feature of the popular Chef IT automation software, embraces Compliance as Code by directly including audit and remediation capability into continuous integration pipelines.
- DevOps Audit Defense Toolkit and community organized by the awesome Gene Kim crowd helps DevOps culture explain how it supports compliance to auditors.
- CloudAudit is an effort to standardized interfaces and name spaces to share audit data across organizations.
- Gauntlet, an open source penetration testing software tool, is a developer-targeted security penetration testing for continuous integration environments.
- ReadTheDocs, a documentation generation and hosting service, builds attractive, granularly linkable online documentation derived from developer-maintained machine and human readable markdown files in git repositories.
Compliance culture is about scaling risk management practice
To summarize, if thinking about compliance makes you cringe, chances are your organization has made the common mistake of treating compliance as an aspect of security, instead of its own discipline and set of practices.
Compliance is painful because you are asking your security professionals who are busy standing guard and fighting fires to undertake outreach, information sharing, and practice evangelism.
Compliance is painful because your compliance budget and tools focus heavily in monitoring technology deployed to production and minimally in scaling the verification of security practices across your organization in all stages of the System Development Life Cycle.
To change this, to better scale the management of risk in our organizations and make our systems more secure, we need only accept and act on what we already know.
Compliance is not security.
