Security Controls

About

Information security controls frameworks are a bit of a mess, with multiple hard-to-parse formats and inconsistent structures describing similar goals. This project aspires to help users:

1. Easily obtain clean, consistent controls information from one place
2. Easily search, manipulate, and use controls information
3. Map controls across frameworks
4. Easily share controls information with other tools and platforms

... and more.

Risk-Focused

This project is designed to support a thoughtful risk management strategy where security moves beyond mere "compliance" (or "maturity") and into risk mitigation. Controls decisions and priorities should consider the full risk equation and avoid "box-checking."

risk = impact x likelihood
risk = (functional_impact + info_impact) x (threat x vulnerability)
risk =   (functional_impact + info_impact - controls_effect)
       x (threat x (vulnerability - controls_effect))

Controls (a.k.a., actions, requirements, outcomes)

Control Frameworks

ID	Framework	URL	Version	Notes
nist_csf_v1.1	National Institute for Standards and Technology (NIST) Framework for Improving Critical Infrastructure Cybersecurity	NIST CSF	1.1
cis_csc_7.1	Center for Internet Security (CIS) Controls	CIS CSC	7.1	a.k.a., Critical Security Controls, Top 20
800_53_v4	NIST Security and Privacy Controls for Federal Information Systems and Organizations	NIST 800-53	4
800_171_v1	Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations	NIST 800-171	1
owasp_10_v3	Open Web Application Security Project (OWASP) Top Ten Proactive Controls 2018	OWASP Top 10	3	Distinct from OWASP Top 10 Security Risks
asvs_v4.0.1	OWASP Application Security Verification Standard	ASVS	4.0.1

Control Format

All controls are standardized to capture the following fields:

Field	Description	Example
source	framework from which the item was drawn, using the ID listed above	nist_csf_v1.1
id_raw	identifier for the item drawn from the source (may not be globally unique), in its original format	RS.MI
id	globally unique (namespaced) identifier created by combining source with lowercase, no-spaces id_raw	nist_csf_v1.1:rs.mi
tier_raw	tier (group) for the item drawn from the source (may not be globally unique or consistent), in its original format	Category
tier	0-based level in the hierarchy of the original framework (i.e., the number of ancestors for this item)	1
seq	strictly increasing sequence number capturing the order of controls within a tier of a framework (optional), drawn from the source	3
title	short description of the item (optional), in its original format	Mitigation
description	long description of the item (optional), in its original format	Activities are performed ...

Relationships (e.g., equivalence, hierarchy, association)

Relationship Types

Relationships ("mappings") contain their Simple Knowledge Organization System (SKOS) mapping type, one of the following:

Type	SKOS Type	Properties	Notes
Hierarchical	skos:broadMatch, skos:narrowMatch	transitive, each is the other's inverse	dog skos:broadMatch mammal ("is specific example of"), mammal skos:narrowMatch dog ("is generic category including"). Only capture one level of ancestry if possible, as the rest can be inferred through transitivity.
Associative	skos:relatedMatch	non-transitive, symmetric (bidirectional)	generic, non-hierarchical relationship
Close equivalent	skos:closeMatch	non-transitive, symmetric (bidirectional)	"concepts ... sufficiently similar that they can be used interchangeably in some [applications]"
Exact equivalent	skos:exactMatch	transitive, symmetric (bidirectional)	"two concepts ... that can be used interchangeably [in many applications]"

Relationship Format

All relationships are standardized to capture the following fields:

Field	Description	Example
source	framework from which the relationship was drawn, using the ID listed above, or community for those drawn from community input	nist_csf_v1.1
head	id of the first endpoint (control, item) in this relationship; by convention (optionally), for non-directional relationship to another framework, this is the item from source	nist_csf_v1.1:rs.co-3
tail	id of the second endpoint (control, item) in this relationship	nist_800_53_v4:ir-4
type_raw	type for the relationship from the source (may not be globally unique), in its original format; leave blank for outline-based hierarchies or other non-explicit relationship types	Informative Reference
type_skos	SKOS mapping type for the relationship, which captures its directionality, transitivity, and symmetry	skos:relatedMatch
id	globally unique identifier, likely necessary, but nothing semantic comes to mind right away	TBD

Labels (a.k.a., tags, metadata)

TODO

Notes

• Hierarchical groups of controls are captured as higher-tier controls, even when not explicitly described that way in the source (e.g., CIS CSC implementation groups). When a set of controls is defined by some cross-cutting aspect of the controls (e.g., 800-171 basic vs. derived requirements, or CIS CSC asset types) rather than a hierarchy, this is captured using labels.
• This project maintains format from the source document(s) in order to comply with licenses and avoid becoming a copy-editing nightmare. This means data retains capitalization artifacts, style inconsistencies, and typographical errors, among other issues. Proposed fixes should first determine if the issue is present in the underlying source (in which case, it will likely remain by design, and to comply with license terms).
• This approach clearly leaves out useful information from each framework, but benefits from simplicity and consistency. This project emphasizes these values over comprehensiveness.
• Items deeper than tier-2 are wrapped into their nearest tier 2 ancestor (e.g., 800_53_v4 tier-3 items AC-2h.1., AC-2h.2., AC-2h.3. are included in tier-2 item AC-2h.).
• "Withdrawn" controls in 800_53_v4 do not appear in the consolidated data.
• Leading and trailing spaces were removed in consolidated data.
• Because of disclaimers in the source material, there's often not much more than an associative match (skos:relatedMatch) that we can pull from the text itself. Take the following from the NIST CSF: "Mappings between the Framework Core Subcategories and the specified sections in the Informative References are not intended to definitively determine whether the specified sections in the Informative References provide the desired Subcategory outcome." That is, you could do all those things and still not have what we're looking for. Or maybe you would. Good luck.
• DISCLAIMER: Much of the initial consolidation was done by hand with the assistance of good old Excel. There are likely transcription errors. Please create an issue or pull request if you identify a problem.

Use Cases

The data and tools in this project can support:

1. Efficiency and cost savings by avoiding duplication of effort across multiple departments (e.g., security operations and product development)
2. Prioritizing controls based on cross-framework coverage (pareto principal). For example:
   1. NIST 800-53 has 256 distinct tier-1 controls (the lowest level that maps directly to the NIST CSF, useful because they get more detailed than the sub-categories). Of those, the NIST CSF only references 212, leaving 44 that maybe don't move the needle if NIST CSF is your governance model of choice.
   2. It's a long-tail distribution too: the top four related controls (nist_800_53_v4:cp-2, nist_800_53_v4:ir-4, nist_800_53_v4:ca-7, nist_800_53_v4:si-4, and nist_800_53_v4:ir-8) show up 91 times out of 508 total mappings - effort on just four controls helps advance over 20% of the "Informative References" across the entire NIST CSF. On the other end, implementing the 107 controls that show up just once gets you similar coverage.
3. Choosing an initial framework for a new or re-built security program.
4. Transitions from one regime to another (e.g., due to an acquisition or initiative)
5. Integrating controls information into task tracking, ticketing, planning, and GRC tools (e.g., Archer, SAP, github/gitlab, JIRA, Zendesk)
6. Integrating controls information into operations tools like log aggregators, SIEMs, visualization tools, and orchestration platforms (e.g., Elastic Stack, Splunk, Demisto, Phantom)
7. Visualizing coverage and progress towards goals
8. Prioritizing controls based on the threat component of risk (e.g., in concert with threat intelligence and adversary activity taxonomies like MITRE ATT&CK or CAPEC)
9. Prioritizing controls based on business, mission, regulatory, and legal impact components of risk (e.g., using lists of critical assets, information, and accounts)
10. Prioritizing controls based on the vulnerability component of risk
11. Prioritizing controls based on the confidentiality, integrity, and availability requirements of assets and information

Frequently Asked Questions (FAQ)

• Why do you mix application security and organizational/corporate information security frameworks? Our master list strives to include all reputable information security controls, across a wide variety of domains. We support the use of labels to add metadata to controls, and if that distinction is important to your team, we encourage you to capture it within the mode. More broadly: different organizations assign security responsibilities differently, and for many firms their applications are their entire organization. There's often no meaningful distinction in the world of small business, DevSecOps, or integrated IT/security teams - the same people are responsible for most of it!

• How did you choose the relationships (mappings)? We created initial mappings based on the source documents themselves (i.e., they say X maps to Y), as well as a good-faith effort to apply the relationships ("mappings") in the Simple Knowledge Organization System (SKOS), as noted above. In so many cases it's a matter of judgment and usability - if you think X should be mapped to Y, please open an issue or pull request and we can discuss it! Because relationships have metadata, you can also create and use your own without breaking anything.

• What is the easiest way to update this data? We find working with the CSV the most straightforward, using Excel or Libre Office Calc. You can then produce the other formats (jsonl and json) using free command-line tools like csvkit and jq:

  # pip3 install csvkit
  $ csvjson controls.csv | jq -c '.[]' > controls.jsonl
  $ jq -s '.' controls.jsonl > controls.json

• Why isn't this in a database? Text files are universal and CSV and JSON cover a lot of use-cases, both technical and non-technical. If you want a database-like experience, you can import them into your DB of choice, or use a tool like q which lets you run SQL queries on text files:

  $ q -H -d , "select id, title, description from ./controls.csv where id like '%csf%' and tier = 0"
  # nist_csf_v1.1:de,Detect,Develop and implement appropriate ...
  # nist_csf_v1.1:id,Identify,Develop an organizational understanding ...
  # nist_csf_v1.1:pr,Protect,Develop and implement appropriate ...
  # nist_csf_v1.1:rc,Recover,Develop and implement appropriate ...
  # nist_csf_v1.1:rs,Respond,Develop and implement appropriate ...

  The JSON formats make it straightforward to work with the data programmatically:

  const _ = require('lodash')
  const controls = require('./controls.json')
  const relationships = require('./relationships.json')
  // go to town ...

References and Prior Art

• Open Control
• See NOTICE for additional source material and references

Roadmap

• Publish clean, consistent controls framework data
• Determine mapping approach using SKOS, ISO 25964-2 and source documents
• Capture hierarchical mappings for NIST CSF
• Capture associative mappings for NIST CSF to 800-53 (from CSF source xml)
• Capture associative mappings for NIST CSF to CIS CSC (from NIST CSF source)
• Capture hierarchical mappings for CIS CSC (excluding implementation groups)
• Capture implementation groups for CIS CSC
• Add an optional sequence number for controls at a tier (within a framework) for in-source ordering
• Add all sequence numbers for NIST CSF, CIS CSC, and 800-171
• Add all sequence numbers for NIST 800-53
• POC for visualization capabilities
• Tool for capturing/editing relationships
• Capture associative mappings for CIS CSC to NIST CSF (from CIS CSC source)
• Capture hierarchical mappings for 800-53
• Capture hierarchical mappings for ASVS
• Capture equivalence and associative mappings for 800-171 to 800-53
• Capture equivalence and associative mappings for CIS CSC to NIST 800-53
• Consider ways to include adversary activity taxonomies (e.g., ATT&CK, OWASP Top 10 Security Risks, CAPEC)
• Consider including additional frameworks like SOC 2, PCI/DSS, ISO 2700X, COBIT, ITIL, HIPAA/HITRUST, FedRAMP

License and Notice

Controls information is copyright its respective creator and used according its respective license. See the NOTICE file for details on each source. These licenses include:

• Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International Public License (e.g., for items marked cis_csc_v7.1)
• Creative Commons Attribution ShareAlike 3.0 (e.g., for items marked asvs_)
• Public domain and not subject to copyright in the United States (e.g., for items marked nist_)
• Creative Commons Attribution-ShareAlike 4.0 International Public License (e.g., for items marked owasp_10_)

Original assets are Copyright 2020 Counteractive Security and licensed under the Apache License, Version 2.0 (the "License"); you may not use this work except in compliance with the License. You should have received a copy of the license along with this work, and you may obtain a copy of the License here.

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

Changelog

Version	Release Date	Notes
N/A	N/A	Pre-release