{ "$schema": "https://beaconstandards.com/beacon-catalog.schema.json", "standard": "Beacon Standards", "version": "1.0", "license": "GPL-3.0", "publisher": "Penti.ai", "url": "https://beaconstandards.com", "generated": "2026-07-31", "identifierFormat": "BCN-T{tier}-{DOMAIN}-{nnn}", "identifierPolicy": "Identifiers are permanent. They are never reused and never renumbered; a finding may be reworded, re-mapped, or superseded, but the identifier continues to denote the same finding class.", "tiers": [ { "id": 1, "name": "Critical", "slug": "critical", "sla": "24–72 hours", "slaDays": 3, "escalation": "CISO and executive sponsor notified at 48 hours", "cvssRange": "7.0 – 10.0", "test": "Could an external attacker use this to gain access, escalate privilege, or take data — today, without an insider and without a chain of unlikely events?", "intent": "Stop active bleeding", "description": "Tier 1 covers conditions an attacker can act on now. The defining property is not severity score but reachability: the vulnerability is exposed to an untrusted network, exploitation is understood and tooled, and success grants meaningful access. These are the findings that show up in breach post-mortems.", "url": "https://beaconstandards.com/tiers/critical" }, { "id": 2, "name": "Regulatory", "slug": "regulatory", "sla": "30 days", "slaDays": 30, "escalation": "Security manager review at 14 days", "cvssRange": "4.0 – 6.9, or any score where a control is mandated", "test": "Would a named auditor, regulator, or contractual counterparty record this as a deficiency?", "intent": "Maintain the licence to operate", "description": "Tier 2 covers conditions that threaten certification, contract, or regulatory standing. The consequence is not a breach but a finding in someone else's report: a qualified SOC 2 opinion, a failed PCI DSS assessment, a GDPR Article 32 exposure. These are deadline-driven rather than threat-driven, and the deadline belongs to the auditor.", "url": "https://beaconstandards.com/tiers/regulatory" }, { "id": 3, "name": "Best Practices", "slug": "best-practices", "sla": "90 days", "slaDays": 90, "escalation": "Reviewed at quarterly planning; may be formally deferred", "cvssRange": "0.1 – 3.9", "test": "Does fixing this reduce the number or severity of future Tier 1 and Tier 2 findings?", "intent": "Reduce the rate at which the first two tiers refill", "description": "Tier 3 covers structural improvements with compounding returns. Nothing here is urgent in isolation, which is exactly why it never gets done without a tier of its own. Tier 3 is the only tier where deferral is a legitimate, recorded outcome — an organisation that closes every Tier 3 item is probably under-investing elsewhere.", "url": "https://beaconstandards.com/tiers/best-practices" } ], "domains": [ { "id": "network", "code": "NET", "name": "Network", "question": "What can be reached, and from where?", "description": "The Network domain covers reachability: which services are exposed, to which networks, and what sits between an untrusted packet and a sensitive system. Most Tier 1 findings are network findings in disguise — a vulnerable service that nothing can route to is a very different problem from the same service on a public IP.", "scope": [ "Internet and partner-network service exposure", "Firewall, security group, and network ACL configuration", "Segmentation between trust zones and regulated environments", "Ingress and egress filtering", "Network telemetry, flow logging, and intrusion detection coverage" ], "typicalOwner": "Network engineering / cloud platform", "url": "https://beaconstandards.com/domains/network" }, { "id": "iam", "code": "IAM", "name": "Identity & Access Management", "question": "Who can act, and how strongly is that proven?", "description": "The Identity domain covers authentication strength, authorisation scope, and credential lifecycle. Identity is the modern perimeter: in cloud-first estates the majority of privilege-escalation paths are IAM misconfigurations rather than software vulnerabilities, and they carry no CVE to alert on.", "scope": [ "Multi-factor authentication coverage and enforcement", "Privilege assignment, standing access, and least-privilege posture", "Credential and key lifecycle, rotation, and revocation", "Service account and workload identity governance", "Access review, joiner-mover-leaver, and federation" ], "typicalOwner": "Identity engineering / IT operations", "url": "https://beaconstandards.com/domains/iam" }, { "id": "data", "code": "DAT", "name": "Data Protection", "question": "What happens to the data if everything else fails?", "description": "The Data domain covers the controls that determine blast radius. Every other domain is about preventing access; this one is about limiting what access is worth. Encryption, classification, retention, and injection defence decide whether a compromise is an incident or a notifiable breach.", "scope": [ "Encryption at rest and in transit, and key management", "Injection defence in data-access paths", "Data classification and inventory", "Retention, deletion, and data-subject rights", "Backup integrity, isolation, and restoration testing" ], "typicalOwner": "Data platform / application engineering", "url": "https://beaconstandards.com/domains/data" }, { "id": "processing", "code": "PRC", "name": "Processing Protection", "question": "Is the compute that runs the business trustworthy and available?", "description": "The Processing domain covers the integrity and availability of compute: patch currency, workload and container hardening, build-pipeline trust, and resilience against disruption. It is where software supply chain and known-exploited vulnerabilities land.", "scope": [ "Patch currency, especially known-exploited vulnerabilities", "Management, orchestration, and administrative interface exposure", "Container, image, and workload hardening", "Build pipeline and infrastructure-as-code integrity", "Availability protection and rate limiting" ], "typicalOwner": "Platform engineering / SRE", "url": "https://beaconstandards.com/domains/processing" } ], "findings": [ { "id": "BCN-T1-NET-001", "name": "Internet-Exposed Remote Administration Services", "tier": 1, "domain": "network", "summary": "SSH, RDP, SMB, or equivalent management protocols reachable from the public internet.", "sla": "24 hours", "definition": "A remote administration protocol — most commonly SSH (22), RDP (3389), SMB (445), VNC (5900), or Telnet (23) — accepts connections from arbitrary internet addresses. The service may be fully patched and correctly configured; the finding is about reachability, not about a software defect. Exposure of an authentication surface to the entire internet is itself the condition being flagged.", "whyThisTier": "Internet-facing administration ports are continuously enumerated by commodity scanning infrastructure, and a newly exposed RDP host typically receives credential-stuffing traffic within hours. These services are the single most common initial-access vector in ransomware intrusions, and the path from successful authentication to full administrative control is direct. Tier 1 applies regardless of patch level, because the exposure grants an attacker unlimited offline-speed attempts against your authentication.", "commonMisclassification": "Teams frequently downgrade this to Tier 3 when the service is patched and uses key-based authentication. Patch state does not change the tier: the finding is the exposure of an authentication surface, and it stays Tier 1 until reachability is removed.", "detection": [ "Run an external port scan from outside your own network — cloud-internal scanning misses exposure created by public load balancers and NAT rules.", "Query internet-wide scan data (Shodan, Censys) for your registered netblocks and cloud-assigned addresses to see what attackers already see.", "Audit cloud security groups and network ACLs for ingress rules with a 0.0.0.0/0 or ::/0 source on administrative ports.", "Review edge firewall and port-forward rules for legacy entries created for time-limited access and never withdrawn." ], "remediation": [ "Remove the ingress rule. This is almost always the correct fix and it is available immediately — do not begin with hardening the exposed service.", "Place administrative access behind an identity-aware proxy, a bastion with session recording, or a zero-trust access broker.", "Where a VPN is the chosen control, enforce phishing-resistant MFA on it — a VPN with password-only authentication reproduces the original problem one hop back.", "Restrict any residual exposure to an explicit source allowlist of known egress addresses, and set a documented expiry on each entry.", "Review authentication logs for the full exposure window before closing the finding — treat successful logins from unrecognised sources as a suspected incident." ], "verification": "An external scan of the address returns filtered or closed on the affected port, and the ingress rule is absent from the infrastructure-as-code definition rather than only from the live console.", "mitre": [ { "id": "T1190", "name": "Exploit Public-Facing Application" }, { "id": "T1133", "name": "External Remote Services" }, { "id": "T1110", "name": "Brute Force" } ], "cwe": [ { "id": "CWE-284", "name": "Improper Access Control" } ], "owasp": [], "compliance": [ { "framework": "PCI DSS v4.0", "control": "1.4.2 — restrict inbound traffic to trusted networks" }, { "framework": "ISO/IEC 27001:2022", "control": "A.8.20 — network security" }, { "framework": "NIST CSF 2.0", "control": "PR.AA-05 / PR.IR-01" }, { "framework": "SOC 2", "control": "CC6.6 — boundary protection" } ], "scanners": [ "Nmap", "Nessus", "Shodan", "Nuclei", "PROWLER" ], "url": "https://beaconstandards.com/catalog/internet-exposed-remote-administration" }, { "id": "BCN-T1-NET-002", "name": "Publicly Accessible Storage and Data Services", "tier": 1, "domain": "network", "summary": "Object storage, file shares, or managed data services readable without authentication from the internet.", "sla": "24 hours", "definition": "A storage resource — S3 bucket, Azure blob container, GCS bucket, network file share, or managed backup target — permits anonymous or unauthenticated read (and sometimes write) access from the public internet. This includes resources made public by an explicit ACL, by an over-broad bucket policy, or by a permissive default inherited at creation.", "whyThisTier": "There is no exploitation step. An attacker who locates the resource simply reads it, which means time-to-compromise is bounded only by time-to-discovery, and discovery is automated and continuous. Public-storage exposure requires no skill, leaves minimal trace in most default logging configurations, and has produced some of the largest recorded data exposures. Where write access is also permitted, the resource becomes a malware distribution point trading on your domain's reputation.", "commonMisclassification": "Buckets holding 'non-sensitive' assets are often deferred to Tier 3. Classify by what the bucket *can* hold under its current permissions and by what write access would enable, not by an inventory of what happens to be in it today.", "detection": [ "Enumerate all storage resources across every account, subscription, and project — shadow accounts are the usual source of exposure.", "Run cloud posture checks (PROWLER, Cloudsploit, ScoutSuite) for public-access findings rather than inspecting resources by hand.", "Test anonymously from outside your identity plane: an unauthenticated curl is the only reliable evidence, since a signed-in session masks the finding.", "Check for public access granted indirectly through presigned URLs with long expiry windows, or through a CDN distribution fronting a private origin." ], "remediation": [ "Revoke public access on the specific resource first, then confirm no legitimate consumer breaks — reverse this order and the finding stays open through a change-approval cycle.", "Enable account-level public access blocks (S3 Block Public Access, Azure storage-account network restrictions) so the misconfiguration cannot recur.", "Serve genuinely public content through a CDN with an origin access identity, keeping the underlying bucket private.", "Review access logs for the exposure window and, where regulated data was reachable, initiate the breach-assessment process rather than closing the finding silently.", "Add a preventive guardrail — a service control policy or Azure Policy denying public ACLs — so the next occurrence is blocked at creation." ], "verification": "An unauthenticated request from an unrelated network returns 403 or 404, and an account-level public-access block is enforced so that a future per-resource misconfiguration cannot take effect.", "mitre": [ { "id": "T1530", "name": "Data from Cloud Storage" }, { "id": "T1619", "name": "Cloud Storage Object Discovery" } ], "cwe": [ { "id": "CWE-1188", "name": "Insecure Default Initialization of Resource" } ], "owasp": [], "compliance": [ { "framework": "GDPR", "control": "Art. 32 — security of processing" }, { "framework": "PCI DSS v4.0", "control": "1.4.4 — no direct public access to CDE data" }, { "framework": "HIPAA", "control": "§164.312(a)(1) — access control" }, { "framework": "SOC 2", "control": "CC6.1 — logical access" } ], "scanners": [ "PROWLER", "Cloudsploit", "ScoutSuite", "Nuclei" ], "url": "https://beaconstandards.com/catalog/publicly-accessible-data-stores" }, { "id": "BCN-T1-NET-003", "name": "No Segmentation Between Trust Zones", "tier": 1, "domain": "network", "summary": "A compromise of any low-value host grants unrestricted network reachability to critical systems.", "sla": "72 hours", "definition": "Systems of materially different sensitivity share a routable broadcast domain or an unrestricted routing path, with no filtering enforced between them. A workstation VLAN can reach the database subnet; a development account peers unrestricted into production; a guest network resolves and routes to internal services. The condition is the absence of an enforcement point, not the presence of a specific rule.", "whyThisTier": "Segmentation determines whether a single compromised endpoint is an incident or an outage. Ransomware operators depend almost entirely on lateral movement — the initial foothold is rarely a system worth encrypting — and a flat network converts one phished user into estate-wide access within hours. Beacon assigns 72 hours rather than 24 because meaningful segmentation cannot be safely deployed in a day; the extended window is for staged rollout, not for reduced priority.", "commonMisclassification": "Frequently filed as Tier 2, because segmentation appears in PCI DSS and auditors ask about it. If the gap exposes crown-jewel systems to a routine endpoint compromise it is Tier 1; Tier 2 covers scope-reduction segmentation around a regulated environment that is already protected by other controls (see BCN-T2-NET-001).", "detection": [ "Run authenticated reachability testing from a representative low-trust host to known critical services, rather than reading the intended firewall policy.", "Analyse cloud flow logs for accepted traffic between subnets that policy says should not communicate.", "Audit VPC peering, transit gateway routes, and VPN tunnels for transitive paths that bypass the intended inspection point.", "Check whether security group rules reference broad CIDR blocks instead of peer security group identifiers — a common source of unintended reachability." ], "remediation": [ "Identify and rank the crown-jewel systems first; segment inbound to those before attempting an estate-wide programme, which will not complete.", "Deploy default-deny between zones with an explicit, documented allowlist for each required flow.", "In cloud environments, reference security groups rather than CIDR ranges so that policy follows workloads through scaling events.", "Isolate management and out-of-band interfaces onto a dedicated administrative network reachable only through a bastion.", "Instrument the enforcement points with flow logging before tightening rules, so that break-fix is measured rather than guessed." ], "verification": "Reachability testing from a low-trust segment to each crown-jewel service is denied at the enforcement point, and the denial appears in flow logs — proving the control is active rather than the test being misrouted.", "mitre": [ { "id": "T1021", "name": "Remote Services" }, { "id": "T1210", "name": "Exploitation of Remote Services" }, { "id": "T1570", "name": "Lateral Tool Transfer" } ], "cwe": [], "owasp": [], "compliance": [ { "framework": "PCI DSS v4.0", "control": "1.2.1 — network security controls between zones" }, { "framework": "NIST CSF 2.0", "control": "PR.IR-01 — networks are protected" }, { "framework": "ISO/IEC 27001:2022", "control": "A.8.22 — segregation of networks" } ], "scanners": [ "Nmap", "Nessus", "PROWLER", "ScoutSuite" ], "url": "https://beaconstandards.com/catalog/missing-segmentation-between-trust-zones" }, { "id": "BCN-T1-IAM-001", "name": "Missing MFA on Privileged Accounts", "tier": 1, "domain": "iam", "summary": "Administrative, root, or break-glass accounts authenticate with a single factor.", "sla": "24 hours", "definition": "An account holding administrative privilege — cloud root or global administrator, domain admin, privileged SaaS role, or an equivalent — can complete authentication with a password alone. This includes accounts where MFA is available but not enforced, where enforcement is bypassable through a legacy protocol, and where the second factor is SMS in an environment facing targeted attackers.", "whyThisTier": "Credentials for privileged accounts are available in bulk from infostealer logs and prior breaches, and password reuse remains widespread. A single factor means one leaked or phished credential is sufficient for full administrative control, with no further exploitation required. This is the most consequential single control in most estates, and the remediation is usually a configuration change that can be completed the same day.", "commonMisclassification": "Service accounts and workload identities are often reported under this finding. They cannot present an interactive second factor and belong under BCN-T1-IAM-003 (credential lifecycle) or BCN-T2-IAM-003 (governance) instead.", "detection": [ "Enumerate every account with privileged role assignment across all identity providers — including local accounts on network appliances, which are routinely missed.", "Report on MFA registration state rather than MFA policy state; a policy that exempts unregistered users enforces nothing.", "Check for legacy authentication protocols (IMAP, POP3, SMTP AUTH, legacy Exchange) that bypass conditional access entirely.", "Identify break-glass accounts and confirm they are covered by a compensating control — typically a split, sealed credential with alerting on use." ], "remediation": [ "Enforce phishing-resistant MFA — FIDO2/WebAuthn or platform passkeys — on privileged accounts first; TOTP is an acceptable interim step, SMS is not.", "Block legacy authentication protocols at the identity provider, since they defeat conditional access regardless of configuration.", "Configure break-glass accounts with hardware tokens held under dual control, excluded from conditional access by design, and alerting on every authentication.", "Extend enforcement to the whole population once privileged accounts are covered — the tier assignment falls to Tier 2 for non-privileged users.", "Audit sign-in logs across the exposure window for successful single-factor privileged authentication from unfamiliar addresses." ], "verification": "A privileged sign-in attempt with a correct password alone is refused, and the refusal is visible in the identity provider's sign-in log with the expected conditional-access policy named.", "mitre": [ { "id": "T1078", "name": "Valid Accounts" }, { "id": "T1110", "name": "Brute Force" }, { "id": "T1621", "name": "Multi-Factor Authentication Request Generation" } ], "cwe": [ { "id": "CWE-308", "name": "Use of Single-factor Authentication" } ], "owasp": [], "compliance": [ { "framework": "PCI DSS v4.0", "control": "8.4.2 / 8.5.1 — MFA for all access into the CDE" }, { "framework": "NIST CSF 2.0", "control": "PR.AA-03 — users are authenticated" }, { "framework": "SOC 2", "control": "CC6.1 — logical access controls" }, { "framework": "HIPAA", "control": "§164.312(d) — person or entity authentication" } ], "scanners": [ "PROWLER", "ScoutSuite", "Nessus", "Entra ID access reviews" ], "url": "https://beaconstandards.com/catalog/missing-mfa-privileged-accounts" }, { "id": "BCN-T1-IAM-002", "name": "Excessive Standing Privilege", "tier": 1, "domain": "iam", "summary": "Accounts hold permanent administrative rights far beyond what their role requires.", "sla": "48 hours", "definition": "Identities carry broad, always-active privilege that is not required for their routine work — wildcard IAM policies, permanent membership of highly-privileged directory groups, or developer accounts with unrestricted production access. The distinguishing feature is that the privilege is *standing*: available at every moment rather than granted on request for a bounded window.", "whyThisTier": "Standing privilege sets the blast radius of every other compromise. Phishing a developer who holds permanent production administrator rights is equivalent to phishing an administrator, and the attacker inherits the full permission set instantly. Because this finding multiplies the impact of every credential-theft technique, it is treated as Tier 1 even though it is a configuration state rather than an exploitable defect.", "commonMisclassification": "Often deferred to Tier 3 as 'least-privilege cleanup'. Broad standing privilege on production is Tier 1; Tier 3 covers refining already-scoped roles into finer-grained ones (see BCN-T3-IAM-001).", "detection": [ "Compare granted permissions against permissions actually exercised — cloud providers expose this directly (AWS IAM Access Analyzer, Azure Entra Permissions Management, GCP Recommender).", "Search IAM policy documents for wildcard actions and wildcard resources, and for AdministratorAccess or Owner attached to human identities.", "Enumerate membership of Domain Admins, Enterprise Admins, Global Administrators, and equivalent, and confirm each member against a named business justification.", "Identify privilege inherited through nested group membership, which routinely grants access no one intended and no one reviews." ], "remediation": [ "Right-size the highest-privilege identities first, using observed usage as the baseline for the replacement policy.", "Replace standing administrative access with just-in-time elevation — time-bounded, approved, and logged.", "Separate duties so that the identity which approves an elevation cannot also request it.", "Attach permission boundaries or service control policies so that even a compromised administrative role cannot exceed an outer limit.", "Establish a recurring review, and treat any role that has gone unused for a defined period as a candidate for automatic removal." ], "verification": "No human identity holds a wildcard administrative policy as a standing grant; elevation requires an approval that is recorded, and the resulting session expires without manual intervention.", "mitre": [ { "id": "T1078.004", "name": "Valid Accounts: Cloud Accounts" }, { "id": "T1098", "name": "Account Manipulation" } ], "cwe": [ { "id": "CWE-269", "name": "Improper Privilege Management" } ], "owasp": [], "compliance": [ { "framework": "PCI DSS v4.0", "control": "7.2.1 — access assigned by least privilege" }, { "framework": "ISO/IEC 27001:2022", "control": "A.8.2 — privileged access rights" }, { "framework": "SOC 2", "control": "CC6.3 — role-based access" } ], "scanners": [ "PROWLER", "Cloudsploit", "ScoutSuite", "BloodHound" ], "url": "https://beaconstandards.com/catalog/excessive-standing-privilege" }, { "id": "BCN-T1-IAM-003", "name": "Long-Lived Privileged Credentials", "tier": 1, "domain": "iam", "summary": "Privileged API keys, access keys, or service credentials that never expire and are not rotated.", "sla": "72 hours", "definition": "Static secrets carrying privileged access — cloud access key pairs, personal access tokens, API keys, service account passwords — exist without an expiry and without a rotation record. The finding covers both the absence of rotation and the wider problem of secrets distributed to locations from which they cannot be recalled: source repositories, CI configuration, container images, and developer workstations.", "whyThisTier": "A static privileged credential is a permanent skeleton key whose exposure history cannot be reconstructed. Once copied into a repository or a build log it may be replicated indefinitely, and credential-scanning bots harvest public commits within seconds of a push. Because there is no expiry, a credential leaked years ago remains valid today, so the exposure window is unbounded until rotation occurs.", "commonMisclassification": "Rotation gaps on non-privileged credentials are frequently filed here. Those are Tier 2 under BCN-T2-IAM-003. This finding is specifically about credentials that carry privileged access.", "detection": [ "Report cloud access keys by age and by last-used date; keys that are old and unused are the highest-value targets for removal.", "Run secret scanning across the full history of every repository, not only the current tree — deleted secrets remain in git objects.", "Scan container image layers and CI job logs, both of which persist secrets that were removed from source.", "Correlate each active credential to a named owner and purpose; unattributable credentials should be treated as compromised." ], "remediation": [ "Rotate the credential before investigating its provenance — the investigation is valuable but the rotation is what closes the exposure.", "Replace static keys with short-lived, federated credentials wherever the platform supports it (OIDC federation for CI, instance or workload identity for compute).", "Move any remaining static secrets into a managed secret store with automatic rotation, and grant retrieval by workload identity rather than by embedded credential.", "Where a secret reached a public repository, treat it as compromised regardless of how briefly it was visible, and review usage logs for the whole window.", "Add pre-commit and pre-receive secret scanning so the next occurrence is blocked before it becomes permanent." ], "verification": "No privileged static credential exceeds the defined maximum age, secret scanning across full repository history returns no active credentials, and CI authenticates through federation rather than a stored key.", "mitre": [ { "id": "T1552", "name": "Unsecured Credentials" }, { "id": "T1552.001", "name": "Credentials In Files" }, { "id": "T1078.004", "name": "Valid Accounts: Cloud Accounts" } ], "cwe": [ { "id": "CWE-798", "name": "Use of Hard-coded Credentials" } ], "owasp": [], "compliance": [ { "framework": "PCI DSS v4.0", "control": "8.3.9 / 8.6.3 — credential management" }, { "framework": "NIST CSF 2.0", "control": "PR.AA-01 — identities and credentials are managed" }, { "framework": "ISO/IEC 27001:2022", "control": "A.5.17 — authentication information" } ], "scanners": [ "TruffleHog", "Gitleaks", "PROWLER", "Cloudsploit" ], "url": "https://beaconstandards.com/catalog/long-lived-privileged-credentials" }, { "id": "BCN-T1-DAT-001", "name": "Injection Flaws on Internet-Facing Applications", "tier": 1, "domain": "data", "summary": "SQL, NoSQL, OS command, or template injection reachable from an unauthenticated request.", "sla": "24 hours", "definition": "User-controlled input reaches an interpreter without adequate separation between code and data, on a code path reachable from the public internet. Beacon treats SQL injection, NoSQL injection, OS command injection, LDAP injection, and server-side template injection as one finding class because the exploitation economics and the remediation pattern are effectively identical.", "whyThisTier": "Injection converts a request into arbitrary interpreter execution. In the database case that is usually direct bulk exfiltration; in the command and template cases it is remote code execution, which is initial access rather than mere data loss. Detection and exploitation are both fully automated by widely-distributed tooling, so the window between a vulnerability becoming reachable and it being exploited is short and shrinking.", "commonMisclassification": "Injection on an internal-only application is often filed here at Tier 1. Reachability is the deciding factor — an internal-only injection flaw is Tier 2 unless the application is reachable from a routinely-compromised segment.", "detection": [ "Run authenticated and unauthenticated dynamic scanning against every internet-facing application, covering API endpoints as well as rendered forms.", "Apply static analysis to identify string-concatenated queries and unsanitised interpreter calls, then confirm reachability before triaging.", "Review ORM escape hatches — raw-query interfaces are where parameterisation is most often abandoned under deadline pressure.", "Test paths that are frequently overlooked: search, export, sort and filter parameters, file-name handling, and webhook receivers." ], "remediation": [ "Deploy a WAF rule as an immediate containment measure, and record it as containment rather than remediation — it buys hours, not closure.", "Replace dynamic query construction with parameterised statements or prepared queries; this is the fix, and no amount of input filtering substitutes for it.", "For OS command paths, invoke the target binary directly with an argument array rather than passing a constructed string to a shell.", "Apply allowlist validation on structural elements that cannot be parameterised, such as table and column names in dynamic sorting.", "Reduce the database account's privilege so that a future injection yields a narrower result, and review query logs for exploitation predating the fix." ], "verification": "The original proof-of-concept payload no longer alters interpreter behaviour, code review confirms parameterisation at the call site, and a regression test carrying the payload runs in CI.", "mitre": [ { "id": "T1190", "name": "Exploit Public-Facing Application" }, { "id": "T1059", "name": "Command and Scripting Interpreter" } ], "cwe": [ { "id": "CWE-89", "name": "SQL Injection" }, { "id": "CWE-78", "name": "OS Command Injection" } ], "owasp": [ "A03:2021 — Injection" ], "compliance": [ { "framework": "PCI DSS v4.0", "control": "6.2.4 — software defences against injection" }, { "framework": "GDPR", "control": "Art. 32 — security of processing" }, { "framework": "SOC 2", "control": "CC7.1 — vulnerability identification" } ], "scanners": [ "Burp Suite", "OWASP ZAP", "sqlmap", "Nuclei", "Semgrep" ], "url": "https://beaconstandards.com/catalog/injection-internet-facing" }, { "id": "BCN-T1-DAT-002", "name": "Unauthenticated Database Endpoints", "tier": 1, "domain": "data", "summary": "MongoDB, Redis, Elasticsearch, or similar services accepting internet connections with no authentication.", "sla": "24 hours", "definition": "A database or cache service is bound to a publicly-routable interface and either requires no authentication or accepts well-known default credentials. This affects data services whose historical defaults favoured convenience — MongoDB, Redis, Elasticsearch, Memcached, CouchDB, and Cassandra among them — particularly when deployed directly from a container image without configuration review.", "whyThisTier": "This is the shortest path to total data loss in existence: connect and read. Automated campaigns have repeatedly swept the entire IPv4 space for these services, exfiltrating and then wiping databases in favour of a ransom note, and a newly-exposed instance is typically found within hours. Write access additionally permits data destruction and, in several of these engines, a path to code execution on the host.", "commonMisclassification": "Non-production instances are routinely downgraded. Development databases are commonly seeded with copies of production data and share credentials with production systems — classify by the data present and the credentials accepted, not by the environment label.", "detection": [ "Scan your external address space for the standard data-service ports (27017, 6379, 9200, 11211, 5984, 9042) and attempt an unauthenticated connection.", "Audit container and orchestration manifests for port publishing that binds a data service to the host's public interface.", "Check managed database instances for public accessibility flags, which are enabled by default in several provider consoles.", "Confirm whether authentication is enabled at all — several of these engines historically shipped with it disabled and preserve that default on upgrade." ], "remediation": [ "Remove public reachability first — bind to a private interface or withdraw the security group rule — because this closes the exposure in minutes.", "Enable authentication and create per-application accounts with scoped privileges; delete or disable any default account.", "Require TLS for client connections so that credentials are not recoverable from network capture.", "Assume compromise if the service was exposed without authentication: inspect for unexpected collections, ransom artefacts, and modified data, and follow the incident process.", "Add a preventive policy check in CI that rejects manifests publishing data-service ports on a public interface." ], "verification": "An unauthenticated connection attempt from an external host fails to establish, authentication is confirmed enabled in the running configuration rather than only in the intended config file, and the listener is bound to a private address.", "mitre": [ { "id": "T1530", "name": "Data from Cloud Storage" }, { "id": "T1213", "name": "Data from Information Repositories" }, { "id": "T1485", "name": "Data Destruction" } ], "cwe": [ { "id": "CWE-306", "name": "Missing Authentication for Critical Function" } ], "owasp": [], "compliance": [ { "framework": "PCI DSS v4.0", "control": "8.2 — user identification for all access" }, { "framework": "HIPAA", "control": "§164.312(a)(1) — access control" }, { "framework": "GDPR", "control": "Art. 32 — security of processing" } ], "scanners": [ "Nmap", "Shodan", "Nuclei", "Nessus" ], "url": "https://beaconstandards.com/catalog/unauthenticated-database-endpoints" }, { "id": "BCN-T1-DAT-003", "name": "Unencrypted Sensitive Data at Rest", "tier": 1, "domain": "data", "summary": "Regulated or business-critical data stored without encryption on systems exposed to compromise.", "sla": "48 hours", "definition": "Databases, volumes, snapshots, or backups holding regulated or business-critical data are stored without encryption at rest. Beacon reserves Tier 1 for the case where the unencrypted store sits on a system with a realistic compromise path — an internet-facing host, a shared platform, or a backup replicated to third-party infrastructure.", "whyThisTier": "Encryption at rest is the control that determines whether a compromise is an incident or a notifiable breach. Snapshots and backups are copied far more widely than their source systems and routinely outlive the security controls that protected the original, which means an unencrypted snapshot exposes data long after the primary system is decommissioned. Most breach-notification regimes offer a safe harbour for properly encrypted data, so this control has direct financial consequence.", "commonMisclassification": "This is the finding most often misplaced between tiers. Tier 1 requires a realistic compromise path to the unencrypted store; where data is encrypted but the algorithm or key management does not meet the regulatory standard, the correct classification is BCN-T2-DAT-001.", "detection": [ "Inventory every storage volume, database instance, and snapshot, and report encryption state — snapshots are the most commonly missed category.", "Verify that encryption is enabled with a customer-managed or provider-managed key as policy requires, rather than merely that a flag is set.", "Check backup destinations and any replication targets separately; encryption at source does not imply encryption at the replica.", "Trace where regulated data is exported — reporting extracts, data-warehouse loads, and analytics copies frequently land in unencrypted stores." ], "remediation": [ "Enable encryption on the highest-sensitivity store first; for engines that cannot encrypt in place, plan an encrypted replica and cut over.", "Re-encrypt existing snapshots by copying them into encrypted equivalents, then delete the unencrypted originals — creating the new copy alone does not close the finding.", "Move key material into a managed KMS with access policies separate from the data plane, so that database compromise does not yield keys.", "Enable encryption-by-default at account level so new resources inherit it without relying on the creator.", "Record the encryption state and key custodian in the data inventory, since regulators ask for evidence rather than assertion." ], "verification": "Every store and snapshot holding regulated data reports encryption enabled with the correct key, unencrypted originals are confirmed deleted, and account-level default encryption is active.", "mitre": [ { "id": "T1530", "name": "Data from Cloud Storage" }, { "id": "T1005", "name": "Data from Local System" } ], "cwe": [ { "id": "CWE-311", "name": "Missing Encryption of Sensitive Data" } ], "owasp": [], "compliance": [ { "framework": "PCI DSS v4.0", "control": "3.5.1 — PAN rendered unreadable" }, { "framework": "HIPAA", "control": "§164.312(a)(2)(iv) — encryption and decryption" }, { "framework": "GDPR", "control": "Art. 32(1)(a) — encryption of personal data" }, { "framework": "ISO/IEC 27001:2022", "control": "A.8.24 — use of cryptography" } ], "scanners": [ "PROWLER", "Cloudsploit", "ScoutSuite", "Nessus" ], "url": "https://beaconstandards.com/catalog/unencrypted-sensitive-data-at-rest" }, { "id": "BCN-T1-PRC-001", "name": "Known-Exploited Vulnerabilities", "tier": 1, "domain": "processing", "summary": "Unpatched CVEs with confirmed exploitation in the wild, on systems an attacker can reach.", "sla": "24 hours", "definition": "A system carries a vulnerability that is confirmed to be exploited in the wild — the authoritative reference being the CISA Known Exploited Vulnerabilities catalog — and the vulnerable component is reachable by an attacker. Beacon deliberately keys this finding to observed exploitation rather than to CVSS score, because the two correlate weakly.", "whyThisTier": "Confirmed exploitation removes all the uncertainty that normally governs patch prioritisation: working exploit code exists, someone is using it, and targets are being selected by scanning rather than by choice. The KEV catalog is a small fraction of published CVEs but accounts for a hugely disproportionate share of successful intrusions, which makes it the single highest-yield patching signal available and the reason Beacon separates it from routine vulnerability management.", "commonMisclassification": "High-CVSS vulnerabilities with no evidence of exploitation are often escalated into this finding. A CVSS 9.8 with no known exploitation and no reachability is Tier 2; a CVSS 6.5 in the KEV catalog on an internet-facing host is Tier 1. Exploitation evidence outranks score.", "detection": [ "Cross-reference your vulnerability inventory against the CISA KEV catalog on every scan cycle, and treat matches as a distinct queue rather than as high-severity items in the main backlog.", "Incorporate EPSS scores to prioritise among CVEs not yet listed in KEV but with high modelled exploitation probability.", "Confirm reachability before assigning the tier — an unreachable KEV entry is Tier 2, and treating every KEV match as Tier 1 will exhaust the queue's credibility.", "Extend coverage to appliances, hypervisors, and network equipment, which are heavily represented in KEV and thinly covered by host-based agents." ], "remediation": [ "Patch. Where a maintenance window is the obstacle, escalate rather than defer — the KEV designation is the justification for the emergency change.", "Where patching is genuinely blocked, apply the vendor mitigation and record it with an explicit review date rather than closing the finding.", "Remove reachability as a compensating control — withdrawing internet exposure converts an emergency into scheduled work.", "Hunt for prior exploitation using the indicators published with the CVE, since KEV entries frequently predate detection in your estate.", "Feed each occurrence back into patch-cadence planning; a recurring KEV backlog is a process finding, not a series of unrelated incidents." ], "verification": "The affected component reports a fixed version, an authenticated re-scan no longer detects the CVE, and — where a mitigation was applied instead — the compensating control is tested and carries a dated review.", "mitre": [ { "id": "T1190", "name": "Exploit Public-Facing Application" }, { "id": "T1203", "name": "Exploitation for Client Execution" }, { "id": "T1068", "name": "Exploitation for Privilege Escalation" } ], "cwe": [ { "id": "CWE-1035", "name": "Using Components with Known Vulnerabilities" } ], "owasp": [ "A06:2021 — Vulnerable and Outdated Components" ], "compliance": [ { "framework": "PCI DSS v4.0", "control": "6.3.3 — critical patches within one month" }, { "framework": "NIST CSF 2.0", "control": "ID.RA-01 — vulnerabilities are identified" }, { "framework": "SOC 2", "control": "CC7.1 — vulnerability management" } ], "scanners": [ "Nessus", "Qualys", "Nuclei", "Trivy", "Grype" ], "url": "https://beaconstandards.com/catalog/known-exploited-vulnerabilities" }, { "id": "BCN-T1-PRC-002", "name": "Exposed Management and Orchestration Interfaces", "tier": 1, "domain": "processing", "summary": "Kubernetes dashboards, CI/CD consoles, hypervisor managers, or admin panels reachable from the internet.", "sla": "24 hours", "definition": "A control-plane interface is reachable from an untrusted network. This includes Kubernetes API servers and dashboards, CI/CD consoles such as Jenkins and GitLab runners, hypervisor and out-of-band management (vCenter, iDRAC, iLO), container registries, and application administration panels — whether authentication is required or not.", "whyThisTier": "Control-plane interfaces are force multipliers: compromising one yields authority over every workload beneath it rather than over a single host. A CI/CD system with deployment credentials is functionally an administrative account for production, and an exposed orchestrator permits workload creation, secret retrieval, and code execution across the cluster. These systems are also frequently deployed with permissive defaults and patched on a slower cycle than production applications.", "commonMisclassification": "Interfaces protected by 'a strong password' are sometimes downgraded. Authentication strength does not change the tier while the interface is internet-reachable; the exposure of a control plane is the finding.", "detection": [ "Scan external address space for the characteristic ports and paths of management interfaces (6443, 8080/jenkins, 443/vsphere-client, 623 IPMI).", "Review ingress controllers and load balancer rules for routes that expose control-plane services alongside application traffic.", "Audit out-of-band management networks specifically — BMC and IPMI interfaces are frequently connected to reachable networks during datacentre builds and never revisited.", "Check for anonymous or default-credential access on each interface found, which materially escalates the urgency." ], "remediation": [ "Remove internet reachability, placing the interface behind a VPN or identity-aware proxy — this is the fix, and it is usually available immediately.", "Where the Kubernetes API server must remain reachable, restrict authorised networks to a defined allowlist and disable anonymous authentication.", "Enforce SSO with phishing-resistant MFA on every management console, and remove local administrative accounts.", "Isolate out-of-band management onto a dedicated network with no route to or from the internet.", "Review the interface's audit log across the exposure window, treating unrecognised administrative actions as a suspected incident." ], "verification": "External scanning finds no response on the management port or path, access requires traversal of the intended proxy or VPN, and anonymous authentication is confirmed disabled in the running configuration.", "mitre": [ { "id": "T1133", "name": "External Remote Services" }, { "id": "T1610", "name": "Deploy Container" }, { "id": "T1552.007", "name": "Container API" } ], "cwe": [ { "id": "CWE-284", "name": "Improper Access Control" } ], "owasp": [], "compliance": [ { "framework": "PCI DSS v4.0", "control": "2.2.7 — administrative access encrypted and restricted" }, { "framework": "ISO/IEC 27001:2022", "control": "A.8.20 — network security" }, { "framework": "NIST CSF 2.0", "control": "PR.AA-05 — access permissions" } ], "scanners": [ "Nmap", "Shodan", "Nuclei", "kube-bench", "Trivy" ], "url": "https://beaconstandards.com/catalog/exposed-management-interfaces" }, { "id": "BCN-T1-PRC-003", "name": "No Availability Protection on Revenue-Critical Services", "tier": 1, "domain": "processing", "summary": "Business-critical services with no rate limiting, no DDoS mitigation, and no capacity isolation.", "sla": "48 hours", "definition": "A service whose unavailability directly interrupts revenue or safety operates without rate limiting, upstream DDoS mitigation, or isolation between tenants and workloads. The finding covers both volumetric exposure and application-layer exhaustion — expensive endpoints, unbounded queries, and authentication paths that can be driven to saturation cheaply.", "whyThisTier": "Availability is a security property, and denial of service is used both as an end in itself and as a distraction concurrent with intrusion. Application-layer attacks are the practical concern for most organisations: a single unauthenticated endpoint performing an expensive query can be saturated from one host, without the volumetric traffic that upstream providers detect. Tier 1 applies only where interruption has immediate business consequence.", "commonMisclassification": "Applied too broadly. Tier 1 is for services where interruption has immediate revenue or safety consequence; availability hardening on internal or non-critical services is Tier 3.", "detection": [ "Identify unauthenticated endpoints that trigger disproportionate work — search, report generation, export, and file processing are the usual candidates.", "Confirm whether rate limiting exists per-identity and per-address, and whether it is enforced at the edge or only in application code that the attacker's traffic already reached.", "Verify DDoS mitigation is actually engaged for the specific hostname, rather than merely available on the account.", "Load-test authentication and password-reset paths, which are frequently unprotected and expensive." ], "remediation": [ "Apply edge rate limiting keyed on both source address and authenticated identity, with the limits tuned from observed legitimate traffic.", "Enable upstream DDoS protection for revenue-critical hostnames and confirm the traffic path traverses it.", "Bound expensive operations — enforce query timeouts, result-set caps, and pagination — so that a single request cannot consume unbounded resources.", "Isolate critical workloads from best-effort ones so that saturation in one does not starve the other.", "Add a queue or async execution model for genuinely expensive operations rather than serving them synchronously." ], "verification": "A controlled load test against the identified endpoints triggers rate limiting before service degradation, and the limiting is observed at the edge rather than in application logs alone.", "mitre": [ { "id": "T1498", "name": "Network Denial of Service" }, { "id": "T1499", "name": "Endpoint Denial of Service" } ], "cwe": [ { "id": "CWE-770", "name": "Allocation of Resources Without Limits or Throttling" } ], "owasp": [], "compliance": [ { "framework": "NIST CSF 2.0", "control": "PR.IR-04 — adequate resource capacity" }, { "framework": "ISO/IEC 27001:2022", "control": "A.8.6 — capacity management" }, { "framework": "SOC 2", "control": "A1.1 — availability commitments" } ], "scanners": [ "k6", "Burp Suite", "Nuclei", "PROWLER" ], "url": "https://beaconstandards.com/catalog/no-availability-protection" }, { "id": "BCN-T2-NET-001", "name": "Regulated Environment Segmentation Gaps", "tier": 2, "domain": "network", "summary": "Insufficient isolation around a cardholder, health, or otherwise regulated data environment.", "sla": "30 days", "definition": "The boundary around a regulated environment is incompletely defined or incompletely enforced, so that systems which should be out of assessment scope can reach in. In PCI DSS terms this expands the cardholder data environment; in HIPAA and GDPR terms it expands the population of systems subject to the relevant controls.", "whyThisTier": "The immediate consequence is scope rather than compromise: every system that can reach the regulated environment is drawn into the assessment, multiplying the control obligations and the cost of the audit. Assessors test segmentation directly and a failed segmentation test is a reportable deficiency. Where the gap also exposes crown-jewel systems to routine endpoint compromise, escalate to BCN-T1-NET-003.", "commonMisclassification": "Confused with BCN-T1-NET-003. The distinguishing question is consequence: audit scope expansion is Tier 2, exposure of crown-jewel systems to lateral movement is Tier 1. A single gap can be both, in which case the Tier 1 SLA governs.", "detection": [ "Obtain the current data-flow diagram and test it — the discrepancy between documented and actual flows is where the finding lives.", "Run segmentation penetration testing from each adjacent network into the regulated environment, which is the same evidence the assessor will request.", "Review firewall rule sets for any-any rules, rules with expired business justification, and rules whose stated owner has left.", "Enumerate systems that provide, support, or secure the environment — they are in scope even when they hold no regulated data themselves." ], "remediation": [ "Define the boundary formally and produce a current data-flow diagram; the diagram is a required artefact, not documentation overhead.", "Implement default-deny at the boundary with an explicit allowlist, each entry carrying a business justification and a named owner.", "Withdraw unnecessary connectivity to reduce scope — removing systems from scope is usually cheaper than bringing them into compliance.", "Schedule segmentation testing at the cadence the applicable standard requires, and retain the reports as evidence.", "Establish rule review as a recurring control so that the boundary does not erode between assessments." ], "verification": "Independent segmentation testing confirms the boundary holds, results are documented in the format the assessor accepts, and the data-flow diagram matches tested reality.", "mitre": [ { "id": "T1021", "name": "Remote Services" } ], "cwe": [], "owasp": [], "compliance": [ { "framework": "PCI DSS v4.0", "control": "1.2.1 / 11.4.5 — segmentation and its testing" }, { "framework": "HIPAA", "control": "§164.312(a) — technical safeguards" }, { "framework": "ISO/IEC 27001:2022", "control": "A.8.22 — segregation of networks" } ], "scanners": [ "Nmap", "Nessus", "manual segmentation testing" ], "url": "https://beaconstandards.com/catalog/regulated-environment-segmentation" }, { "id": "BCN-T2-NET-002", "name": "Insufficient Logging and Retention", "tier": 2, "domain": "network", "summary": "Security-relevant events are not captured, not centralised, or not retained for the required period.", "sla": "30 days", "definition": "Logging is absent, incomplete, or retained for less than the applicable requirement across network devices, cloud control planes, applications, and identity providers. The finding includes logs that exist locally but are not centralised, and centralised logs that lack integrity protection against modification by an attacker who reaches the host.", "whyThisTier": "Every major framework mandates specific log content and retention periods — PCI DSS requires twelve months with three immediately available — and inadequate logging is among the most frequently cited audit deficiencies. The operational consequence appears during incident response, where absent logs mean the scope of a breach cannot be established, which under most notification regimes obliges you to assume the worst case and notify accordingly.", "commonMisclassification": "Absence of detection capability is often filed here. Missing IDS/IPS coverage is BCN-T2-NET-003; this finding concerns the capture and retention of records.", "detection": [ "Compare captured log sources against the applicable requirement, item by item; partial coverage is the norm and is what assessors find.", "Verify actual retention in the storage tier rather than the configured policy, and confirm logs remain queryable rather than merely stored.", "Confirm cloud control-plane logging (CloudTrail, Azure Activity, GCP Audit) is enabled in every region and account, including those that are unused.", "Test whether a host-level administrator can alter or delete that host's forwarded logs — if so, integrity protection is absent." ], "remediation": [ "Enable control-plane logging organisation-wide with a policy that prevents disablement in individual accounts.", "Centralise into a store held in a separate account or subscription, with write-once semantics and no delete permission for operational roles.", "Set retention to the longest applicable requirement across every framework in scope, using tiered storage to control cost rather than shortening retention.", "Add the log sources the standard names explicitly — administrative actions, authentication events, and access to regulated data are the usual gaps.", "Document the logging architecture and evidence retention, since assessors test the documentation as well as the control." ], "verification": "A sampled security event is retrievable from centralised storage at the far end of the retention period, and an attempt to delete a log object from an operational role is denied.", "mitre": [ { "id": "T1562.008", "name": "Impair Defenses: Disable Cloud Logs" }, { "id": "T1070", "name": "Indicator Removal" } ], "cwe": [], "owasp": [], "compliance": [ { "framework": "PCI DSS v4.0", "control": "10.5.1 — twelve months retention, three immediately available" }, { "framework": "SOC 2", "control": "CC7.2 — monitoring for anomalies" }, { "framework": "ISO/IEC 27001:2022", "control": "A.8.15 — logging" }, { "framework": "HIPAA", "control": "§164.312(b) — audit controls" } ], "scanners": [ "PROWLER", "Cloudsploit", "ScoutSuite" ], "url": "https://beaconstandards.com/catalog/insufficient-logging-retention" }, { "id": "BCN-T2-NET-003", "name": "Missing Intrusion Detection Coverage", "tier": 2, "domain": "network", "summary": "No detection capability at network boundaries or across critical segments.", "sla": "30 days", "definition": "Network-based detection is absent or covers only part of the estate — commonly present at the internet edge but absent between internal segments, or deployed for on-premises networks with no equivalent for cloud workloads. The finding also covers deployed sensors producing alerts that no process consumes.", "whyThisTier": "Detection is explicitly mandated by PCI DSS, NIST CSF, and ISO 27001, making its absence a direct audit deficiency. It is Tier 2 rather than Tier 1 because detection does not prevent compromise — it bounds dwell time. An estate with strong preventive controls and no detection is in a materially better position than the reverse, which is why Beacon does not treat this as an emergency, but the gap directly determines how long an intrusion runs before anyone notices.", "commonMisclassification": "Endpoint detection is sometimes recorded as satisfying this finding. EDR and network detection cover different traffic and different techniques; frameworks that require network-based detection are not satisfied by endpoint coverage alone.", "detection": [ "Map deployed sensors against network topology and identify segments with no coverage — east-west traffic is the usual gap.", "Confirm cloud workloads are covered by an equivalent capability, since traditional appliances do not see cloud-internal traffic.", "Test with a benign, agreed detection trigger and confirm the alert reaches a human, which is the control that actually matters.", "Review alert disposition: a high false-positive rate that has led to alerts being ignored is functionally equivalent to no coverage." ], "remediation": [ "Prioritise coverage at the regulated-environment boundary, which is where assessors look first.", "Deploy cloud-native detection (GuardDuty, Defender for Cloud, Security Command Center) for cloud workloads rather than attempting to route traffic to on-premises appliances.", "Route alerts into a monitored queue with a defined triage owner and response time, and tune out false positives rather than allowing them to accumulate.", "Establish a recurring detection test so coverage is verified continuously rather than assumed between audits.", "Document coverage and tuning decisions as evidence." ], "verification": "A benign detection trigger executed in each covered segment produces an alert that reaches the triage queue within the defined time, evidenced by the ticket rather than by the console.", "mitre": [ { "id": "T1562.001", "name": "Impair Defenses: Disable or Modify Tools" } ], "cwe": [], "owasp": [], "compliance": [ { "framework": "PCI DSS v4.0", "control": "11.5.1 — intrusion detection and prevention" }, { "framework": "NIST CSF 2.0", "control": "DE.CM-01 — networks are monitored" }, { "framework": "ISO/IEC 27001:2022", "control": "A.8.16 — monitoring activities" } ], "scanners": [ "Suricata", "Zeek", "GuardDuty", "PROWLER" ], "url": "https://beaconstandards.com/catalog/missing-intrusion-detection" }, { "id": "BCN-T2-IAM-001", "name": "Non-Compliant Authentication Policy", "tier": 2, "domain": "iam", "summary": "Password and authentication settings that do not meet the applicable regulatory standard.", "sla": "30 days", "definition": "Authentication policy diverges from the requirements of an applicable framework — password length or complexity below the mandated minimum, absent lockout thresholds, missing session timeouts, or MFA not extended to the full population the standard names. The finding concerns the general user population; privileged accounts without MFA are BCN-T1-IAM-001.", "whyThisTier": "Authentication settings are among the first items an assessor tests, because they are objectively verifiable from a configuration export. Deficiencies are cited reliably and are usually straightforward to remediate. Note that frameworks have diverged: NIST SP 800-63B now discourages mandatory periodic rotation and composition rules, while PCI DSS v4.0 continues to specify minimums — where a policy must satisfy both, the stricter applies.", "commonMisclassification": "Frequently over-escalated to Tier 1 because it concerns authentication. Weak policy on non-privileged accounts is a compliance deficiency; missing MFA on privileged accounts is the Tier 1 case.", "detection": [ "Export the effective authentication policy from every identity provider and compare against each applicable framework's requirement.", "Check for policy exceptions and exempted groups, which is where non-compliance concentrates.", "Confirm the policy applies to federated and guest identities, not only to accounts created locally.", "Verify session timeout and re-authentication settings, which are commonly overlooked and explicitly required." ], "remediation": [ "Set policy to the strictest applicable requirement across frameworks in scope and apply it uniformly.", "Prefer length and breach-corpus screening over composition rules, which is both current guidance and more effective.", "Remove standing exemptions; where one is genuinely required, record it as a formal, time-bounded exception with compensating controls.", "Extend MFA coverage to the full population once privileged accounts are complete.", "Retain the policy export as evidence, since assessors ask for the configuration rather than the intent." ], "verification": "A configuration export from each identity provider satisfies every applicable requirement with no unexplained exemptions, and a test account confirms enforcement in practice.", "mitre": [ { "id": "T1110", "name": "Brute Force" }, { "id": "T1078", "name": "Valid Accounts" } ], "cwe": [ { "id": "CWE-521", "name": "Weak Password Requirements" } ], "owasp": [], "compliance": [ { "framework": "PCI DSS v4.0", "control": "8.3.6 — minimum password strength" }, { "framework": "NIST SP 800-63B", "control": "5.1.1 — memorized secret requirements" }, { "framework": "ISO/IEC 27001:2022", "control": "A.5.17 — authentication information" }, { "framework": "SOC 2", "control": "CC6.1 — logical access" } ], "scanners": [ "PROWLER", "ScoutSuite", "identity provider configuration export" ], "url": "https://beaconstandards.com/catalog/non-compliant-authentication-policy" }, { "id": "BCN-T2-IAM-002", "name": "Missing Periodic Access Reviews", "tier": 2, "domain": "iam", "summary": "No recurring, evidenced certification that granted access remains appropriate.", "sla": "30 days", "definition": "Access rights are granted but never systematically re-examined. There is no recurring process in which an accountable owner confirms that each identity's access remains appropriate, and no retained evidence of such a review having occurred. The finding covers both the absence of the process and a process that runs without producing auditable records.", "whyThisTier": "Access review is explicitly required by SOC 2, ISO 27001, and PCI DSS, and is tested by sampling — an assessor selects identities and asks for the certification record. Absent records are a citable deficiency regardless of whether the underlying access is appropriate. Operationally, the absence of review is the mechanism by which privilege accumulates: without it, access granted for a temporary project persists for years and eventually becomes BCN-T1-IAM-002.", "commonMisclassification": "Discovering excessive privilege during a review is a separate finding — record the specific privilege under BCN-T1-IAM-002 or BCN-T3-IAM-001 and keep this finding scoped to the absence of the process.", "detection": [ "Ask for the last completed review and its evidence; inability to produce it is the finding.", "Check leaver processing by sampling recent departures and confirming access was revoked within the defined period.", "Look for orphaned accounts with no active owner, and for accounts whose last authentication predates their owner's role change.", "Confirm reviews cover third-party, contractor, and service identities, which are typically excluded from HR-triggered processes." ], "remediation": [ "Define the review cycle per the strictest applicable requirement — typically quarterly for privileged access, annually for standard.", "Assign accountable reviewers who understand the business context; a review performed by IT alone is evidence of process, not of appropriateness.", "Automate campaign generation and evidence capture, since manual reviews degrade after the first cycle.", "Integrate with joiner-mover-leaver so that role changes trigger review rather than relying on the periodic cycle.", "Retain completed campaigns with reviewer identity and timestamp as the audit artefact." ], "verification": "A completed review campaign exists for the current period covering all in-scope identities, with per-reviewer attestations retained, and sampled revocations are confirmed applied in the target system.", "mitre": [ { "id": "T1078", "name": "Valid Accounts" } ], "cwe": [], "owasp": [], "compliance": [ { "framework": "SOC 2", "control": "CC6.2 / CC6.3 — access is reviewed" }, { "framework": "PCI DSS v4.0", "control": "7.2.4 — review user accounts every six months" }, { "framework": "ISO/IEC 27001:2022", "control": "A.5.18 — access rights" } ], "scanners": [ "Entra ID access reviews", "AWS IAM Access Analyzer", "SailPoint" ], "url": "https://beaconstandards.com/catalog/missing-access-reviews" }, { "id": "BCN-T2-IAM-003", "name": "Ungoverned Service Accounts", "tier": 2, "domain": "iam", "summary": "Non-human identities without owners, documented purpose, or lifecycle management.", "sla": "30 days", "definition": "Service accounts, workload identities, and machine credentials exist without a named owner, a documented purpose, or inclusion in any lifecycle process. They are typically excluded from access reviews because those processes are driven by HR events that non-human identities never generate.", "whyThisTier": "Non-human identities outnumber human ones in most modern estates, frequently by an order of magnitude, and they hold correspondingly significant privilege. Their exclusion from governance is a control-design gap that assessors increasingly test explicitly. It is Tier 2 rather than Tier 1 because it describes the absence of governance rather than a specific exposure — a service account found to hold excessive privilege or a static privileged key is separately BCN-T1-IAM-002 or BCN-T1-IAM-003.", "commonMisclassification": "Individual over-privileged service accounts are often recorded here. Keep this finding scoped to governance absence and record specific excessive privilege separately, so remediation of one does not close the other.", "detection": [ "Enumerate all non-human identities across every identity provider and cloud account, then attempt to attribute each to a named owner — the unattributable remainder is the finding.", "Identify accounts with interactive sign-in capability, which service accounts should not have.", "Report last-used timestamps; dormant service accounts with live credentials are the highest-risk subset.", "Check whether service accounts are shared across applications, which makes rotation and revocation impossible without coordinated change." ], "remediation": [ "Build the inventory first with owner, purpose, and permission scope — governance cannot be applied to an unknown population.", "Assign an accountable owner to each, and decommission any identity for which no owner can be found after a defined notice period.", "Replace shared accounts with per-application identities so that rotation and revocation become possible.", "Migrate to platform-managed workload identity where supported, which removes the credential entirely.", "Include non-human identities in the access review cycle with an owner-attestation step." ], "verification": "Every active non-human identity maps to a named owner and documented purpose in the inventory, none retains interactive sign-in capability, and the population is covered by the current review campaign.", "mitre": [ { "id": "T1078.004", "name": "Valid Accounts: Cloud Accounts" }, { "id": "T1136", "name": "Create Account" } ], "cwe": [], "owasp": [], "compliance": [ { "framework": "SOC 2", "control": "CC6.1 — logical access to assets" }, { "framework": "ISO/IEC 27001:2022", "control": "A.5.16 — identity management" }, { "framework": "PCI DSS v4.0", "control": "8.6.1 — interactive use of system accounts" } ], "scanners": [ "PROWLER", "ScoutSuite", "Entra ID workload identity reports" ], "url": "https://beaconstandards.com/catalog/ungoverned-service-accounts" }, { "id": "BCN-T2-DAT-001", "name": "Encryption Below Regulatory Standard", "tier": 2, "domain": "data", "summary": "Data is encrypted, but with algorithms, key lengths, or key management that fail the applicable requirement.", "sla": "30 days", "definition": "Encryption is present but does not meet the mandated standard: deprecated algorithms or protocol versions (TLS 1.0/1.1, 3DES, RSA-1024), keys below the required length, keys stored alongside the data they protect, or the absence of a documented key-management lifecycle covering generation, rotation, and destruction.", "whyThisTier": "Assessors test cipher configuration directly and key management is a substantial control area in its own right — PCI DSS devotes a full requirement section to it. Deficiencies here are reliably cited. It is Tier 2 rather than Tier 1 because data is protected against casual exposure; the gap is that the protection does not meet the standard you are contractually or legally held to, and in most cases does not qualify for breach-notification safe harbour.", "commonMisclassification": "Conflated with BCN-T1-DAT-003. Absent encryption on a reachable store is Tier 1; encryption that is present but non-conforming is Tier 2.", "detection": [ "Scan TLS endpoints for protocol versions, cipher suites, and certificate key sizes, covering internal endpoints as well as external.", "Review at-rest encryption algorithms and key lengths against the applicable requirement.", "Determine where key material is stored — keys held in the same system, account, or backup as the data provide substantially less assurance than the configuration implies.", "Ask for the key-management procedure and rotation records; absence of documentation is itself the deficiency for several frameworks." ], "remediation": [ "Disable deprecated protocols and cipher suites at the edge, then work inward to internal services.", "Move key material into a managed KMS or HSM with access control independent of the data plane.", "Establish and document the key lifecycle — generation, rotation, escrow, destruction — with defined custodians and split knowledge where required.", "Re-encrypt data held under deprecated algorithms rather than only changing the setting for new writes.", "Retain scan output and rotation records as evidence." ], "verification": "An external and internal TLS scan reports only approved protocol versions and ciphers, at-rest configuration meets the required algorithm and key length, and a rotation record exists for the current period.", "mitre": [ { "id": "T1040", "name": "Network Sniffing" } ], "cwe": [ { "id": "CWE-327", "name": "Use of a Broken or Risky Cryptographic Algorithm" } ], "owasp": [ "A02:2021 — Cryptographic Failures" ], "compliance": [ { "framework": "PCI DSS v4.0", "control": "3.6 / 3.7 — cryptographic key management" }, { "framework": "HIPAA", "control": "§164.312(e)(1) — transmission security" }, { "framework": "GDPR", "control": "Art. 32(1)(a) — encryption" }, { "framework": "ISO/IEC 27001:2022", "control": "A.8.24 — use of cryptography" } ], "scanners": [ "testssl.sh", "SSL Labs", "Nessus", "PROWLER" ], "url": "https://beaconstandards.com/catalog/encryption-below-standard" }, { "id": "BCN-T2-DAT-002", "name": "Data Retention and Deletion Non-Compliance", "tier": 2, "domain": "data", "summary": "Personal or regulated data kept beyond its lawful basis, or deletion requests not honoured throughout.", "sla": "30 days", "definition": "Data is retained past the period justified by its lawful basis or business need, or deletion is incomplete — records removed from a primary database while persisting in backups, analytics warehouses, log aggregation, search indexes, and third-party processors. Also covers the absence of any defined retention schedule.", "whyThisTier": "Storage limitation is a substantive obligation under GDPR Article 5(1)(e), and data-subject erasure rights under Article 17 carry direct regulatory exposure. Retained data is also breach exposure that produces no business value — the cheapest possible reduction in blast radius is deleting what you should not still hold. Tier 2 reflects that the consequence is regulatory rather than immediate compromise.", "commonMisclassification": "Treated as a legal rather than a security finding and consequently routed away from the vulnerability backlog. Retention is a security control — it directly determines breach blast radius — and belongs in the same queue.", "detection": [ "Compare the documented retention schedule against actual data ages per system; the absence of a schedule is itself the finding.", "Trace a test deletion request end to end through every downstream system, which is where incompleteness is found.", "Enumerate secondary copies — warehouses, backups, search indexes, caches, logs, and processor systems — and confirm each is in scope for deletion.", "Review processor contracts for deletion obligations and confirm they are exercised rather than merely agreed." ], "remediation": [ "Publish a retention schedule per data category with the lawful basis and retention period stated.", "Automate deletion at the end of the retention period rather than relying on periodic manual purges.", "Extend deletion to every downstream copy, and where backup architecture makes selective deletion impractical, document the compensating approach — typically encryption with per-subject key destruction.", "Establish a data-subject request process with a tracked service level.", "Instruct processors to delete on the same schedule and retain their confirmations." ], "verification": "A test data-subject erasure request completes across all identified systems within the statutory period, evidenced per system, and automated retention deletion is observed executing on schedule.", "mitre": [ { "id": "T1213", "name": "Data from Information Repositories" } ], "cwe": [], "owasp": [], "compliance": [ { "framework": "GDPR", "control": "Art. 5(1)(e) / Art. 17 — storage limitation and erasure" }, { "framework": "PCI DSS v4.0", "control": "3.2.1 — retain account data only as required" }, { "framework": "ISO/IEC 27001:2022", "control": "A.5.33 — protection of records" } ], "scanners": [ "data discovery tooling", "Macie", "Purview" ], "url": "https://beaconstandards.com/catalog/retention-deletion-non-compliance" }, { "id": "BCN-T2-DAT-003", "name": "Absent Data Classification", "tier": 2, "domain": "data", "summary": "No scheme identifying which data is sensitive, where it lives, and which controls apply.", "sla": "30 days", "definition": "There is no maintained classification scheme, or a scheme exists on paper without being applied to actual data stores. The organisation cannot state with confidence where regulated data resides, which means control requirements cannot be reliably targeted.", "whyThisTier": "Classification is a prerequisite control that every major framework requires, and its absence undermines every other data control — you cannot encrypt, restrict, or set retention on data you have not located. Assessors treat it as foundational. It is Tier 2 because the absence of classification is not itself an exposure, but it reliably conceals exposures that would otherwise be Tier 1.", "commonMisclassification": "Regulated data discovered in an unexpected, exposed location during classification work is a separate Tier 1 finding — record it as such rather than folding it into the classification programme.", "detection": [ "Ask where regulated data resides and compare the answer against automated discovery results; the delta is the finding.", "Run content discovery across storage, databases, and collaboration platforms — regulated data in file shares and ticketing systems is the usual surprise.", "Check whether classification labels, where they exist, drive any actual control decision, since labels that affect nothing provide no assurance.", "Review whether new systems are classified at onboarding or only during periodic sweeps." ], "remediation": [ "Define a small number of levels — three or four — with concrete handling requirements for each; elaborate schemes are not applied consistently.", "Run automated discovery to establish the current position rather than relying on system-owner recollection.", "Bind classification to enforcement so labels drive encryption, access, retention, and DLP policy.", "Make classification a gate in the system-onboarding process so the inventory does not immediately drift.", "Assign data owners accountable for maintaining classification of their systems." ], "verification": "A maintained inventory maps every system holding regulated data to its classification and applicable controls, automated discovery finds no significant unclassified regulated data, and labels demonstrably drive at least one enforced control.", "mitre": [ { "id": "T1213", "name": "Data from Information Repositories" } ], "cwe": [], "owasp": [], "compliance": [ { "framework": "ISO/IEC 27001:2022", "control": "A.5.12 — classification of information" }, { "framework": "GDPR", "control": "Art. 30 — records of processing activities" }, { "framework": "SOC 2", "control": "CC3.2 — risk identification" } ], "scanners": [ "Macie", "Purview", "BigID", "data discovery tooling" ], "url": "https://beaconstandards.com/catalog/absent-data-classification" }, { "id": "BCN-T2-PRC-001", "name": "Vulnerability Management Process Gaps", "tier": 2, "domain": "processing", "summary": "No defined scanning cadence, remediation SLA, or exception process — or incomplete asset coverage.", "sla": "30 days", "definition": "The vulnerability management programme lacks a defined element: a documented scanning cadence, remediation timeframes by severity, a formal risk-acceptance path, or complete asset coverage. Incomplete coverage is the most common form — scanning that reaches servers but not containers, cloud-native services, or network appliances.", "whyThisTier": "Every major framework mandates a vulnerability management programme with specific cadence and timeframes, and assessors test the process as well as its output. PCI DSS names quarterly external scanning by an approved vendor and remediation windows by severity. It is Tier 2 because the process gap is not itself an exposure, but it is the mechanism by which Tier 1 findings go undetected — an unscanned asset class produces no findings and therefore appears clean.", "commonMisclassification": "Individual unpatched vulnerabilities are frequently recorded against this finding. Those belong to BCN-T1-PRC-001 or their own entries; this finding is about the process, and closing it should not require patching every host.", "detection": [ "Reconcile the scanned asset inventory against the authoritative asset inventory; the difference is the coverage gap.", "Check for asset classes structurally excluded from scanning — containers, serverless functions, appliances, and OT are the usual omissions.", "Measure actual time-to-remediate against the stated SLA by severity; a stated SLA with no measurement is not a control.", "Ask for the risk-acceptance register and confirm exceptions carry an owner, an expiry, and a compensating control." ], "remediation": [ "Document the programme: scope, cadence, severity definitions, remediation timeframes, and the exception path.", "Extend coverage to every asset class, using image scanning for containers and posture management for cloud-native services.", "Instrument SLA measurement and report attainment, since assessors ask for the metric rather than the policy.", "Formalise risk acceptance with named approver, expiry, and compensating control — perpetual undocumented exceptions are a finding in themselves.", "Route findings into the same ticketing system engineering already uses, rather than a security-only tool nobody opens." ], "verification": "Scan coverage reconciles to the asset inventory with documented exclusions, SLA attainment is reported by severity for the current period, and every open exception carries an owner and a future expiry.", "mitre": [ { "id": "T1190", "name": "Exploit Public-Facing Application" } ], "cwe": [], "owasp": [], "compliance": [ { "framework": "PCI DSS v4.0", "control": "11.3 — internal and external vulnerability scanning" }, { "framework": "SOC 2", "control": "CC7.1 — vulnerability identification and management" }, { "framework": "ISO/IEC 27001:2022", "control": "A.8.8 — technical vulnerabilities" }, { "framework": "NIST CSF 2.0", "control": "ID.RA-01 / RS.MI-03" } ], "scanners": [ "Nessus", "Qualys", "Trivy", "PROWLER" ], "url": "https://beaconstandards.com/catalog/vulnerability-management-process-gaps" }, { "id": "BCN-T2-PRC-002", "name": "Change Management Control Gaps", "tier": 2, "domain": "processing", "summary": "Production changes without review, approval, testing, or a recorded rollback path.", "sla": "30 days", "definition": "Changes reach production without the controls the applicable framework requires — peer review, documented approval, separation between the identity that authors a change and the one that deploys it, testing evidence, or a rollback plan. Includes infrastructure changes made directly in a console, bypassing the pipeline entirely.", "whyThisTier": "Change management is a core control area for SOC 2 and PCI DSS, tested by sampling production changes and requesting evidence for each. It is Tier 2 because the consequence is audit and reliability exposure rather than direct compromise, though undocumented direct-to-production changes are also the most common source of the misconfigurations that become Tier 1 findings.", "commonMisclassification": "Recorded as an engineering-process concern and excluded from the security backlog. It is a security control — it is the mechanism preventing unreviewed misconfiguration reaching production — and belongs in the same queue.", "detection": [ "Sample recent production changes and attempt to produce the required evidence for each — this replicates the assessor's test exactly.", "Compare cloud control-plane logs against pipeline deployment records to find changes made outside the pipeline.", "Check whether repository branch protection actually enforces review, or whether administrators can merge without it.", "Confirm separation of duties between change authoring and production deployment." ], "remediation": [ "Route all production change through the pipeline and remove standing console write access, replacing it with just-in-time elevation.", "Enforce branch protection with required review, applied to administrators as well.", "Capture approval, testing, and rollback evidence automatically as pipeline artefacts rather than as manual records.", "Define an emergency change path with retrospective review, so urgent changes have a compliant route rather than an ad-hoc one.", "Alert on control-plane changes originating outside the pipeline." ], "verification": "A sample of recent production changes each produces review, approval, and testing evidence from pipeline artefacts, and control-plane logs show no unaccounted direct modifications.", "mitre": [ { "id": "T1195", "name": "Supply Chain Compromise" } ], "cwe": [], "owasp": [], "compliance": [ { "framework": "SOC 2", "control": "CC8.1 — change management" }, { "framework": "PCI DSS v4.0", "control": "6.5.1 — change control procedures" }, { "framework": "ISO/IEC 27001:2022", "control": "A.8.32 — change management" } ], "scanners": [ "CloudTrail analysis", "GitHub/GitLab audit logs" ], "url": "https://beaconstandards.com/catalog/change-management-gaps" }, { "id": "BCN-T2-PRC-003", "name": "Untested Incident Response Capability", "tier": 2, "domain": "processing", "summary": "No incident response plan, or a plan that has never been exercised.", "sla": "30 days", "definition": "There is no documented incident response plan, or the plan exists but has not been tested within the required period. Also covers plans that are documented but unusable in practice — missing current contact details, no defined severity thresholds, or no regulatory notification timelines.", "whyThisTier": "Incident response planning and annual testing are explicitly required by PCI DSS, ISO 27001, HIPAA, and SOC 2, and assessors ask for the test record rather than the plan. The operational stake is high: breach-notification regimes impose short deadlines — 72 hours under GDPR — and an organisation discovering its plan's gaps during a live incident will miss them. It is Tier 2 because the capability matters at the moment of compromise rather than preventing it.", "commonMisclassification": "Deferred as a documentation task. The test — not the document — is what both frameworks and reality require, and the test is what reveals whether the capability exists.", "detection": [ "Ask for the plan and its last test record; either being absent is the finding.", "Check that the plan names regulatory notification timelines for every applicable regime and jurisdiction.", "Verify contact details, escalation paths, and third-party retainers are current — these decay fastest.", "Confirm the plan covers cloud and SaaS incidents, not only on-premises scenarios." ], "remediation": [ "Document the plan with severity definitions, roles, escalation paths, and notification obligations with their statutory deadlines.", "Run a tabletop exercise against a realistic scenario — ransomware and cloud account compromise are the highest-value starting points.", "Record lessons learned and update the plan; the update record is the evidence assessors want.", "Establish retainers for forensics and legal counsel in advance, since procurement during an incident consumes the notification window.", "Test at least annually and after any material change to the estate." ], "verification": "A current plan exists with defined severities and notification deadlines, a test conducted within the required period is documented with participants and findings, and resulting plan updates are recorded.", "mitre": [ { "id": "T1486", "name": "Data Encrypted for Impact" } ], "cwe": [], "owasp": [], "compliance": [ { "framework": "PCI DSS v4.0", "control": "12.10.1 / 12.10.2 — incident response plan and annual testing" }, { "framework": "ISO/IEC 27001:2022", "control": "A.5.24 — incident management planning" }, { "framework": "GDPR", "control": "Art. 33 — notification within 72 hours" }, { "framework": "SOC 2", "control": "CC7.4 — incident response" } ], "scanners": [ "tabletop exercise", "purple team assessment" ], "url": "https://beaconstandards.com/catalog/untested-incident-response" }, { "id": "BCN-T3-NET-001", "name": "Non-Critical Service Exposure", "tier": 3, "domain": "network", "summary": "Unnecessary services reachable on internal networks, expanding attack surface without immediate risk.", "sla": "90 days", "definition": "Services are listening and reachable within internal networks without a current business need — legacy applications retained after migration, default daemons enabled at build time, or diagnostic endpoints left from troubleshooting. The services are not internet-exposed and hold no immediately exploitable defect.", "whyThisTier": "Each unnecessary service is a future Tier 1 candidate: it will eventually need a patch, and it provides a foothold for lateral movement once an attacker is inside. The risk is real but deferred, and remediation is straightforward — reducing surface area now avoids compounding maintenance later. Tier 3 is appropriate because nothing here is exploitable today from an untrusted position.", "commonMisclassification": "Internet-facing exposure is sometimes recorded here on the grounds that the service is unimportant. Any unnecessary internet-facing service is Tier 1 under BCN-T1-NET-001 or BCN-T1-PRC-002; Tier 3 applies to internal exposure only.", "detection": [ "Run internal network scans and reconcile listening services against the documented service inventory.", "Compare against a hardened baseline image to identify services enabled by default and never disabled.", "Identify services with no traffic over an extended observation window — flow logs make this straightforward.", "Look for legacy systems retained after migration, which typically remain reachable and unpatched." ], "remediation": [ "Disable services with no identified consumer, working from the observation data rather than from assumption.", "Update the base image so newly-provisioned hosts do not reintroduce the same services.", "Bind services that must remain to loopback or a management interface rather than a general-purpose one.", "Decommission legacy systems formally, including DNS and certificate cleanup.", "Add drift detection so newly-listening services are surfaced rather than discovered at the next annual scan." ], "verification": "An internal scan reconciles to the service inventory with no unexplained listeners, and a freshly-provisioned host from the updated base image exposes only the intended services.", "mitre": [ { "id": "T1046", "name": "Network Service Discovery" } ], "cwe": [], "owasp": [], "compliance": [ { "framework": "PCI DSS v4.0", "control": "2.2.4 — only necessary services enabled" }, { "framework": "ISO/IEC 27001:2022", "control": "A.8.9 — configuration management" }, { "framework": "NIST CSF 2.0", "control": "PR.PS-01 — configuration management" } ], "scanners": [ "Nmap", "Nessus", "OpenSCAP" ], "url": "https://beaconstandards.com/catalog/non-critical-service-exposure" }, { "id": "BCN-T3-NET-002", "name": "Cloud Network Hardening Gaps", "tier": 3, "domain": "network", "summary": "Cloud network configuration diverging from CIS Benchmark or provider best practice.", "sla": "90 days", "definition": "Cloud network configuration departs from established benchmarks without creating direct exposure — default VPCs still present, overly broad security group rules on internal traffic, absent VPC flow logging, unused elastic IPs, or missing private endpoints for provider services.", "whyThisTier": "These are the conditions from which Tier 1 findings emerge. A default VPC with permissive rules is the environment in which someone eventually launches an internet-facing instance by accident. Individually low-impact and each cheap to fix, they compound into the misconfigurations that appear in breach reports. Benchmark alignment also materially reduces audit friction.", "commonMisclassification": "Benchmark reports frequently include genuinely Tier 1 items — public storage, unrestricted administrative ingress — mixed into the same output. Triage benchmark findings individually rather than importing the whole report at Tier 3.", "detection": [ "Run a CIS Benchmark assessment with PROWLER, Cloudsploit, or ScoutSuite across every account and region.", "Check for default VPCs in unused regions, which are commonly overlooked and permissively configured.", "Identify security groups with broad internal CIDR sources rather than security-group references.", "Confirm private endpoints are used for provider services so that traffic does not traverse the public internet unnecessarily." ], "remediation": [ "Delete default VPCs in regions with no workloads, and restrict region usage through policy.", "Replace CIDR-based internal rules with security-group references so policy follows workloads.", "Enable flow logging on all VPCs, which also supports BCN-T2-NET-002.", "Adopt private endpoints for provider service access.", "Encode the benchmark as preventive policy so remediated items do not regress." ], "verification": "A benchmark assessment reports the target pass rate across all accounts and regions, with documented exceptions, and preventive policy blocks reintroduction of the corrected items.", "mitre": [ { "id": "T1580", "name": "Cloud Infrastructure Discovery" } ], "cwe": [], "owasp": [], "compliance": [ { "framework": "CIS Benchmarks", "control": "AWS/Azure/GCP Foundations — networking section" }, { "framework": "ISO/IEC 27001:2022", "control": "A.8.9 — configuration management" }, { "framework": "NIST CSF 2.0", "control": "PR.PS-01" } ], "scanners": [ "PROWLER", "Cloudsploit", "ScoutSuite", "Steampipe" ], "url": "https://beaconstandards.com/catalog/cloud-network-hardening" }, { "id": "BCN-T3-NET-003", "name": "Incomplete Egress Filtering", "tier": 3, "domain": "network", "summary": "Unrestricted outbound connectivity, permitting unconstrained command-and-control and exfiltration.", "sla": "90 days", "definition": "Workloads can initiate outbound connections to arbitrary internet destinations on arbitrary ports. Most environments filter inbound rigorously and outbound not at all, leaving a compromised workload free to reach any command-and-control endpoint and to exfiltrate at will.", "whyThisTier": "Egress filtering does not prevent compromise; it constrains what an attacker can do afterwards, breaking the command-and-control step that most intrusion tooling depends on. It is Tier 3 because implementing it in a mature estate requires substantial discovery of legitimate destinations and carries real breakage risk — it is a project rather than a change. The defensive value is nonetheless high.", "commonMisclassification": "Abandoned as impractical rather than being recorded and deferred. Beacon treats formal deferral with a recorded rationale as a legitimate Tier 3 outcome — an undocumented decision not to do it is not.", "detection": [ "Review egress rules for unrestricted destinations, particularly on workloads processing sensitive data.", "Analyse flow logs to establish which outbound destinations are genuinely used — this is the necessary input to any allowlist.", "Check whether DNS resolution is unrestricted, since DNS is a common exfiltration channel that port-based filtering does not address.", "Identify workloads with no legitimate outbound need at all — these are the correct starting point." ], "remediation": [ "Begin with workloads that have no outbound requirement, where default-deny is achievable immediately and without risk.", "Build allowlists from observed flow data rather than from documentation, then apply in monitor-only mode before enforcing.", "Route necessary egress through inspecting proxies for logging and policy enforcement.", "Restrict DNS to approved resolvers and monitor for tunnelling patterns.", "Use provider private endpoints so that provider-service traffic does not require broad internet egress." ], "verification": "Sensitive workloads deny outbound connections to destinations outside the allowlist, the denial is visible in flow logs, and DNS resolution is confined to approved resolvers.", "mitre": [ { "id": "T1071", "name": "Application Layer Protocol" }, { "id": "T1041", "name": "Exfiltration Over C2 Channel" }, { "id": "T1048", "name": "Exfiltration Over Alternative Protocol" } ], "cwe": [], "owasp": [], "compliance": [ { "framework": "PCI DSS v4.0", "control": "1.3.2 — restrict outbound traffic from the CDE" }, { "framework": "NIST CSF 2.0", "control": "PR.IR-01 — networks are protected" }, { "framework": "ISO/IEC 27001:2022", "control": "A.8.20 — network security" } ], "scanners": [ "flow log analysis", "PROWLER", "Zeek" ], "url": "https://beaconstandards.com/catalog/incomplete-egress-filtering" }, { "id": "BCN-T3-IAM-001", "name": "Coarse-Grained Role Design", "tier": 3, "domain": "iam", "summary": "Roles that are scoped but still broader than the tasks they support.", "sla": "90 days", "definition": "Roles exist and are not administrative, but each grants more than its holders need — a single 'developer' role spanning every service, read access to all data rather than to the relevant subset, or environments sharing one role definition. This is refinement of an already-functioning model, not the absence of one.", "whyThisTier": "Role refinement reduces blast radius incrementally, and each iteration reduces what a compromised account yields. It is Tier 3 because a working role model already exists and the residual excess is bounded — where roles carry administrative privilege the finding is BCN-T1-IAM-002 instead. This work compounds: teams that refine roles continuously accumulate far fewer Tier 1 privilege findings.", "commonMisclassification": "Confused with BCN-T1-IAM-002. If the role carries administrative or production-wide privilege it is Tier 1; Tier 3 is for narrowing already-bounded roles.", "detection": [ "Compare granted against exercised permissions per role using provider access analysers.", "Identify roles shared across functions or environments, which necessarily grant the union of every holder's needs.", "Look for roles whose membership has grown well beyond the population originally intended.", "Check whether non-production environments reuse production role definitions." ], "remediation": [ "Split multi-purpose roles along observed usage boundaries, starting with the most widely-held.", "Separate role definitions per environment so non-production access cannot reach production.", "Scope data access to the relevant subset rather than granting estate-wide read.", "Adopt attribute-based conditions where the platform supports them, reducing the number of discrete roles required.", "Re-derive role scope from usage data periodically so definitions track how teams actually work." ], "verification": "Usage analysis shows granted permissions closely tracking exercised ones for the refined roles, and no role spans multiple environments.", "mitre": [ { "id": "T1078", "name": "Valid Accounts" } ], "cwe": [ { "id": "CWE-269", "name": "Improper Privilege Management" } ], "owasp": [], "compliance": [ { "framework": "ISO/IEC 27001:2022", "control": "A.8.2 — privileged access rights" }, { "framework": "SOC 2", "control": "CC6.3 — role-based access control" }, { "framework": "NIST CSF 2.0", "control": "PR.AA-05 — access permissions" } ], "scanners": [ "IAM Access Analyzer", "PROWLER", "Entra Permissions Management" ], "url": "https://beaconstandards.com/catalog/coarse-grained-rbac" }, { "id": "BCN-T3-IAM-002", "name": "Manual Credential Lifecycle", "tier": 3, "domain": "iam", "summary": "Credential provisioning, rotation, and revocation performed by hand rather than automatically.", "sla": "90 days", "definition": "Credentials are managed through manual process — rotation performed on a calendar reminder, provisioning through ticket and console, revocation depending on someone remembering. The credentials are within policy today; the finding is that maintaining that state depends on human diligence.", "whyThisTier": "Manual processes fail silently and eventually. Every long-lived credential finding at Tier 1 began as a manual rotation that stopped happening, which makes automation preventive work with clearly compounding returns. Tier 3 is correct because the current state is compliant — this is investment against future Tier 1 and Tier 2 findings rather than a present exposure.", "commonMisclassification": "Applied to privileged credentials that are already past their rotation interval. That state is BCN-T1-IAM-003; this finding covers process immaturity where credentials are currently within policy.", "detection": [ "Ask how rotation occurs; if the answer names a person or a reminder rather than a system, the finding applies.", "Compare actual rotation dates against policy intervals to see whether manual process is holding.", "Check whether revocation is triggered by an authoritative event or by notification.", "Identify credentials distributed by hand — chat, email, shared documents — which cannot be rotated without coordination." ], "remediation": [ "Adopt a managed secret store with automatic rotation for supported credential types.", "Replace static credentials with short-lived federated ones wherever the platform allows, which removes rotation from the problem entirely.", "Automate provisioning and deprovisioning from the authoritative identity source.", "Deliver credentials to workloads through the secret store rather than through people.", "Alert on credentials approaching maximum age so failures surface before expiry." ], "verification": "Rotation for supported credential types occurs automatically and is observable in the secret store's audit log, and a simulated leaver event triggers automated deprovisioning.", "mitre": [ { "id": "T1552", "name": "Unsecured Credentials" } ], "cwe": [], "owasp": [], "compliance": [ { "framework": "ISO/IEC 27001:2022", "control": "A.5.17 — authentication information" }, { "framework": "NIST CSF 2.0", "control": "PR.AA-01 — identities and credentials are managed" }, { "framework": "SOC 2", "control": "CC6.1" } ], "scanners": [ "Vault audit", "AWS Secrets Manager", "PROWLER" ], "url": "https://beaconstandards.com/catalog/manual-credential-lifecycle" }, { "id": "BCN-T3-IAM-003", "name": "Fragmented Identity Federation", "tier": 3, "domain": "iam", "summary": "Applications with local accounts outside the central identity provider.", "sla": "90 days", "definition": "Applications maintain their own user directories rather than federating to the central identity provider. Each local directory has its own password policy, its own MFA capability or lack of it, and its own joiner-mover-leaver problem that no central process addresses.", "whyThisTier": "Every non-federated application is a parallel identity estate that central controls do not reach — MFA policy does not apply, access reviews miss it, and departing employees retain access indefinitely. Consolidating federation is the highest-leverage identity investment available, but it is application-by-application migration work rather than a configuration change, which places it at Tier 3.", "commonMisclassification": "A non-federated application holding regulated data and lacking MFA is not merely a federation gap — record the MFA deficiency separately at its own tier.", "detection": [ "Inventory applications and record which authenticate through the central identity provider and which do not.", "Cross-reference recent leavers against local application directories to quantify the residual-access problem.", "Identify applications supporting SSO but not configured for it — often the majority of the gap.", "Check for shared local accounts, which defeat attribution entirely." ], "remediation": [ "Prioritise by sensitivity and user population; the widely-used sensitive applications deliver most of the benefit.", "Enable SSO on applications that already support it before undertaking any migration project.", "Make SSO support a procurement requirement so the problem stops growing.", "Add federated applications to the access review cycle and the leaver process.", "Eliminate shared local accounts, replacing them with individually-attributable federated identities." ], "verification": "The application inventory shows federation for all sensitive applications, a test leaver loses access to federated applications automatically, and no shared local accounts remain on in-scope systems.", "mitre": [ { "id": "T1078", "name": "Valid Accounts" } ], "cwe": [], "owasp": [], "compliance": [ { "framework": "ISO/IEC 27001:2022", "control": "A.5.16 — identity management" }, { "framework": "SOC 2", "control": "CC6.1 — logical access" }, { "framework": "NIST CSF 2.0", "control": "PR.AA-01" } ], "scanners": [ "identity provider application inventory", "SaaS discovery tooling" ], "url": "https://beaconstandards.com/catalog/fragmented-identity-federation" }, { "id": "BCN-T3-DAT-001", "name": "No Data Loss Prevention Coverage", "tier": 3, "domain": "data", "summary": "No technical control detecting or preventing sensitive data leaving approved channels.", "sla": "90 days", "definition": "There is no capability detecting sensitive data moving through email, collaboration platforms, endpoints, or cloud storage to unapproved destinations. Includes deployments running in monitor-only mode indefinitely, where alerts are generated but no policy is enforced and no one reviews them.", "whyThisTier": "DLP addresses inadvertent disclosure and low-sophistication insider exfiltration, both real and both common. It is Tier 3 because DLP does not stop a determined attacker — encrypted channels and staged exfiltration defeat it — and because deployment requires substantial tuning to avoid disrupting legitimate work. The value is genuine but the returns are gradual, which is exactly the Tier 3 profile.", "commonMisclassification": "Presented as preventing breach. DLP addresses accidental and casual disclosure; positioning it as an anti-exfiltration control leads to over-investment here relative to Tier 1 work.", "detection": [ "Test whether a benign marker file resembling regulated data can be emailed or uploaded externally without detection.", "Check coverage across channels — email, endpoint, cloud storage, and collaboration platforms are usually addressed unevenly.", "Determine whether existing deployments enforce policy or merely log, and whether the logs are reviewed.", "Confirm detection rules match the data types you actually hold rather than the vendor's defaults." ], "remediation": [ "Start with the channel carrying the highest volume of sensitive data — usually email or a single collaboration platform.", "Deploy in monitor mode first, tune against real traffic, then enforce; enforcing untuned policy generates disruption and erodes support for the programme.", "Align detection rules with the classification scheme from BCN-T2-DAT-003 rather than with generic patterns.", "Route alerts to an owner with a defined triage process, since unreviewed alerts provide no control value.", "Extend to further channels once the first is enforcing cleanly." ], "verification": "A benign marker file matching a defined sensitive data type is blocked or alerted on when sent through each covered channel, and the alert reaches the triage owner.", "mitre": [ { "id": "T1048", "name": "Exfiltration Over Alternative Protocol" }, { "id": "T1567", "name": "Exfiltration Over Web Service" } ], "cwe": [], "owasp": [], "compliance": [ { "framework": "ISO/IEC 27001:2022", "control": "A.8.12 — data leakage prevention" }, { "framework": "GDPR", "control": "Art. 32 — security of processing" }, { "framework": "SOC 2", "control": "CC6.7 — transmission of information" } ], "scanners": [ "Purview DLP", "Google Workspace DLP", "endpoint DLP agents" ], "url": "https://beaconstandards.com/catalog/no-dlp-coverage" }, { "id": "BCN-T3-DAT-002", "name": "Unverified Backup Restoration", "tier": 3, "domain": "data", "summary": "Backups are taken but restoration has never been tested end to end.", "sla": "90 days", "definition": "Backup jobs run and report success, but no restoration has been performed to confirm the data is complete, usable, and recoverable within the stated objective. Includes the absence of immutable or logically-isolated copies, which determines whether backups survive a ransomware event at all.", "whyThisTier": "An untested backup is an assumption. Restoration failures are common and are discovered at the worst possible moment — incomplete application state, missing encryption keys, or recovery times far exceeding the objective. Modern ransomware operators target backup infrastructure specifically, which makes immutability the difference between recovery and payment. Tier 3 reflects that this is preparatory rather than presently exploitable.", "commonMisclassification": "The absence of any backup at all for a critical system is not Tier 3 — that is an immediate business-continuity exposure and should be escalated.", "detection": [ "Ask for the last successful restoration test; job success reports are not evidence of recoverability.", "Confirm at least one copy is immutable or logically isolated from production credentials, since backups reachable with production credentials are reachable by ransomware.", "Check whether encryption keys required for restoration are themselves backed up and independently recoverable.", "Measure actual restoration time against the stated recovery objective." ], "remediation": [ "Perform a full restoration test of the most critical system into an isolated environment, and record the elapsed time.", "Implement immutable backup storage with a retention lock that operational credentials cannot override.", "Isolate backup infrastructure credentials from the production identity plane.", "Ensure key material needed for restoration is recoverable independently of the systems being restored.", "Schedule recurring restoration tests and treat a failed test as a finding rather than as a completed exercise." ], "verification": "A documented restoration test returns a critical system to a working state within the recovery objective, and at least one backup copy is confirmed immutable and inaccessible from production credentials.", "mitre": [ { "id": "T1490", "name": "Inhibit System Recovery" }, { "id": "T1486", "name": "Data Encrypted for Impact" } ], "cwe": [], "owasp": [], "compliance": [ { "framework": "ISO/IEC 27001:2022", "control": "A.8.13 — information backup" }, { "framework": "SOC 2", "control": "A1.2 — recovery of infrastructure and data" }, { "framework": "HIPAA", "control": "§164.308(a)(7) — contingency plan" } ], "scanners": [ "backup platform reporting", "restoration testing" ], "url": "https://beaconstandards.com/catalog/unverified-backup-restoration" }, { "id": "BCN-T3-DAT-003", "name": "Database Configuration Hardening", "tier": 3, "domain": "data", "summary": "Database settings diverging from benchmark without creating direct exposure.", "sla": "90 days", "definition": "Database configuration departs from CIS Benchmark or vendor hardening guidance — sample schemas retained, verbose error messages returned to clients, audit logging disabled, unnecessary extensions or stored procedures enabled, or default ports retained where the benchmark advises otherwise.", "whyThisTier": "These settings determine how much an attacker gains from a partial compromise. Verbose errors accelerate injection exploitation; disabled audit logging removes the record of what was accessed; unnecessary extensions provide privilege-escalation paths. None is exploitable alone, all reduce the effort required once another finding is exploited.", "commonMisclassification": "Benchmark output frequently includes authentication and network-exposure items that are genuinely Tier 1. Triage each item rather than importing the report wholesale.", "detection": [ "Run a CIS Benchmark assessment for the specific database engine and version.", "Confirm error verbosity is suppressed for client-facing responses.", "Check whether database audit logging is enabled and forwarded to central storage.", "Inventory enabled extensions and stored procedures against actual application requirements." ], "remediation": [ "Apply the benchmark to a non-production instance first to identify application breakage before touching production.", "Suppress detailed errors to clients while retaining full detail in server-side logs.", "Enable audit logging for administrative actions and regulated-data access, forwarding to the central store.", "Remove sample schemas, unused extensions, and unnecessary stored procedures.", "Encode the hardened configuration in the provisioning template so new instances inherit it." ], "verification": "A benchmark assessment reports the target pass rate, client-facing errors reveal no schema detail, and audit events appear in central log storage.", "mitre": [ { "id": "T1213", "name": "Data from Information Repositories" } ], "cwe": [ { "id": "CWE-209", "name": "Generation of Error Message Containing Sensitive Information" } ], "owasp": [], "compliance": [ { "framework": "CIS Benchmarks", "control": "database engine benchmark" }, { "framework": "PCI DSS v4.0", "control": "2.2.1 — configuration standards" }, { "framework": "ISO/IEC 27001:2022", "control": "A.8.9 — configuration management" } ], "scanners": [ "CIS-CAT", "Nessus", "OpenSCAP" ], "url": "https://beaconstandards.com/catalog/database-configuration-hardening" }, { "id": "BCN-T3-PRC-001", "name": "Container and Image Hardening", "tier": 3, "domain": "processing", "summary": "Containers running as root, from oversized base images, or without runtime constraints.", "sla": "90 days", "definition": "Container workloads depart from hardening guidance — running as root, built on full operating-system base images carrying substantial unnecessary surface, lacking resource limits, running with unnecessary Linux capabilities, or permitting writable root filesystems. Also covers images without provenance or signature verification.", "whyThisTier": "Container hardening constrains what an application compromise yields. A non-root container with dropped capabilities and a read-only filesystem substantially raises the cost of turning code execution into host access, but none of these settings prevents the initial compromise. The work is also naturally incremental — each image can be hardened independently — which fits the Tier 3 profile of continuous background investment.", "commonMisclassification": "A container running as root does not by itself make an application vulnerability Tier 1, and equally does not reduce one. Record the application vulnerability and the hardening gap as separate findings at their own tiers.", "detection": [ "Scan image manifests for root user, missing resource limits, and unnecessary capabilities.", "Assess base image size and package count; minimal and distroless bases materially reduce surface.", "Run a Kubernetes benchmark (kube-bench) and check whether pod security standards are enforced.", "Confirm images are signed and that verification is enforced at admission rather than merely available." ], "remediation": [ "Add a non-root user to images and set the runtime user explicitly; this is the single highest-value change.", "Migrate to minimal or distroless base images, which reduces both attack surface and vulnerability-scan noise.", "Set resource limits, drop all capabilities and re-add only those required, and mount root filesystems read-only.", "Enforce pod security standards at the namespace level so new workloads inherit the constraints.", "Enable signature verification at admission so unsigned images cannot run." ], "verification": "Running workloads report a non-root user, dropped capabilities, and resource limits; an admission test confirms a non-conforming or unsigned manifest is rejected.", "mitre": [ { "id": "T1610", "name": "Deploy Container" }, { "id": "T1611", "name": "Escape to Host" } ], "cwe": [ { "id": "CWE-250", "name": "Execution with Unnecessary Privileges" } ], "owasp": [], "compliance": [ { "framework": "CIS Benchmarks", "control": "Docker / Kubernetes Benchmark" }, { "framework": "NIST SP 800-190", "control": "container security guidance" }, { "framework": "ISO/IEC 27001:2022", "control": "A.8.9 — configuration management" } ], "scanners": [ "Trivy", "kube-bench", "Grype", "Docker Bench" ], "url": "https://beaconstandards.com/catalog/container-image-hardening" }, { "id": "BCN-T3-PRC-002", "name": "CI/CD Pipeline Hardening", "tier": 3, "domain": "processing", "summary": "Build pipelines without dependency pinning, artefact signing, or runner isolation.", "sla": "90 days", "definition": "The build pipeline lacks supply-chain controls: unpinned dependencies and actions, no lockfile enforcement, unsigned build artefacts, shared runners without isolation between jobs, or secrets available to workflows triggered by untrusted contributions.", "whyThisTier": "The pipeline has production write access, which makes it a high-value target — compromising a build reaches every downstream consumer at once. These controls are Tier 3 rather than Tier 1 because they harden a system that should already be protected by access controls; where the pipeline's credentials are themselves exposed the finding is BCN-T1-IAM-003, and where its console is internet-reachable it is BCN-T1-PRC-002.", "commonMisclassification": "Exposed pipeline credentials found during this work are Tier 1 under BCN-T1-IAM-003 — do not fold them into the hardening item, which would delay rotation to a 90-day SLA.", "detection": [ "Check whether third-party actions and dependencies are pinned to immutable digests rather than to mutable tags.", "Determine whether build artefacts are signed and whether signatures are verified at deployment.", "Review runner isolation — shared runners permit one job to observe another's secrets.", "Identify workflows triggered by external contributions that have access to repository secrets." ], "remediation": [ "Pin all external actions and dependencies to digests, and enforce lockfiles in CI.", "Sign build artefacts and verify signatures at deployment, so an unsigned artefact cannot reach production.", "Use ephemeral runners so each job starts from a known state and leaves nothing behind.", "Restrict secret access by workflow and branch, and deny secrets to workflows triggered by forks.", "Generate and retain a software bill of materials for each build." ], "verification": "A build with an unpinned dependency or an unsigned artefact fails the pipeline, runners are confirmed ephemeral, and a fork-triggered workflow cannot access repository secrets.", "mitre": [ { "id": "T1195.002", "name": "Compromise Software Supply Chain" }, { "id": "T1552.004", "name": "Private Keys" } ], "cwe": [ { "id": "CWE-1357", "name": "Reliance on Insufficiently Trustworthy Component" } ], "owasp": [], "compliance": [ { "framework": "SLSA", "control": "Build track levels 2–3" }, { "framework": "SOC 2", "control": "CC8.1 — change management" }, { "framework": "NIST SSDF", "control": "PS.2 / PS.3 — protect software and artefacts" } ], "scanners": [ "GitHub Actions audit", "Trivy", "Syft", "Cosign" ], "url": "https://beaconstandards.com/catalog/cicd-pipeline-hardening" }, { "id": "BCN-T3-PRC-003", "name": "Infrastructure-as-Code Security Gaps", "tier": 3, "domain": "processing", "summary": "Infrastructure defined in code without security scanning, policy enforcement, or drift detection.", "sla": "90 days", "definition": "Infrastructure-as-code templates are not scanned for misconfiguration before apply, no policy-as-code gate blocks non-conforming changes, and no drift detection identifies manual modifications made outside the code path.", "whyThisTier": "This is the highest-leverage preventive control available for cloud misconfiguration: a policy gate in the pipeline prevents the entire class of findings that otherwise arrives as Tier 1 public storage and open security groups. It is Tier 3 because it prevents future findings rather than remediating current ones — its value is measured in the Tier 1 items that never get created.", "commonMisclassification": "Existing misconfigurations discovered by newly-enabled IaC scanning are separate findings at their own tiers. Enabling the control and clearing its backlog are distinct pieces of work.", "detection": [ "Check whether IaC scanning (Checkov, tfsec, Terrascan) runs in the pipeline and whether it blocks or merely reports.", "Determine whether policy-as-code gates exist for high-risk resource configurations.", "Run drift detection against deployed infrastructure to quantify manual changes.", "Identify infrastructure not defined in code at all, which no gate can protect." ], "remediation": [ "Add IaC scanning to the pipeline in reporting mode, fix the existing backlog, then switch to blocking.", "Write policy-as-code rules for the configurations that produce Tier 1 findings — public storage, unrestricted ingress, unencrypted volumes — and block them at apply time.", "Enable drift detection and alert on out-of-band changes.", "Bring undefined infrastructure under code management, prioritising production.", "Apply preventive guardrails (service control policies, Azure Policy) so the control holds even when the pipeline is bypassed." ], "verification": "A test pull request introducing a public storage bucket is blocked by the pipeline, drift detection reports on a deliberately-introduced manual change, and preventive policy denies the same change made directly in the console.", "mitre": [ { "id": "T1578", "name": "Modify Cloud Compute Infrastructure" } ], "cwe": [], "owasp": [], "compliance": [ { "framework": "NIST CSF 2.0", "control": "PR.PS-01 — configuration management" }, { "framework": "ISO/IEC 27001:2022", "control": "A.8.9 — configuration management" }, { "framework": "SOC 2", "control": "CC8.1 — change management" } ], "scanners": [ "Checkov", "tfsec", "Terrascan", "PROWLER" ], "url": "https://beaconstandards.com/catalog/iac-security-gaps" } ] }