Remember how Mirai exploded in 2016 because so many IoT cameras kept default passwords and exposed telnet (port 23)? From a risk lens, that single control failure created systemic exposure — what other tiny misconfigs have you seen drive outsized incidents, and which one mitigation would you prioritize first?
Your 2016 “port 23” callout reminds me of a case where one AWS IAM role had a wildcard trust (Principal: *) and an external account walked right into prod — one line, huge blast radius. If I had to pick one fix first, I’d enforce org-wide guardrails that block wildcard principals and auto-flag risky trusts before deploys (IAM Access Analyzer). Not in AWS?
Quick example: saw a fleet wiped in 2017 because MongoDB was exposed on 27017 with no auth — ransom note in every DB (https://www.mongodb.com/blog/post/important-reminder-configure-access-control-and-enforce-authentication). If I had to pick one fix, I’d enforce default‑deny inbound at the org level (no 0.0.0.0/0 to infra ports), and only allow ingress via an approved ALB/VPN. , small caveat: you still need continuous external scans to catch drift — do you run attack surface checks?