I gave a presentation titled "Understanding from the Basics! How to Think About and Delegate AWS Security Operations"

Hello, this is Usuda.

Everyone, are you doing AWS security operations? (Greeting)

This is an explanation of the content I presented at the event Freedom from Dependence on Individuals! How to Build Continuously Running AWS Security Operations.

Materials

Event Overview

In AWS security operations, we hear many voices saying that although they have introduced Security Hub and GuardDuty, they cannot keep up with reviewing findings, determining priorities, and taking action.

There are so many alerts that they cannot review and judge them all, so they get put off
A limited number of staff members handle security responses in parallel with their daily AWS operations
They have not been able to sufficiently advance monitoring and governance enhancements after introducing AWS Organizations / Control Tower
Response procedures and decision criteria depend on individuals, so operations tend to stall when personnel change
In this webinar, Usuda, who holds the title of AWS Security Hero, will explain "what operational monitoring should ideally look like" in response to these challenges, and organize the common "time" and "talent" barriers in AWS operations.
We will also introduce the mechanism of the "Comprehensive Cloud Security Operations Support Service," which provides end-to-end support from assessment, design, and implementation to operations, along with actual case studies.

Don't try to handle everything in-house—entrust what can be entrusted to others——
This session lets you explore best practices for AWS security operations that suit your own company.

Session Overview

"I want to do security properly! But where should I start?" I often receive consultations like this.
Security covers a wide range, and it is a domain that is very difficult for a single person to consider and handle. Furthermore, security measures are not something you do once and finish; you need to operate them continuously to maintain a secure state. In this session, I will explain from the basics of AWS security, and clearly describe how to keep your AWS environment secure and how Classmethod can support your AWS security operations.

Explanation

Later

Q&A

I will answer the questions we received during the webinar.

When allowing access from another organization's AWS account to resources in our own organization's account, which is the best practice: (1) cross-account access using an IAM role, or (2) using access keys? For (1), I am concerned because we would need to share our AWS account ID with the other organization.

Option 1 is recommended. If you create access keys with method 2, permanent keys are issued, and if they are leaked, they can be abused immediately.

On the other hand, cross-account access using an IAM Role allows access with temporary credentials only, as long as MFA and security management are properly applied on the partner organization's AWS, which increases security resilience. Sharing an account ID itself is not a security problem, so the appropriate policy is to avoid the use of dangerous access keys.

I understand that using the AWS Security Hub CSPM security standards can cover general compliance rules (controls). In that case, I wonder, "Is there no need to deliberately configure compliance rules on the AWS Config side?" Is this thinking correct? (It seems like checks are duplicated between CSPM and Config.)

Yes, basically that is correct. AWS Security Hub CSPM internally uses AWS Config to set up rules, so you can leave all the general security rules to it. On top of that, when you develop your own company-specific rules, you can use individual AWS Config rules; that order of thinking is fine.

The more security measures you implement, the more the cost increases. As a best practice for security measures, which is more appropriate: "strict → loose" or "loose → strict"?

Balancing with cost is very difficult, but protecting costs and protecting the business is also security measures in a broad sense.

It is hard to say categorically which is better or worse, but one way of thinking is to choose according to your organization's culture.

For example, if there are many engineers doing AWS and application development and their security levels vary, and you judge that leaving everything to each person's self-direction tends to lead to collapse, start from the strict side. If it is an organization where self-direction works well, you can take a strategy such as starting loose and building up rule development step by step.

There are so many Config and CloudTrail notifications that we can't review them all. Is there a good countermeasure?

For AWS CloudTrail/AWS Config, you basically do not need to follow the logs directly. Just storing them is fine. Amazon GuardDuty and AWS Security Hub CSPM take on the role of using those logs and detections to make security judgments, so it is fine to look at their results.

There are many Inspector findings, and I'm unsure how to proceed. As with Security Hub, should I start by organizing them based on categories, severity, etc., and deciding on a response policy?

Inspector detects everything registered as a vulnerability, so as you say, it is a difficult area to handle. First, as a broad policy, update anything for which a patch is provided as much as possible, which steers toward reducing the volume of findings and lowering risk. For those that are difficult to handle through package managers (those requiring individual version upgrades) or for which no patch exists at all, you need to investigate and make judgments. For these, you should raise the priority of those that are especially Critical and already being exploited, and consider them including mitigation measures.

After setting up Inspector and GuardDuty with EventBridge, we received a huge number of emails. It is currently stopped. I want to resume it and configure it so that a flood of emails is not received. Specifically, what should I do?

There are many cases where enabling notifications immediately after enabling security services results in a flood of them. It is better to first work through and resolve the findings, then add notifications.
Let's check the findings one by one and resolve them!

We have set up a mechanism to notify member accounts of some specific Security Hub rules. Is there a best practice for the timing and frequency of reviewing the rules?

The rules on the AWS Security Hub CSPM side basically do not change, so no review is needed due to rule changes.

If everything from notification to remediation is running without problems, there is no need to review that part directly, but if the detection frequency is high, it would be good to also work on reducing detections themselves by establishing operational rules and the underlying design policy as guidelines so that incorrect configurations do not occur.

I am interested in AWS security operations support. We operate multiple AWS accounts with Classmethod's Flat-Rate Discount Plan v2 and Organization Management Plan v2. Is it easier to receive support or are there restrictions depending on the plan?

The two plans you mentioned differ in whether the customer can directly use AWS Organizations or not, but basically support related to AWS security operations can be provided under both. Using AWS Organizations has the advantage of making it easier to roll out and aggregate security settings in bulk, but even if you cannot directly use AWS Organizations, you can do similar things with CloudFormation StackSets and so on, so it is not a major constraint.

So far I have only used the old Security Hub (now CSPM), but since CSPM has many items, I wonder whether it would be better to also use the new Security Hub and judge based on combined risk rather than using CSPM alone. What do you think?

If you use the new AWS Security Hub, in addition to AWS Security Hub CSPM, it can evaluate combined risks based on information collected from Amazon GuardDuty, Amazon Inspector, and others, visualizing higher-priority issues so you can address them.

However, when responding, it is the same as addressing what was detected in each service as before, so it is not necessarily a required service.

Because it also incurs additional cost, you may not feel much need for it if operations are running well with each service on its own. As a guideline, the benefits of using the new AWS Security Hub are greater if you want to prioritize and address the many notifications even at additional cost, want to find more serious issues easily, or want detailed response procedures.

When enabling AWS Security Hub CSPM, you select the security standards to enable. Is there a recommendation? By default, "Enable AWS Foundational Security Best Practices v1.0.0" and "Enable CIS AWS Foundations Benchmark v1.2.0" are checked.

You only need to enable "AWS Foundational Security Best Practices v1.0.0." CIS is the default for historical reasons, but it is not needed in normal environments.

For the remaining security standards, use them only if your company utilizes those standards.

Currently we perform security checks with Trusted Advisor. Does this mean there are many things that can't be caught unless we introduce Security Hub CSPM?

Yes, it can detect across many more resource types than the content of AWS Trusted Advisor, which is available at no extra charge if you use Support, and it has various features useful for operations such as fine-grained parameter adjustment, suppression settings, and automatic remediation. AWS Security Hub CSPM is an essential service in every AWS environment.

Notifications came from CSPM, but we forgot to respond and they were not re-notified. There are cases where things are only finally found during recent comprehensive security checks, and I feel that operating only with Security Hub notifications is tough. With many accounts, operating Security Hub itself is hard and troubling.

Yes, AWS in particular does not have a ticketing/ticket management function to manage the status of detected issues and threats. It is expected to be used in integration with ticket management systems that companies usually have, such as Jira or Backlog.

You need to address this together with efforts such as mechanisms to suppress notifications and developing guidelines to reduce notifications.

That said, including these points, as the environment scale grows, using third-party CNAPP-type solutions can sometimes make things more convenient, so I think it would be good to consider those as well.

Summary

Doing AWS security properly is hard, but you need to build up steadily from the basics. There are no shortcuts on this path, so let's do our best!