This post explains how I am using OpenControl and ComplianceLib, a couple of tools from the emerging discipline of supply chain compliance documentation automation, to manage re-usable compliance documentation content applicable to multiple systems at multiple government agencies.
The post shares how the real world example of mapping the 800-53 controls to Drupal projects (e.g., plugins) was solved by documenting the controls once in a publicly available repository using the OpenControl data format and then programmatically generating customized documents private system documentation using the open source ComplianceLib software library and a bit of Python`.
Re-usable, iteratively written compliance content would be a blessing. I write iteratively. I make typographical errors. Others suggest revisions. Documenting and maintaining mappings betweem system components and compliance controls once and re-using that content would save time and improve documentation quality.
Take the following scenario. I consult with a system-integrator who supports Drupal web sites at multiple agencies. Recently, one of the agencies asked us to document which Drupal projects supported which 800-53 controls. This should be a solved problem after years of government agencies using Drupal for websites, something that any team member could quickly google, share a link, and import into system documentation and System Security Plans.
But alas, this tasks instead falls to the resident FISMA expert to repeatedly figure out for each Drupal system at each agency going through FISMA for an Authorty to Operate. I've helped this particular system-integrator with five Drupal systems at five agencies already. Not every single agency requested this level of control detail, but the would certainly all benefit if only the information
In fact, a colleague suggested that I use the term "Drupal project" instead of "Drupal plugin" in my documentation. By following DRY principles, I've made the necessary changes across each OpenControl file in the source repository and then re-ran the scripts to generate new versions of my artifacts.
Creating re-usable compliance content involves overcoming a number of barriers. For the purposes of this post, we will focus on just three barriers:
- need for a structured format (e.g., machine-readable) so we can automatically re-generate artifacts and support multiple artifacts with different formats
- need to update generic content inside of multiple documentation repositories of differing types, some of which are treated sensitive and private
- need for a solution simple and standardized enough for others to use, maintain, and extend
Before we go any further, here is a summary of the mappings between common Drupal projects and controls from the NIST SP 800-53 v4.
The below table is a fine representation of the mappings, but it doesn't provide us with re-usable snippets of how each control is met or help us much including the information in system documentation beyond copy and paste.
| Drupal Project | 800-53 Control |
|---|---|
| Automated Logout | AC-12 Session Termination |
| Flood-control | SC-5 Denial Of Service Protection |
| Session Limit | AC-12 Session Termination |
| TFA | AC-2 Account Management; AC-6 Least Privilege; (SI-7) Software, Firmware, And Information Integrity - b/c preventing user to escalate privilege |
| Paranoia | AC-6(1) Least Privilege - Authorize Access To Security Functions |
| Watchdog | AU-2 Audit Events; AU-3 Content Of Audit Records; AU-7 Audit Reduction And Report Generation; AU-8 Time Stamps; AU-9 Protection Of Audit Information; AU-14 Session Audit; |
| Ejector Seat | AC-12 Session Termination? |
| GovReady | ?CDM, patching |
This list can be extended to list additional mappings of controls to Drupal tools, re-posted below:
Supporting RMF Controls with Drupal Tools & Practices
| RMF | Control Title | Drupal Tool / Practices | Notes |
|---|---|---|---|
| AC-2 | Account Management | User module | core |
| AC-2(5) | Inactivity Logout | autologout | contrib |
| AC-6 | Least Privilege | Roles and perms | core |
| AC-6(9) | Audit Use of Privileged Functions | SELinux auditd | Red Hat SELinux |
| IA-5 | Authenticator Management | password_policy | contrib |
| AU-2 | List the Auditable Events | logging_alerts | contrib |
| AU-6 | Audit Review, Analysis, And Reporting | Syslog / ELK | DevOps |
| SA-3 | System Development Lifecycle | Agile Methodology | Agile Government Leadership |
| SA-5 | Use of Live Data | Drush sqlsanitize, Devel Generate (or Faker) | drush contrib |
| SA-10 | Developer Configuration Management | Code Reviews Automated Testing | Team structure, DevOps |
| SA-15 | Development Process | E.g. GitFlow | Jenkins, DevOps... |
| CM-3 | Configuration Change Control | Drupal 7 Features, Drupal 8 CMI | contrib, core |
| PS-1 | Personnel Security Policy | CivicActions/security-policy | Write one! |
| RA-5 | Vulnerability Scanning | Security Review, Paranoia, OpenSCAP/GovReady | contrib, contrib, GitHub |
| SC-7 | Deny by Default / Allow by Exception | CDN, VPC, iptables, Bastion SSH | Sysadmin |
| SC-13 | Cryptographic Protection | Encrypt, Field Encrypt, File Encrypt | contrib |
| SC-18 | Prevent Downloading Execution | SecKit Private file system | contrib, core |
The Drupal use case is just a specific instance of a more general problem of how to create and manage snippets of compliance content in a re-usable manner, ideally following the DRY (Don't Repeat Yourself) principle. A variety of applications have plugins, modules and tools that address specific hardening and compliance controls.
The following table summarizes various approaches we could use to capture our snippets of compliance content and their respective limitations.
| Approach | Limitations |
|---|---|
| Jira tickets | limited sharing; content buried in closed tickets |
| System Security Plan | limited sharing; may not yet be written; organized by controls; not machine-readable |
| Spreadsheet | overtime people forget where that spreadsheet is |
| Word document | not machine-readable; cumbersome to maintain |
| Google doc | not machine-readable; prohibited by some agencies |
| Gist, pasteboard | editing by original author only; does not address data format |
| System documentation | differs by organization; not share-able across organizations |
- information captured
- shared with more than one person
- can be updated
- information is machine-readable
- shared with community
- editable by approved parties only
- changes tracked
- part of system's documentation
- publicly available for re-use
- conforms to a supported, standardized structure
- gracefully supports cascading/local revisions
- generated and maintained by upstream by suppliers
The solution we adopt uses an emerging
Several of my colleagues are very involved with Drupal project. One has recommended the proper place for the Drupal Project OpenControl repository is within the Drupal project. I couldn't agree more. Because the documentation is structured and in a repository, its easy to move ownership. And who better to map controls to Drupal projects and configuration settings than the Drupal community?