Bad Security is Debt, and You’re Paying for it.
Security compliance is often of least concern when it comes to “getting things done,” especially for small to medium sized businesses. However, choosing to put it off or planning to go back and fix it later when the business is more mature is quite the same as paying with credit; the interest is very high, you will pay for it eventually, and the longer you wait, the more it’s going to cost you.
“An ounce of prevention is worth a pound of cure”
Instead, create environments with guardrails. IAM roles should contain policies with least privilege. Infrastructure and applications should be deployed via pipelines and code. Certain actions can and cannot be allowed to take place based on the permissions set forth. If you disallow bad practices from the start in your environments, then there never needs to be the dreaded ‘go back and fix it’ step.
Think of this as ‘short feedback loops,’ meaning a developer can try something, and if it’s not allowed by the compliance policies they can try a different method. A dev team would never be asked to write a whole project without ever debugging or compiling, or told to save debugging and rebuilding until final delivery. So, why are these things done in the cloud for infrastructure and security? The term ‘Security on Rails’ is somewhat apt - there’s only one way forward, it’s easy to ride along on, and you can’t make a wrong turn.
Which debts get paid first?
This is where AWS Security Hub comes in. Think of it as a ‘single pane of glass’ that ties together other AWS security services and third party solutions. It enables you to configure, control, and monitor the state of one or many AWS accounts. This eliminates the need to skip around between various service consoles to track and control security. Best of all, it tells you what’s wrong, how many problems there are in total, and prioritizes severity for you. This makes it easy to knock out the worst flaws in smaller pieces, sort of like paying off high-interest loans first.
If you’re not familiar with Insights, they’re useful ready-made compliance rules such as, ‘AWS users with suspicious activity,’ ‘Credentials that may have leaked,’ and the ever present ‘S3 buckets with public write or read permissions.’
What about more complex compliance needs? How do we safely store, process, or transmit cardholder data? What if you don’t know which rules are part of a ‘Best Practices’ foundation? Remember that too much unnecessary security can cause friction for developers. This in turn reduces their velocity and costs your team more working hours fighting inefficient controls. This not only makes developers deeply annoyed and dissatisfied, but it wastes money and time in all aspects of the business.
The Goldilocks of Security Controls
This panel displays how closely your current environment comes to meeting different frameworks. The inclusion of the PCI DSS v3.2.1 is extremely important for those who need to handle credit cards, and CIS is a gold standard in security benchmarks. This means you don’t have to know everything about compliance in order to get it right, which is a huge time-saver that makes doing the right thing easy.
Dig down into the findings to get an idea of their severity.
The summary screen shows when the standards were applied and tracks the severity of findings over time. This is a great way to show how an environment is becoming more compliant and safe over time. You can also visit the “Findings” section to get a more detailed view of each rule, the non-compliant resources, and a Severity score.
What about 3rd party tools?
What if I wanted to easily move these findings to a SOC or SIEM? Or what if I wanted to make Slack notifications based on events? Or if we run VM vulnerability management tools like Rapid7?
Good news! There are a huge number of supported services that integrate right into AWS Security Hub. This means the findings from a 3rd party scanner can be brought in and just as easily used to make notifications in Slack and/or send event alerts to Splunk. For a full list of native AWS and 3rd party integrations, you can visit the AWS Security Hub Documentation here.
All of these findings are useful for compliance, but ‘to err is human.’ What if the non-compliant resource is discovered but then left without remediation? What if there’s an issue when someone isn’t watching? How can we quickly and automatically correct findings? Just fix it!
This is where custom actions come in. By giving the action a name, a description, and a custom ID, you can set actions up to fire based on the related findings. You can then create a Lambda function to perform any action desired based on the finding. This could remediate public buckets for example, or kick off any myriad of actions an organization needs in reaction to a finding.
Alternatively, you can leverage the AWS Config integration for Security Hub, but note that it’s quite a few more steps and not a direct feature of Security Hub. It also does not allow for such open-ended actions as we have with Lambdas and Security Hub. Nevertheless, if you’re interested, you can find more information on AWS Config Auto Remediation here.
To recap, Security Hub:
- Collects findings from a variety of tools, including AWS and 3rd party.
- Prioritizes findings by severity to allow for prioritization.
- Provides a single location to view the status of all environments and resources.
- Automatically checks both existing and new resources.
- Can automatically remediate in a highly customizable fashion.
- Integrates well with outbound alerting systems for NOC, SOC, SIEM, or even Slack.
- Offers ‘best practice’ one-click security framework evaluations of your environment.
Go give Security Hub a look - you may very well find a few ugly skeletons hidden around the place. Just don’t forget: The debt will always be paid - either by fixing the flaws now, fixing even more flaws later, or by fixing all the flaws after it’s too late, potentially following a security breach. Stay safe out there!