zero-trust-catalog

A project to define an OSCAL catalog of controls for Zero Trust and related component models for Red Hat products.

The OSCAL architecture is described in https://pages.nist.gov/OSCAL/resources/concepts/layer/.

This project uses NIST SP 800-207 - Zero Trust Architecture as the definition of a desired Zero Trust architectural state. The controls defined in NIST SP 800-53 rev5 and Cloud Native Security Controls are used as a basis and cross-referenced with the architectural tenets described in NIST SP 800-207.

The catalog of controls in this project is derived from the NIST maintained OSCAL content in: https://github.com/usnistgov/oscal-content.

Background Material

• OSCAL Notes

Requirements from NIST specifications

• NIST SP 800-204B
• NIST SP 800-207A

DoD Zero Trust Overlays

The US Department of Defense has published a document called Zero Trust Overlays which takes the security controls defined in NIST SP 800-53 Rev 5 and associates them with the DoD pillars of zero trust.

Scripts

The dod-extractor.py script extracts the mappings from the Zero Trust Overlays PDF to produce a YAML file containing all the mappings.

The merge-mappings.py script merges DoD mappings into the NIST controls YAML file to produce a composite YAML file containing the NIST controls with additional properties.

- id: ac-2.1
  title: Automated System Account Management
  props:
  - name: label
    value: AC-2(1)
  - name: implementation-level
    ns: http://csrc.nist.gov/ns/rmf
    value: organization
  - class: dod-zero-trust-overlay
    name: Appendix A - Control Tables Allocated to Pillars
    value: User
  - class: dod-zero-trust-overlay
    name: Appendix C - User Pillar Overlay
    value: 1.5 Identity Federation & User Credentialing

The gen-dod-profiles.py script generates an OSCAL profile for each DoD pillar from the DoD-extended NIST controls.

These scripts need the pypdf and pyyaml python packages to be installed. The scripts can be run using the provided Makefile:

% make
vis                  Generate a visualization of controls by pillar
generate             Generate OSCAL profiles for each DoD pillar
resolved             Generate resolved OSCAL catalogs for each DoD pillar
merge                Merge the DoD and CNSWP mappings into NIST controls
yaml                 Generate a YAML version of the NIST extended controls
dod                  Extract the DoD mappings from the PDF
clean                Remove generated files
help                 This help

Summary of NIST SP 800-53 rev5

Groups: 20
    ac: 147 (25) - Access Control
    at:  17 ( 6) - Awareness and Training
    au:  69 (16) - Audit and Accountability
    ca:  32 ( 9) - Assessment, Authorization, and Monitoring
    cm:  66 (14) - Configuration Management
    cp:  56 (13) - Contingency Planning
    ia:  74 (13) - Identification and Authentication
    ir:  42 (10) - Incident Response
    ma:  30 ( 7) - Maintenance
    mp:  30 ( 8) - Media Protection
    pe:  59 (23) - Physical and Environmental Protection
    pl:  17 (11) - Planning
    pm:  37 (32) - Program Management
    ps:  18 ( 9) - Personnel Security
    pt:  21 ( 8) - Personally Identifiable Information Processing and Transparency
    ra:  26 (10) - Risk Assessment
    sa: 145 (23) - System and Services Acquisition
    sc: 162 (51) - System and Communications Protection
    si: 118 (23) - System and Information Integrity
    sr:  27 (12) - Supply Chain Risk Management
Total controls: 1193, top-level: 323

Sample Queries

You need to install yq to make use of these queries.

• yq - Installation instructions
• yq - Documentation

Controls linked to ZTA Tenet 1

Find all controls that have been linked to ZTA Tenet 1 with a zta-tenet property annotation:

yq '[.controls[]
   | select(contains({"props":[{"name":"zta-tenet","value":"1 -"}]}))]' \
   cnswp-v2-controls.yaml

- id: control-206
  class_: CNSWP-v2.0
  title: All cluster and workloads operators are authenticated
  props:
    - name: section
      value: Access
    - name: assurance-level
      value: N/A
    - name: risk-categories
      value: N/A
    - name: refs
      value: IA-7 Cryptographic Module Authentication
    - name: zta-tenet
      value: 1 - All data sources and computing services are considered resources
- id: control-207
  class_: CNSWP-v2.0
  title: cluster and worklods operate actions are evaluated against access control policies governing context, purpose, and output
  props:
    - name: section
      value: Access
    - name: assurance-level
      value: N/A
    - name: risk-categories
      value: N/A
    - name: refs
      value: IA-7 Cryptographic Module Authentication
    - name: zta-tenet
      value: 1 - All data sources and computing services are considered resources

Count of annotated controls

Count the number of controls that have zta-tenet annotations.

yq '[.controls[]
   | select(contains({"props":[{"name":"zta-tenet"}]})
            or contains({"props":[{"name":"x-"}]}))
   ] | length' \
   cnswp-v2-controls.yaml

151

No zta-tenet annotation

Find all controls that don’t have a zta-tenet property annotation

yq '[.controls[]
   | select(contains({"props":[{"name":"zta-tenet"}]}) == false
            and contains({"props":[{"name":"x-"}]}) == false)
   ] | .[] | .id' \
   cnswp-v2-controls.yaml

0

Controls per section

List the number of mapped controls in each CNSWP section.

for s in Access Compute Deploy Develop Distribute Security\ Assurance
do
    C=`yq "[.controls[]
    | select(contains({\"props\":[{\"value\":\"${s}\"}]}))
    ] | length" cnswp-v2-controls.yaml`

    N=`yq "[.controls[]
    | select(contains({\"props\":[{\"value\":\"${s}\"}]}))
    | select(contains({\"props\":[{\"name\":\"zta-tenet\"}]}))
    ] | length" cnswp-v2-controls.yaml`

    echo "${s}:  ${N} of ${C} are mapped"
done

Access:  43 of 55 are mapped
Compute:  23 of 35 are mapped
Deploy:  3 of 6 are mapped
Develop:  3 of 17 are mapped
Distribute:  27 of 36 are mapped
Security Assurance:  20 of 22 are mapped

Anything that is not mapped will have a x-note or x-query property.

X- notes

List the notes and queries that need to be reviewed.

yq '[.controls[] | .props[] | select(contains({"name":"x-"}))] | .[] | .value ' \
   cnswp-v2-controls.yaml | sort -u

Development infrastructure is a zero trust resource
Is there a relevant zero trust tenet to link with HSM secret storage
Need to consider key rotation requirements in id:control-197
Not directly related to tenets of zero trust
cryptographic secret storage
data integrity
data security
encryption at rest
high availability
identity attestation
relationship to zero trust?
resource isolation
resource isolation is not explicitly mentioned in tenets of zero trust
resource lifecycle management?
software quality
software quality feedback loop

Tenet mappings

List the number of mappings for each ZTA Tenet.

for n in 1 2 3 4 5 6 7
do
    MAPPINGS=`ack -c "${n} - " cnswp-v2-controls.yaml`
    echo "Tenet ${n} - ${MAPPINGS}"
done

Tenet 1 - 13
Tenet 2 - 10
Tenet 3 - 8
Tenet 4 - 32
Tenet 5 - 13
Tenet 6 - 19
Tenet 7 - 23

List all the mappings for each Tenet of Zero Trust.

for n in 1 2 3 4 5 6 7
do
    echo
    echo "Tenet ${n}"
    yq "[.controls[] | select(contains({\"props\":{\"value\": \"${n} -\"}}))]
    | .[] | .title" cnswp-v2-controls.yaml
done

CNSWP controls with no NIST mappings

• control-255 Forensics capabilities are integrated into an incident response plan and procedures
• control-266 Code should be clean and well commented
• control-274 Should software artifacts become untrusted due to compromise or other incident, teams should revoke signing keys to ensure repudiation
• control-275 Artifacts ready for deployment are managed in a staging or pre-prod registry
• control-276 container images are hardened following best practices
• control-277 Static application security testing (SAST) is performed
• control-278 Test suites follow the test pyramid
• control-279 Artifacts undergoing active development are held in a private registery
• control-290 Automated test results map back to requirements
• control-291 Infrastructure security tests must be employed
• control-293 IaC is subject to the same pipeline policy controls as application code
• control-306 Incremental hardening of the infrastructure is employed
• control-313 Rootless builds are employed
• control-314 cgroups and system groups are used to isolate workloads and deployments
• control-321 Orchestrator network policies are used in conjunction with a service mesh
• control-322 Adhere to supply chain security best practices
• control-323 Restrict access to repository and branches
• control-324 Never store unencrypted credentials or secrets in the Git repository and block sensitive data being pushed to Git
• control-325 Enforce strong identity with GPG Signed Commits, to give accountability and traceability
• control-326 Require linear history and maintain a commit history by disallowing force pushes
• control-327 Enforce branching policy. Especially protect the main branch and require code review before merging
• control-328 Monitor for vulnerabilities, and keep Git and GitOps tools up to date
• control-329 Rotate SSH keys and Personal Access Tokens, block unauthorized access to Git repositories
• control-330 Utilize a dedicated non-user technical account for access where credentials are frequently rotated and short-lived
• control-331 Limit users who can elevate permissions to remove security features to cover their tracks via deletion of audit trails and silencing of alerts
• control-338 Caching is considered for determining encryption requirements in archictures
• control-339 Namespaces have defined trust boundaries to cordon access to volumes
• control-343 Artifact registry supports OCI artifacts