Harden security groups and restrict ingress

Security groups are free, and tightening a rule changes nothing on the AWS bill. Every control in this group remediates at zero AWS cost, which removes the cost-versus-benefit trade-off entirely; the only question is whether someone is accountable for getting it done. The risk these controls track, by contrast, is the single most common root cause of cloud breaches: an administrative or data-tier port left open to the internet, found by automated scanners within minutes and brute-forced or scraped.

Frame each failing rule by what is behind it, not by the count. An open SSH port on a throwaway test box is a different item from an unauthenticated Redis cache or a production database reachable from 0.0.0.0/0. Map the failures to the data and prioritise by exposure. A useful early signal that an exposed data-tier port is being abused is an unexplained spike in egress charges, which often shows up on the bill weeks before a breach is confirmed.

The insurance maths is one-sided. The remediation is minutes of engineering time per rule plus a one-time pass to strip default groups, against the documented cost of a breach: incident response, regulatory fines, breach notification, and the cyber-insurance questionnaire that asks, pointedly, whether remote administrative access is restricted.

Priya is the GRC and finance partner sitting in on the security cadence. The posture dashboard shows a cluster of open-port findings spread across a recently acquired account: open SSH on several groups, an exposed Redis and Elasticsearch tier, and 47 default security groups carrying stock rules. Her first reaction is not to ask how much the fix will cost, because she already knows the answer is nothing. Security groups are free, and revoking a rule changes no AWS line item. Her question is which of these failing rules sits in front of regulated or customer data, because that is what decides expected loss.

The team maps each failing rule to what is behind it. The open Redis on 6379 and Elasticsearch on 9200 front internal data with no authentication, so Priya weights them as the highest expected loss on the board: a low annual probability of a serious incident multiplied by a six or seven figure impact still dwarfs almost every cost line on the report. The open SSH rules she ranks next, and the default groups she treats as a single hygiene sweep. Her output for the finance pack is one line: there is no spend to approve, the items are ordered by the sensitivity of the data each rule exposes, and the close-out criterion is a preventive guardrail rather than a one-time cleanup, because a finding that recurs is exactly the posture that fails an audit at the worst moment.

These findings carry no monthly dollar figure, which is precisely why they are easy to under-prioritise on a cost-led dashboard. The right way to size them is expected loss: a low annual probability of a serious incident multiplied by a very high impact, against a remediation that costs essentially nothing. Even a small probability against a six- or seven-figure impact dwarfs almost every line on the cost report, and the fix has zero bill impact, so there is no cost trade-off to weigh.

The compliance and insurance exposure is concrete and recurring. A persistent count of open admin or data-tier ports is the kind of thing that raises a cyber-insurance premium, triggers an audit exception, or stalls a customer security review. The finance role is to attach expected loss to each failing rule by the sensitivity of the data behind it, to treat recurrence rather than the snapshot count as the real signal, and to insist the close-out criterion is a preventive guardrail, not just removal, because cleanup-without-prevention is exactly the posture that fails an audit at the worst moment.

These findings ask one question across all your firewall rules: was every open door opened deliberately, and is it scoped to who actually needs it? An administrative port (SSH, RDP) or a data-tier port (a database, a cache, a queue) reachable from the open internet is the classic, low-cost-to-fix root cause behind a long list of cloud breaches.

The leadership question is not "is it fixed this quarter?" but "what stops it from coming back?" This is the finding famous for recurring: cleared one quarter, back the next, because the work was a cleanup rather than a guardrail. A finding that returns is a sign the organisation is patching symptoms; a preventive control that blocks the open rule at creation is the sign it is solved.

None of this is a cost decision. Closing and scoping security-group rules is free in AWS terms. It is a discipline-and-governance question about whether exposure is prevented by design or only by everyone remembering not to make a mistake at 2am.

After a partner security review stalled on a single question, whether any administrative or data-tier port faced the open internet, the CTO asked the platform team a blunt follow-up: not are we clean today, but what stops an open rule from coming back. The honest answer was that the previous cleanup had cleared the finding one quarter and watched it return the next, because the work had been a manual sweep rather than a control. Someone opened SSH to 0.0.0.0/0 during a 2am incident, and nobody closed it.

The response was to treat the whole cluster as one capability and to make prevention the close-out criterion. The backing AWS Config rules went on as detective controls, and a Service Control Policy was added to deny authorize-security-group-ingress for the open patterns: port 22 or 3389 from 0.0.0.0/0, and any rule on a default group. A quarter later the partner review reached the same question and the answer had changed from we cleaned it up to the open rule cannot be created in this organisation. That shift, from vigilance to a guardrail, is the signal that belongs on a board risk report rather than the raw finding count.

There is no dollar amount on these items, and that is the point: they are tracked because an open administrative or data-tier port is one of the most common root causes of cloud breaches, and the fix is effectively free. The asymmetry, near-zero cost to close and potentially catastrophic cost if exploited, makes it a clear priority regardless of how small the count looks.

What the number really measures is discipline. A persistent or recurring count means open ports and untouched default groups are reaching production without anyone catching them, and the same process gap almost certainly applies to other controls that will not surface as cleanly. The leadership move is to require that the fix is preventive, a guardrail that blocks the open rule at creation, and to set the norm that administrative and data-tier ports never face the public internet.