Methodology

Overview

This guide claims to offer technical depth beyond a free CIS Benchmark PDF, a Microsoft Learn article, or an AWS Well-Architected whitepaper. The claim is only credible if a reader can audit the editorial process — how each control is chosen, where its severity comes from, which framework versions back its compliance mappings, and how the page is kept current. This methodology page is that audit trail. It exists because adding genuine value beyond authoritative source PDFs requires showing the work, not just paraphrasing the bullets.

The constitution below is enforced by build-time validation, not author goodwill. Severity tags must use the three-channel markup defined in docs/severity-rubric.md; compliance tables must carry the seven pinned-version column headers defined in docs/control-template.md and reproduced on the compliance frameworks page; citations must use citation-quality anchor text per STD-06; and every page carries a <time datetime="…"> last-reviewed stamp checked by the Phase 4 content gate.

Readers who disagree with a severity assignment, a compliance mapping, or a sourcing choice should read this page first, then file an issue against the specific criterion that the call violates. Disagreements are resolved by re-reading the criterion section, not by majority vote (see §Severity assignment).

Control selection criteria

A control is eligible to appear in this corpus only if it is sourced from at least one of four categories: (1) a pinned-version CIS Benchmark recommendation; (2) an official provider security best-practices document (AWS Well-Architected Security Pillar, Microsoft Cloud Security Benchmark, Google Cloud Architecture Framework Security pillar, OCI Security Best Practices); (3) a NIST Special Publication, most commonly SP 800-53 rev5 or one of its companion publications (SP 800-63B, SP 800-207, SP 800-57, SP 800-92, SP 800-190); or (4) a publicly documented, primary-source incident lesson (Capital One 2019 DOJ filing, Mandiant UNC5537 / Snowflake 2024 advisory, Microsoft Security Response Center Midnight Blizzard write-up, CISA / NSA cybersecurity information sheets).

Marketing statistics are rejected. Claims of the form "X% of organizations do Y" do not enter the corpus unless they originate from a primary research publication with disclosed methodology — Verizon DBIR, ENISA Threat Landscape, IBM Cost of a Data Breach Report, or equivalent. A vendor blog post that asserts "78% of breaches involve identity" without a citation is not a primary source even when the underlying claim is true. The cost of admitting weak sources is the cost of any reader spot-checking one of them and finding it unsupported — the entire corpus then loses authority.

A control is excluded if it is essentially provider marketing (for example, "enable Premium tier of feature X" without a security-outcome justification), if it duplicates an existing control without adding cross-provider coverage, or if it cannot be expressed as a configurable, observable state on a production tenant. "Have a security culture" is not a control. "Enforce MFA on all human identities via a Conditional Access policy that blocks legacy authentication" is a control. The bar is configurability and observability.

Severity assignment

Severity is applied from docs/severity-rubric.md, not from intuition, vendor severity ratings, or CVSS scores. The rubric defines four tiers:

• CRITICAL — Misconfiguration provides a direct, single-step path to data exfiltration, full account takeover, or unauthenticated remote code execution against a production-equivalent resource. No additional vulnerability, social engineering, or pivot is required.
• HIGH — Misconfiguration creates significant attack-surface expansion or a clear privilege-escalation path requiring one additional step (stolen credential, additional vulnerability, pre-positioned attacker) to convert into compromise.
• MEDIUM — Defense-in-depth control whose absence raises attacker cost or reduces detection fidelity but does not directly enable compromise.
• LOW — Configuration hygiene with minimal direct risk; absence affects observability completeness, compliance posture, or operational tidiness rather than the attacker's ability to compromise the environment.

When a candidate misconfiguration does not cleanly match exactly one tier, the author rounds up and records the ambiguity in the control's threat-model "Attack vector" sub-field. Round-down-on-ambiguity inflates the corpus toward MEDIUM and destroys triage value; round-up preserves the signal that CRITICAL controls warrant pager-grade response.

The worked example below illustrates the full control-box markup that every domain page entry mirrors. It exercises every CSS class touched by the DS-05 control-authoring contract: .control-box, .control-header, .control-id, .control-title, .sev, .sev-critical, .sev-icon, .sev-label, .control-type, .threat-model, .label, and .compliance-table. The walk-through after the markup traces why this control receives CRITICAL PREVENTIVE.

Walk-through against the rubric. The CRITICAL criterion says: "Misconfiguration provides a direct, single-step path to data exfiltration, full account takeover, or unauthenticated remote code execution. No additional vulnerability, social engineering, or pivot is required to realize the impact." Absent phishing-resistant MFA, a stolen password is sufficient to log in as the target identity and reach every resource that identity can access. The "single-step" criterion is met because the attacker has only to type the credential; no additional vulnerability is required. The control type is PREVENTIVE because the configuration stops the unsafe state (passwordless or password-only authentication) from existing — it is not a detective alert raised after compromise (DETECTIVE), nor an auto-remediation triggered post-detection (RESPONSIVE). The CRITICAL PREVENTIVE pairing follows directly; no author intuition is involved.

Control type labeling

Every severity tag is paired with a control type label rendered as <span class="control-type">. Three values are defined:

• PREVENTIVE — stops the unsafe state from existing (deny-by-default bucket policy, hardware MFA enforcement, KMS key policy without wildcard principals).
• DETECTIVE — surfaces the unsafe state after it exists (CloudTrail, GuardDuty findings, Defender for Cloud alerts, AWS Config non-compliant resource notification).
• RESPONSIVE — acts on the unsafe state once detected (EventBridge auto-remediation, Logic App disable-on-impossible-travel, SOAR playbook).

A CRITICAL DETECTIVE control is operationally distinct from a CRITICAL PREVENTIVE control even though both carry the same severity tag color and icon. "No audit log in any region" (CRITICAL DETECTIVE) delays discovery of compromise but does not enable it; "root account without MFA" (CRITICAL PREVENTIVE) directly enables compromise. Conflating the two — reading severity without control type — produces incorrect triage. Authors emit both spans adjacent in the control header per the markup in docs/control-template.md. Visual reference at reference/components.html.

Compliance mapping methodology

Every control entry carries a <table class="compliance-table"> whose header row pins seven framework columns: CIS AWS Foundations v3.0.0, CIS Microsoft Azure Foundations v3.0.0, CIS GCP Foundation v4.0.0, CIS OCI Foundation v2.0.0, NIST SP 800-53 rev5, ISO/IEC 27001:2022, and ISO/IEC 27017:2015. The full pinned-version contract — including release dates and the corpus-wide bump policy — lives on the compliance frameworks page §Pinned version contract and is not duplicated here. This methodology page documents only how each cell is verified.

A cell value is admissible only when traced to the framework primary source. For CIS rows, the cell carries the recommendation number from the published PDF benchmark at the pinned version, never from a third-party summary or an older benchmark version. For NIST SP 800-53 rev5 rows, the cell carries the control identifier from the NIST CSRC publication (for example IA-2(1), not "IA-2" without the enhancement number when the enhancement is what applies). For ISO/IEC 27001:2022 rows, the cell uses the three-level 2022 numbering (for example A.8.24), never the four-level 2013 numbering. For ISO/IEC 27017:2015 rows, the cell uses the CLD.x.y.z identifiers when the control is cloud-specific, or an em-dash when ISO/IEC 27017 inherits without adding cloud-specific guidance.

NIST SP 800-53 rev5 Appendix B is the authoritative NIST-to-ISO/IEC 27001 crosswalk and is the primary source consulted when mapping a NIST control to its ISO peer. Where the 2013→2022 ISO renumbering changes the destination control, the corresponding ISO/BSI 2022 transition document supplements Appendix B. Mappings are not invented; if a primary-source crosswalk does not assert the relationship, the cell carries an em-dash and the absence is recorded as a deliberate editorial choice.

Multiple legitimate framework targets are listed when more than one applies. A single CIS recommendation that satisfies both IA-2(1) and IA-2(2) lists both NIST identifiers; cherry-picking only the most flattering target is forbidden. The validation grep for STD-02 enforces the verbatim header strings; cell content correctness is a content review responsibility.

Citation standards

STD-06 requires that every <a> in this corpus use citation-quality anchor text. The format is: publisher, document title, accessed date. Example:

<a href="https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final">
  NIST SP 800-53 rev5 (upd1, Jan 2022) — Security and Privacy Controls (accessed 2026-05)
</a>

The following anchor texts are banned and fail the Phase 4 content gate when found in any page: click here, see this, more info, this link, bare here (case-insensitive), read more, and bare URLs (no surrounding citation text). The reasoning is two-fold. First, screen-reader users navigating by link list see only the anchor text out of context; "click here" is non-navigable. Second, anchor text is the most reliable signal that the author actually read the cited source — a citation written as "NIST SP 800-53 rev5 (upd1, Jan 2022) — IA-2 Identification and Authentication (accessed 2026-05)" demonstrates a different relationship to the source than "see this".

The accessed date is part of the citation, not an optional decoration. Cloud documentation changes weekly; provider URLs are renamed; ISO documents are revised. The accessed date tells a reader checking the citation in 2027 whether the link was current when the author cited it. Build enforcement of the accessed-date substring in <ul class="source-list"> anchors lives in the Phase 4 content gate; a broader build/check-citations.sh sweep across in-body anchors is planned for Phase 12.

Content currency and review cadence

Every page in this corpus carries a <time datetime="YYYY-MM-DD"> last-reviewed stamp rendered in the footer. The Phase 4 content gate fails any page missing the stamp. The stamp is updated whenever the page is materially edited or when a source document referenced by the page changes — whichever comes first.

The review cadence is twelve months as a floor. Every page is re-reviewed at least annually; reviewers re-check that pinned framework versions are still current, that provider documentation URLs still resolve, and that the recommendations have not been deprecated by a provider security advisory. Pages are reviewed sooner than the twelve-month floor when one of the following triggers occurs: a pinned CIS Benchmark publishes a new version; a provider deprecates a feature or service named on the page (for example IMDSv1 removal, classic Application Gateway end-of-life); a NIST publication is superseded; a referenced incident lesson receives an updated authoritative writeup.

Errata and corrections are tracked publicly via GitHub Issues against the repository at github.com/Artur12555/cloud_hardening. Every page footer carries a "Report an issue" link to https://github.com/Artur12555/cloud_hardening/issues/new, enforced by build/check-shell-required.sh (SHELL-06). Substantive corrections require a follow-up commit that bumps the last-reviewed stamp; typo fixes do not.

How to read a control entry

Every control on every domain page mirrors the markup of the example in §Severity assignment above. From top to bottom, a reader sees: the control identifier (lowercase, kebab-case, immutable once published — used as the anchor for deep-linking from the future compliance-matrix.html), the control title (an imperative noun phrase that names the configured outcome), the severity tag (CRITICAL / HIGH / MEDIUM / LOW with icon, label, and color per DS-07's three-channel guarantee), and the control type label (PREVENTIVE / DETECTIVE / RESPONSIVE).

Beneath the header, the threat-model aside carries three labeled sub-fields: MITIGATES (one-sentence threat statement), ATTACK VECTOR (the concrete kill-chain step that becomes possible absent this control), and BLAST RADIUS (scope of compromise if exploited). The threat-model box is the per-control bridge to the corpus-wide threat model on threat-model.html; readers tracing an attack chain from threat to mitigation enter via the threat-model and exit at the controls that close the chain.

The body of the control entry contains the CLI remediation (provider native command-line, executable as-is against a configured CLI), the IaC remediation (Terraform HCL with a mandatory provider version comment on the first line per STD-07), the compliance-table footer (seven pinned-version framework columns), and a per-control source list with citation-quality anchors. The canonical markup is documented in docs/control-template.md §Reference HTML markup; a rendered visual reference lives at reference/components.html.

How to contribute / report issues

Contributions and errata are filed against the repository at github.com/Artur12555/cloud_hardening. Issues for content corrections, broken links, severity-assignment disputes, and missing controls are welcome; please reference the specific control identifier or the page anchor in the issue title so a reviewer can locate the contested claim quickly. Pull requests are welcome for in-place corrections; substantive new content goes through a planning step first to maintain corpus consistency.

Security-sensitive disclosures (for example, a guide entry that inadvertently teaches an unsafe pattern) are handled via the security disclosure channel documented in the repository SECURITY.md; do not file them as public GitHub Issues.