Having a centralized tool has many benefits. The most important one? Your team won’t have to cycle through several applications to manage dozens, if not hundreds of security alerts every day. It helps them to keep an overview and they will be less likely to miss anything important. You can even set up automated checks!

There are just a few things you need to keep in mind: the AWS Security Hub does not offer multi-region tracking at this time and only supports the following standards:

• CIS AWS Foundations
• AWS Foundational Security Best Practices
• Payment Card Industry Security Standard

If these current limitations are not a hang-up and if the AWS Security Hub fits your needs, it is an excellent and easy-to-set-up tool that will help you take control of your cybersecurity.

I’m ready to go. Where do I start?

When you start using AWS Security Hub, you will most likely be bombarded with alerts. It can be overwhelming, so a structured approach is essential when starting to tackle these issues. 

People seem to have a natural desire to annihilate their to-do lists and to reach a score of 100% as soon as possible. And while that may look good, it will impact your judgment if you let it.  

Instead, realize how important it is to have all this information neatly centralized in one tool. It’s perfectly fine to score less than 100%, as long as you are aware of all issues and create a timeline in which to tackle them. 

An example policy could be:

• Critical: resolve within 1 month
• High: resolve within 3 months
• Medium: resolve within 6 months
• Low: resolve within 12 months

Focus on one standard

It is counter-productive to try and deal with all standards at the same time. Is the PCI standard relevant to your business? No? Then leave it unchecked. 

Of all the standards you do have enabled in the AWS Security Hub, open the one with the worst score (spoiler alert: this is usually the CIS standard).

Once you are satisfied with the standard that requires the most work, you can look into any other standards in need of your attention.

First things first

Let’s start at the beginning. When you select the second tab in the app, you will only see “failed” controls. By default, this list is sorted by severity, with the most critical issues on top. 

Let’s focus on the Critical and High severity findings first. After that, you can work on the Medium and Low findings.

To successfully deal with security findings, follow these steps:

1. Read and understand what the finding is about. Follow the link to the AWS documentation for more details. Find out how many resources it affects (you will find this in the last column) to get an idea of the size, risk, and work to be done.
2. Decide on your next action and set the workflow status accordingly:
   1. Remediate (let me do it)
      Each finding description offers a link to documented remediation instructions. Once resolved, the finding will clear automatically after some time. Do you want it gone sooner? Sure thing. You can set the workflow status to “resolved” to clear the view immediately.
   2. Notify (not my problem)
      This workflow status is convenient to keep track of findings that are not your direct responsibility, but are of interest to you. You will still have to hand over the work to the right person, but it’s a nice way to stay in the loop.
   3. Suppress (shut up)
      Don’t overuse this one! Its purpose is to disable a check for a given resource. Be aware that if you ever disable and enable a standard again, the suppressed findings are reset. You should only use suppress when the check really has no added value for your situation.
      
      You could also completely disable a specific control for all current and future resources. It comes with a text field where you can enter the reason for disabling, which is very interesting for future reference.
      
      Why would you suppress a finding indefinitely? Here’s an example: if your company follows the CIS level 1 standard and only works with virtual MFA devices, control 1.14 (hardware MFA on root) is not necessary – as long as you do have virtual MFA on your root account. In that case, you can disable control 1.14.

Time to think ahead 

While it’s smart to look at the Critical and High severity findings first, it is possible that there are lower severity findings that pose a higher risk to your specific situation. 

Rifle through all findings to see if anything stands out. Look for findings that relate to your most critical instances first, for example. Guard Duty detected suspicious behavior? Investigate!

Lower severity findings typically come in a high number of similar or related issues. In many cases, these can be remediated with a rather low effort.

For example, you may receive dozens of findings about password requirements, one for each user. These can all be solved by applying an IAM password policy. MFA can be enforced through policies.

A missing CloudWatch configuration is another common cause of findings. You can deploy this script to configure the necessary metrics and alarms.

Last but not least

Once you have everything under control and your score reached a value to be proud of, you’re not done. Security never is.

Do you have all relevant standards enabled? Do you get recurring findings? Can you automate things? Did you suppress valid findings? Do you receive new findings each time you deploy new resources? Any 3rd party tools you can integrate with Security Hub?

As you can see, you can’t rest on your laurels when it comes to security. While a solid, centralized tool is half the battle, we also need you to stay on your toes. Good luck!

The post Security Hope appeared first on Cloudar.