Most AWS security tools are pretty good at telling you when something is misconfigured.
An open security group, an overly permissive IAM policy, a publicly accessible resource. These are all things we know how to detect.
But there's a part of the process that doesn't get nearly enough attention: what happens when someone actually tries to fix the problem?
Take something as common as a security group allowing SSH access from 0.0.0.0/0.
Your security scanner flags it, and the recommendation is to remove the rule.
Fair enough.
But what if that security group is attached to multiple production instances? What if someone still uses that connection for maintenance? Or what if the rule was created through Terraform, and removing it manually means it'll be back after the next deployment?
Suddenly, a simple security finding requires a much bigger investigation.
And that's assuming you even know which resources are affected.
You can start by checking the network interfaces associated with the security group:
aws ec2 describe-network-interfaces \
--filters Name=group-id,Values=sg-0123456789abcdef0 \
--query 'NetworkInterfaces[].{
Instance:Attachment.InstanceId,
PublicIP:Association.PublicIp,
Description:Description
}' \
--output table
That gives you some useful context, but it doesn't answer everything.
Just because a resource uses a security group doesn't mean it depends on every rule in that group. And just because you haven't observed traffic doesn't mean that traffic isn't important.
There's also a difference between a security group allowing public access and a resource actually being reachable from the internet.
You need to look at routing, public IPs, load balancers, and the surrounding network configuration before making that determination.
This is where security investigations start taking time.
The interesting question isn't always how to fix a finding. It's how much you actually know before making the change.
That's something we've been thinking about while developing KULTARR.
We're building an AWS security investigation platform, and one of the areas we're focusing on is understanding the potential impact of remediation.
Not just identifying which resources are involved, but helping engineers understand what a proposed change might affect and where the available evidence is incomplete.
We also believe there's value in being able to say, "We don't have enough information to determine that."
It's a lot better than presenting a confident recommendation that turns out to be wrong.
KULTARR is still under development, and we're working through these problems as we build it.
We're curious how other teams approach this.
When you're dealing with security findings in production AWS environments, how much of the investigation happens inside your security tools, and how much still involves manually going through AWS?
Top comments (0)