Post Syndicated from Aaron Wells original https://blog.rapid7.com/2021/07/06/automated-remediation-level-4-actual-automation/
Let’s get to automatically remediating already!
This entry will be the last in our series based on The 4 Levels of Automated Remediation. After the previous 3 steps—where we discussed everything from logging to best practices to account hygiene—it’s time to talk about the actions that really let you calibrate and control the kind of remediation you’re looking to get out of the process. We’ll once again use AWS as our case study and jumping-off point for keeping your cloud environments clean and (as) free (as possible) of misconfigurations at this “classic” level of automated remediation.
Key off on APIs
Deactivate them. If they’re old, that is. Since API keys essentially authenticate traffic for 2 things that really need to talk to each other, it’s a good rule of thumb to regularly and continually “rotate” your API keys so that anyone—or anything—with malicious intent is kept guessing. This is probably the most obvious hygiene action we’ll discuss here. The AWS Secrets Manager platform enables:
- Creation and protection of “secrets” that manage API keys
- Rotation of API keys
- Auditing of credential rotation for your cloud resources
- Scheduled/automatic rotation of keys, aka secrets
Delete the nondescriptors
Those newly provisioned Security Group (SG) rules may not have a description. Why would that be? When found, it doesn’t really matter. They’re liabilities and they should be deleted. SG rules allow you to really get into the fine-grained nitty gritty of control over the traffic moving in and out of instances on your cloud infrastructure.
If an SG rule is indeed newly provisioned and lacks a descriptor, odds are it isn’t a priority and workflow isn’t dependent on it. Security Group rules are supposed to simplify operations, so if it does the opposite of that by being a mystery, then simplify it by getting rid of it.
Tear up the untagged
More to the point, it’s another good hygiene rule of thumb to delete instances that aren’t properly tagged. The whole point of tagging, much like adding descriptions, is to quickly categorize and find all of your many resources. Thus, if something isn’t tagged as it should be or you stumble upon an instance that is wholly untagged, then it’s time for it to go. But as stated in this AWS tagging guide, you must be specific about your deletion process:
You can’t terminate, stop, or delete a resource based solely on its tags; you must specify the resource identifier. For example, to delete snapshots that you tagged with a tag key called DeleteMe, you must use the DeleteSnapshots action with the resource identifiers of the snapshots, such as snap-1234567890abcdef0.
Privatize public buckets
As AWS also states, new S3 buckets do not allow public access. However, much like the context surrounding the suggestions above, somewhere along the way public access was granted for one reason or another, and vulnerabilities were created. So here’s another good hygiene rule of thumb: zero out Access Control Lists (ACLs); they’re what you would use to grant public access to buckets. It’s also a good idea to activate all “block public access” settings.
Ready to rock (automated) remediation?
If your team is ready to activate automated remediation, good for you. Learning all 4 levels of automated remediation will also allow your organization to gradually become acquainted with the process and ultimately strengthen your cloud security.