9 best practices for AWS Security Hub you should know
Best practices are one of the best inventions in architecting and developing environment or apps. When it comes to finding the right answer to our problem AWS has prepared sets of best practices in many different fields covering hundreds or even thousands of topics related to their cloud.
One of the most interest I get close to is security. As a DevOps and Solutions Architect, I need to know all the required nuances to keep my client satisfied and secure. Let’s focus on one of the youngest services from AWS.
AWS Security Hub
AWS Security Hub is a tool that provides comprehensive insight into AWS security and compliance with safety standards and best practices, in which we will deep dive into in a minute. AWS Security Hub is dedicated primarily to clients processing and analyzing large amounts of data, especially those with high confidentiality status. Thanks to its diversity and adaptability, it’s an ideal solution for companies operating in areas such as Big Data, SaaS or E-commerce.
More you can find on LCloud’s blog, where my team has prepared an article and infographic on AWS Security Hub.
Let’s dive into the best practices, shall we?
First thing you need to do is to continuously monitor all regions across all of your AWS accounts. That’s why you should use the AWS Labs script to turn on Security Hub to establish your existing Amazon GuardDuty master/member hierarchy. It’s no new recommendation from AWS, it’s suggested when using such services as AWS Config and AWS CloudTrail. And AWS even take care of helping you to automate the process by adding the script to AWS Labs.
Next thing is to check whether AWS Config is turned on and recording all supported resources, as well as the AWS CIS standard checks, are enabled by default. This allows you to monitor all important security measures.
The third thing to stick to is to use specific managed IAM policies for different types of Security Hub users. By that I mean to give your employees the permissions they need to get started. These policies are already available in your account and are maintained and updated by AWS, but a good thing to do is to create our own customer-managed policies.
Fourth is tags. Tags for access control and cost allocation. A simple example is that tags such as developer or DevOps associated with specific team members ( IAM entities) who will have access to your resources can manage and make changes to them.
The fifth are the integrations. You can choose from over 30 integrations of AWS Security Hub with other AWS services, services of third-party suppliers and the ability to customize your own solutions. Security Hub is the one that normalizes and unifies all results from integrated tools.
Sixthly, create remediation playbooks using AWS services. This will allow the security team to focus on strengthening the security of AWS environments, rather than repairing current arrangements.
Another important thing to remember is to create custom actions. Thanks to the integrations mentioned above and the ability to send AWS Security Gub findings to a resource that is external or internal to your AWS account, it allows you to increase visibility and remediation of findings.
Eight best practice is connected with the insights, and more specifically “manager insights”. They can be used as templates and help prioritize resources and findings to act upon. The ability to modify queries and set them as new insights allow you to provide even better visibility to your AWS accounts.
The last, but not least is to try a trial version in practice. Security Hub provides a 30-day free trial for all AWS accounts and regions. The trial is a good way to evaluate how much Security Hub will cost, on average, to monitor threats and compliance in your environments.
To sum up, AWS Security Hub is one hell good tool, which levels up your safety by allowing us to have more visibility into security status and compliance. It’s quite a big help for your security officers or department for recovery than detecting new threats/intrusions/incidents.
More info you can find in the AWS’ documentation or directly on AWS Security Hub forum.
