Getting started with AWS Cloud Security

When you look to move or adopt the AWS Cloud, you need to think about your approach to the security of your workloads. With the shared responsibility model for AWS Cloud Security, you are responsible for the security of your workloads in the Cloud.

Like any other project, there’s plenty to consider. Of course, you can’t do everything at once. Many organisations we work with are looking for help in prioritising. These are the top 3 security actions that you should treat as fundamental to getting started with the AWS Cloud. Unfortunately they are not peace, love and Cloud but they aren’t difficult to implement either!

Federate identity and use short term credentials

Managing identify is key to protecting your environments and data. Key principles include

• Always use individual not group or shared accounts;
• If you have an identity provider, like Microsoft 365, federate your access to AWS using the identity provider;
• If you have multiple AWS accounts, use AWS SSO and federate your access to SSO to manage access all your AWS accounts;
• Use short term credentials (which is what SSO uses) through assuming roles over long term IAM users. In fact, beyond an emergency break glass admin account, you should aim to have no IAM users in any of your accounts!

Using roles is a key concept. Having people and services assume a role reduces the blast radius if those credentials are leaked as roles have a limited time. It also avoids storing of credentials in endpoints or configuration. Never – never! – store credentials in configuration. They will end up in a repository one day!

Enable monitoring

One of the fundamentals for AWS Cloud Security is instrumentation. AWS security services produce a large amount of information that can be used to understand threats and potential security incidents in your AWS environment.

• Firstly, make sure you have as a minimum the following AWS services enabled and logging – AWS CloudTrail, Amazon GuardDuty, AWS Config, Amazon CloudWatch (for AWS Lambda) and AWS VPC Flow Logs;
• Configure them to log the data for long term storage (using Amazon S3) for forensics (insurance you hope to never need);
• Ideally add notification of key events.

As an example, let’s have a look at how we would do this for Amazon GuardDuty. GuardDuty is a threat detection service that continuously monitors your AWS accounts and workloads for malicious activity and provides detailed security findings for visibility and ultimately remediation.

Fortunately, it’s super easy to setup!

• In the GuardDuty console, it’s a one-click action to enable. Once GuardDuty is enabled, go to Settings and change Findings export options to 15 mins;
• If you are using CloudFormation for infrastructure as code (and you should), it’s a very simple 7 line YAML template to launch GuardDuty!

AWSTemplateFormatVersion: 2010-09-09
Resources:
  GuardDutyDetector:
    Type: AWS::GuardDuty::Detector
    Properties:
      Enable: True
      FindingPublishingFrequency: FIFTEEN_MINUTES

• At this point, you should also consider setting up an S3 bucket to store the findings, using a KMS key to encrypt them. Again you can enable all this as code with CloudFormation!

• If required, you could also enable GuardDuty monitoring of S3 and EKS events;
• Finally, you can setup notifications of findings to an email address using EventBridge and SNS by following these steps.

Congratulations, you’ve just setup notifications for a key security source in AWS! You’ve taken your first step to gaining visibility into your AWS Cloud security. At RedBear, we send these findings to our Managed Security Services platform for analysis, alerting and automated response.

Setup least privilege access, don’t use broad access

We’ve all done it. You just need to get something done quickly. You have a broad all powerful administrator role. Assume the role, perform the action and move on. Sometimes your colleagues need to perform similar actions and you are all busy. Just give them the same access so they can get on with their job.

Let’s be honest, understanding the job roles and task functions is not easy. It takes time and effort but if you think about it up front it gets easier and far more secure in the long run. Interestingly, in the AWS space we see a split in approaches to this. A user based approach often starts broad and then attempts to reduce and refine. Organisations operating in the serverless space tend to start small and work outwards. After all in the serverless world, you have lots of small functions (or containers) performing a single or very limited set of actions. It’s far easier to give them the exact permissions that they needs. An everything as code approach forces you to think in terms of “what does this task actually need to do”!

In fact, this is the approach we would recommend. Start small and add permissions as required, taking a task based approach. IAM will tell you why an action failed if appropriate permission wasn’t provided. If you already have a number of broad roles that are used by your teams, IAM Access Analyzer is your friend. It will tell you what actions have been performed most recently and you can use this to pull back on the permissions. You can use this along with knowledge of your teams to setup a bunch of fine-grained access roles. IAM is not a simple tool. It is super powerful. Give it the time it deserves to get the right secure setup for your organisation.

Similarly, don’t use admin level access by default. Most access to the AWS Console for example, is simply to look something up. Use read-only access as a default and assume a higher role as required.

Wrapping up

Of course, this is only the start of your AWS Cloud security journey! There is a massive amount of capability in the AWS platform to secure your workloads. We recommend you check out our multi-part AWS Security Foundations series. Happy reading!