Disable insecure access modes and protocols

Insecure access modes are a common source of accidental exposure, and almost every control in this group costs nothing in AWS spend to fix. Deleting a root key, closing an EKS endpoint, removing a wildcard from a function policy, disabling ACLs on a bucket or switching a Transfer server to SFTP does not change your bill. The cost sits in the few legitimate exceptions: a genuinely public endpoint that needs a controlled front door, or a partner integration that needs a graceful protocol migration.

Frame each failing control as a line on the risk register rather than a compliance checkbox, and weight by the data behind it. A root access key carries unbounded, account-wide exposure; a public Lambda fronting a database carries both a breach risk and a runaway invocation bill; an FTP server moving customer files is a PCI exposure. A test-box default is far lower. Map the failures to what they expose and prioritise by that, not by the order the report lists them.

The insurance maths is one-sided. The remediation is engineering time plus a small, bounded migration for the legitimate exceptions. The downside of leaving it is the documented cost of an accidental-exposure breach: regulatory fines, breach notification, forensics, legal fees and stalled audits or deals when an open finding fails a customer security review.

Priya, the finance partner at a scale-up heading into its first SOC 2 audit, opens the security pack and finds insecure-access failures spread across IAM, EKS, Lambda and Transfer Family in three older accounts. Her instinct is not to ask what the fix costs, because she already knows the answer is almost nothing in AWS spend: deleting a root key, closing an EKS endpoint, removing a wildcard from a function policy and switching a Transfer server to SFTP all leave the bill unchanged. Her job is to make sure the team works them in the order that retires the most liability first.

She asks for the inventory weighted by what each mode actually reaches, not by the order Security Hub printed them. The root access key (IAM.4) sits at the top with unbounded, account-wide exposure that no other control can contain, so it is the first item and there is no acceptable non-zero count. Next come the public Lambda function fronting a database, which carries both a breach risk and an uncapped per-invocation bill an attacker could run up over a weekend, and the FTP server moving customer files, which is a live PCI exposure. The test-box defaults drop to the bottom. The only line that needs real money is the partner integration that must keep working through a graceful protocol migration, which she books as a small, bounded one-time piece of engineering rather than letting it block the free fixes.

The cost model here is asymmetric in a way that is rare for security work. Closing insecure access costs nothing in AWS spend, and leaving it open creates an unbounded tail risk. Each failing control is a mode where a future accident or compromise could expose what it reaches, and the worst of them, a root key or a public function fronting customer data, has no acceptable non-zero floor.

Two of these controls also touch the bill directly, which most security findings do not. A public Lambda function open to the internet bills per invocation with no cap, so an attacker or scanner can convert the exposure into a four- or five-figure surprise charge in hours. That makes this capability one a CFO should care about on cost grounds alone, not just risk.

The documented cost of an accidental-exposure breach includes mandatory notification within tight regulatory windows, forensics and legal fees that routinely run into six and seven figures, and customer churn. Against that, the remediation is engineering time plus a bounded migration for the few legitimate exceptions. The finance role is to attach expected loss to each failing mode so the work is prioritised by what it exposes, not by the order the report lists it.

Insecure access is the category of risk that turns a default nobody chose into a headline. A master credential that bypasses every control, a cluster open to the internet, a function anyone can invoke, a file pipe moving data in clear text: each is one bad moment away from exposure, and the report shows them as a scatter of separate findings across many services.

The leadership question is not whether we are compliant today; it is whether access is granted on purpose, to identified callers, or whether it leaks through defaults and legacy modes nobody revisited. The defensible end state is that insecure modes are prevented by policy, with the small number of genuinely necessary exceptions routed through a controlled, authenticated front door.

None of this is a cost decision. Closing insecure access is free in AWS terms. It is a governance decision about whether reach is granted deliberately or only by everyone remembering not to take the easy default.

The leadership team learned the shape of this risk from an audit calendar rather than a breach. A readiness scan showed that the accounts carrying the most business risk were precisely the ones still running insecure defaults: a root access key that bypasses every guardrail, a Kubernetes endpoint open to the internet, a function any AWS principal could invoke, and a file pipe still moving data in clear text. None of it had been chosen; each had simply been left at the easy default while the world around it moved on.

The response was to stop treating each red finding as a separate chore and to set one governance line: access is granted deliberately, to identified callers, or it is closed. The small number of genuinely necessary public paths get a controlled, authenticated front door; everything else is turned off, and a Service Control Policy makes the worst modes impossible to recreate. Because none of this is a cost decision, the only thing leadership had to weigh was whether reach should depend on everyone remembering not to take the easy default, or on a policy that closes the door by design. The signal at the review is no longer the finding count but whether insecure access can still appear by accident.

Nearly every major cloud breach that involved exposed access came back to the same root cause: a mode that could be left open or insecure was left that way by default. Disabling insecure access modes is the control that makes that root cause structurally difficult, and the preventive guardrails, an SCP against root keys, private-by-default clusters, FTP blocked at creation, make it close to impossible.

The cost of getting this wrong is large and well documented, while the cost of fixing it is essentially engineering time. This is the rare class of control where the risk of inaction is severe and the cost of action is small, which is exactly the trade leadership should be quickest to approve, and quickest to make permanent with a guardrail so the same finding cannot reappear one ticket at a time.