L67 · Security frameworks

Module 10: People, Governance, and Emerging Threats · ~20 min · Lesson 67 of 71

🎯 What you'll learn

• What a security framework is, and why companies use more than one
• NIST CSF 2.0's six functions, ISO/IEC 27001's management system, and the CIS Controls' priorities
• How they differ: outcomes vs a certifiable management system vs a prioritized checklist
• How a framework control becomes something you can point to in a PR, a pipeline or a config

🔥 Why this matters

Granite Ridge Insurance (a made-up company) wants to sign a bank as a distribution partner. The bank sends a 240-question vendor questionnaire: "Are you ISO 27001 certified? Map your program to NIST CSF. Which CIS Implementation Group do you meet?" Question 117 lands on the engineering team: "Describe how changes to production are reviewed and approved." The answer is the team's branch rules and deploy pipeline. Frameworks let outsiders check a company's security, and much of the proof is engineering work you already do.

1. What a framework is (and isn't)

Think of a building code: it doesn't design your house, but it lists what an inspector will check.

A security framework is a published, structured list of what a security program should achieve or do, so organizations can organize their work and compare it. Frameworks come in three flavours, and the big three each represent one:

 QUESTION IT ANSWERS      EXAMPLE              LOOKS LIKE
 ───────────────────────────────────────────────────────────────
 What outcomes should     NIST CSF 2.0         "Access is managed
 we achieve?                                   and reviewed"
 How do we run the        ISO/IEC 27001        risk process, policy,
 program, provably?                            audits, fixes
 What do we do first?     CIS Controls v8.1    "Inventory your
                                               software" (IG1)
 Exactly which setting?   CIS Benchmarks,      "EKS API endpoint
                          your own configs     not public"

A framework doesn't replace risk assessment (L02); it gives that work structure and vocabulary.

2. NIST CSF 2.0: six functions, outcomes only

The NIST Cybersecurity Framework (CSF) started in 2014 for US critical infrastructure. Version 2.0, published on 26 February 2024, widened the audience to every kind of organization and added a sixth function, Govern. It's voluntary, but regulators, auditors and boards use it as common vocabulary.

               ┌──────────────────────────┐
               │ GOVERN (GV)   new in 2.0 │
               │ strategy, roles, policy, │
               │ oversight, supply chain  │
               └────────────┬─────────────┘
                            │ steers the other five
   ┌──────────┬──────────┬──┴───────┬──────────┐
   ▼          ▼          ▼          ▼          ▼
 IDENTIFY   PROTECT    DETECT     RESPOND    RECOVER
 (ID)       (PR)       (DE)       (RS)       (RC)
 assets,    identity,  monitor,   manage,    restore,
 risks,     data,      find       contain,   communicate
 improve    platforms  anomalies  report

The CSF Core is a hierarchy: 6 functions, 22 categories, 106 subcategories. Each subcategory is an outcome, not an instruction. For example, PR.AA-05 reads: "Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties." It doesn't say "use OPA" or "review quarterly"; that's your decision.

A profile records your current or target state per subcategory (the second deep dive builds one). Tiers (1 Partial to 4 Adaptive) describe how rigorous your risk governance is. For the "how", the CSF points to informative references such as SP 800-53 and the CIS Controls. NIST SP 800-61 Rev. 3, the incident response guide from L63, is itself a CSF 2.0 "community profile".

3. ISO/IEC 27001:2022: a management system you can certify

The bank asks for a certificate, and CSF can't give you one. ISO/IEC 27001 can.

ISO/IEC 27001 specifies an information security management system (ISMS): the policies, processes, roles and records an organization uses to manage security risk and keep improving. It has two parts:

• Clauses 4 to 10 are mandatory: context and scope, leadership, planning (risk assessment and treatment), support, operation, performance evaluation (internal audit, management review), and improvement.
• Annex A lists 93 controls in 4 themes: organizational (37, A.5), people (8, A.6), physical (14, A.7) and technological (34, A.8). (The 2013 edition had 114.) New in 2022 are controls such as A.5.23 (cloud services), A.8.9 (configuration management), A.8.12 (data leakage prevention), A.8.16 (monitoring) and A.8.28 (secure coding).

The clauses form a loop, usually drawn as Plan-Do-Check-Act:

  PLAN: scope, risk                    DO: run the controls,
  assessment, choose   ───────────▶    train people, keep
  controls (SoA)                       records
       ▲                                     │
       │ fix what                            │ measure
       │ failed                              ▼
  ACT: corrective      ◀───────────    CHECK: monitoring,
  actions, improve                     internal audit,
                                       management review

The Statement of Applicability (SoA) lists all 93 controls with, for each one, whether it applies, whether it's implemented, and why. Excluding a control is fine if you justify it.

Certification is done by an accredited certification body: a Stage 1 audit (documents) and a Stage 2 audit (does it actually run?). A certificate lasts three years, with surveillance audits each year. 2013-edition certificates expired by 31 October 2025, so one today is a red flag. ISO/IEC 27002:2022 is the companion guidance per control; you can't certify against it.

The trap is scope: "ISO 27001 certified" might cover one product. Read the certificate's scope, as you'd read a SOC 2 report's system description (L45).

4. CIS Controls v8.1: what to do first

A three-engineer subsidiary can't run an ISMS, but it can do the basics. The CIS Critical Security Controls, from the nonprofit Center for Internet Security, are a prioritized list of technical safeguards. v8 came out in May 2021; v8.1 (June 2024) aligned it with CSF 2.0. There are 18 controls containing 153 safeguards.

Each safeguard belongs to an Implementation Group (IG), and the groups are cumulative:

Controls an API or platform engineer touches: 2 (software inventory), 3 (data protection), 4 (secure configuration), 6 (access control), 7 (vulnerability management), 8 (audit logs) and 16 (application security). The separate CIS Benchmarks give exact settings per product, such as the CIS Amazon EKS Benchmark, which tools like kube-bench and AWS Security Hub check automatically.

5. How they compare, and two more names

Two more you'll hear. NIST SP 800-53 Rev. 5 is a catalog of more than 1,000 controls and enhancements in 20 families (AC access control, AU audit, CM configuration management, and so on), required for US federal systems and FedRAMP, and the deepest "how" behind the CSF (NIST issues minor releases, so check the current one). SOC 2 isn't a framework you implement but an auditor's attestation report against the AICPA's Trust Services Criteria; L45's deep dive covers reading one.

Companies keep a crosswalk: one internal control mapped to each framework's ID, so one piece of evidence answers five auditors.

🧪 Worked example: one ruleset, five framework IDs

Question 117 again: "How are production changes reviewed and approved?" Here is evidence from a made-up repo, granite-ridge/policy-api:

$ gh api repos/granite-ridge/policy-api/rulesets/4411 \
    --jq '.enforcement, .bypass_actors, (.rules[] |
          select(.type=="pull_request") | .parameters)'
"active"
[]
{
  "dismiss_stale_reviews_on_push": true,
  "require_code_owner_review": true,
  "require_last_push_approval": true,
  "required_approving_review_count": 1,
  "required_review_thread_resolution": true
}

Read it like an auditor: enforced, nobody can bypass it (bypass_actors is empty), and a push after approval needs a fresh approval (separation of duties, L04). Add a sample of merged PRs and deploy logs, and one artifact covers many frameworks:

Treat these IDs as a sketch; where an organization has a GRC team, its crosswalk is authoritative. Frameworks reward controls that are automatic and leave records, and engineers build those.

🛠 Try it (optional, ~5 min)

1. Open NIST's Cybersecurity and Privacy Reference Tool (csrc.nist.gov/projects/cprt) and find the CSF 2.0 Core. Read the implementation examples for PR.AA-05 and ID.RA-07. Which one does your last merged PR evidence?
2. On a repository you own, run gh api repos/<you>/<repo>/rulesets (or check branch protection in the settings page). Would it pass question 117? Look for an empty bypass list and require_last_push_approval.

🧠 Key takeaways

• CSF 2.0 says what outcomes to reach (six functions, Govern is new); ISO 27001 says how to run a program and is the one you can be certified against; CIS Controls say what to do first.
• ISO 27001:2022 has 93 Annex A controls in four themes; always check a certificate's scope.
• CIS IG1 is the floor for everyone; a regulated financial firm should expect IG2 or IG3.
• One control, crosswalked to many frameworks; your branch rules, pipeline gates and configs are framework controls, and automatic ones with records are the best evidence.

📖 Words to know

⏭ Next time

L68 moves from voluntary frameworks to the rules with penalties: GLBA, NYDFS Part 500, PCI DSS, SOX and the SEC's four-business-day disclosure clock.

Twice a year, someone asks your team for screenshots of encryption settings for 40 buckets. The screenshots are out of date the day after they're taken. Compliance as code turns each control into an automated check that runs all the time and stores its results as evidence.

Three places to check

  1. BEFORE MERGE         2. AT DEPLOY            3. WHILE RUNNING
  ┌────────────────┐     ┌────────────────┐      ┌────────────────┐
  │ CI: conftest,  │     │ k8s admission: │      │ AWS Config,    │
  │ Checkov on     │────▶│ Kyverno or     │─────▶│ Security Hub,  │
  │ Terraform and  │     │ Gatekeeper     │      │ kube-bench     │
  │ k8s YAML       │     │ (L27, L51)     │      │ (drift, manual │
  └────────────────┘     └────────────────┘      │ console edits) │
   blocks a bad PR        blocks a bad pod       └────────────────┘
                                                  finds what slipped

Each layer catches something the others miss. CI can't see a change someone made in the console; the runtime scan finds it, but only after it's live.

AWS Security Hub has built-in standards that score an account against, among others, the CIS AWS Foundations Benchmark and NIST SP 800-53 Rev. 5, and AWS Config conformance packs bundle rules per framework. The exact standards and versions offered change, so check the console list rather than memory.

Worked example: a policy that names its control

Tag every rule with the control it proves, so failures and passes map straight to the crosswalk. A conftest policy (Rego, as in L27) for Kubernetes manifests:

package main

# controls: CSF PR.PS-01 | ISO A.8.9 | CIS 4.1
deny contains msg if {
    input.kind == "Deployment"
    c := input.spec.template.spec.containers[_]
    not c.securityContext.runAsNonRoot
    msg := sprintf("[PR.PS-01] %s: runAsNonRoot not set",
                   [c.name])
}

Run in CI against a made-up manifest, it fails the build:

$ conftest test k8s/policy-api-deploy.yaml
FAIL - k8s/policy-api-deploy.yaml - main - [PR.PS-01]
  policy-api: runAsNonRoot not set

1 test, 0 passed, 0 warnings, 1 failure, 0 exceptions

Keep the CI results as build artifacts for the audit period. A year of green runs, plus the red ones and the PRs that fixed them, is far stronger evidence than a screenshot: it shows the control operating, not just existing.

Where it stops

Automation proves configuration. It can't prove that leadership reviewed risk, that people were trained, or that an exception was approved for a good reason. Those ISMS clauses (and CSF's Govern function) stay human. Also watch for checks that pass for the wrong reason: a rule that only looks at kind: Deployment silently ignores StatefulSets and CronJobs.

🧠 Extra takeaways

• Check in three places: before merge, at admission, and continuously at runtime.
• Put the control ID in the rule and its message so evidence maps itself.
• Stored check results over time prove a control operates; screenshots prove a moment.
• Automation covers technical controls, not governance; test that your checks cover every kind of resource.

"Are we doing CSF?" isn't a useful question, because CSF has no pass mark. The useful version is: "Where are we today, where do we need to be, and what's the gap?" That's a profile.

Current profile, target profile, gap

An organizational profile picks the subcategories that matter to you and records, for each, the current state and the target state. The gap between them becomes a prioritized plan. NIST publishes a profile template and quick-start guides, and sectors publish community profiles as a starting point (SP 800-61 Rev. 3 for incident response is one; L63).

Tiers are about rigor, not scores

The four tiers describe how an organization governs and manages cyber risk:

 Tier 1        Tier 2          Tier 3         Tier 4
 PARTIAL ────▶ RISK ─────────▶ REPEATABLE ──▶ ADAPTIVE
 ad hoc,       INFORMED        formal         learns and
 reactive      approved, but   policy, used   adapts from
               not org-wide    consistently   lessons and
                                              threat intel

NIST says tiers aren't meant as a maturity model, and not every organization needs Tier 4; many companies use them that way anyway, which is debated. Pick the tier your risk justifies.

Worked example: an API platform team's mini-profile

A made-up team runs Kong, six services on EKS and two MongoDB clusters:

Rank the gaps by risk (L02): the shared prod kubectl access and the missing logs probably come first, because one makes compromise easy and the other makes it invisible. Revisit the profile every quarter and record what moved. The subcategory IDs come from the CSF 2.0 Core; check the wording in NIST's reference tool before you quote them.

🧠 Extra takeaways

• A profile is current state + target state per subcategory; the gap is your roadmap.
• Tiers describe rigor of risk management (Partial, Risk Informed, Repeatable, Adaptive), not a score.
• Choose the target from your risk, not from "highest tier everywhere".
• Community profiles give a head start; NIST's IR guide is one.