Matt Lewis for AWS Heroes

Posted on May 24, 2022

How I passed the AWS Security Speciality exam with mostly free content 🥇

#aws #security #career #tutorial

Background

I recently re-certified the AWS Security Speciality exam. To me, it remains one of my favourite exams, and also one of the most beneficial for anyone looking to improve their AWS knowledge. It doesn't matter whether your interest is in containers or serverless, machine learning or data and analytics - you should understand topics like identity and access management, infrastructure security and data protection to deliver more secure solutions.

As always, there are courses available from the likes of A Cloud Guru,
Exam Pro, WhizLabs and others. You could also take the 3 day "Security Engineering on AWS" course, but this is likely to set you back at least £2,320 + VAT.

Not everyone has the means to access these courses, so lets look at how we can get certified using mostly free content. Even if you don't take the exam, this material will help improve your knowledge in this critical area.

AWS Material

The first place to start is the AWS landing page for the Security Speciality exam. This page provides links to the exam guide, which sets out each domain and its weighting, what is covered in each domain, and lists specific tools and technologies that might be covered on the exam.

In addition, the landing page links to the FAQs and AWS Whitepapers that are most relevant to the exam. It is definitely worth reading through these.

AWS now offer free, on-demand courses through their new learning centre - AWS Skill Builder. The most beneficial course on here is the two-hour "Exam Readiness: AWS Certified Security - Speciality". This runs through the course objectives, talks about each of the domains you will be tested on, and covers a number of sample exam questions and answers at the end of each domain.

AWS also provide hands-on labs to help you learn, measure and build following their architectures best practices. These labs are their Well Architected Labs based around the pillars of the well architected framework. There is a whole section consisting of security labs..

The key to passing this exam is to understand the core AWS services of IAM, VPC and KMS, alongside a higher level understanding of the AWS security services.

Identity and Access Management (IAM)

The IAM domain accounts for 20% of the exam, but in reality, a solid understanding of IAM will also help in many of the questions. This covers off providing authorisation and authentication to services and resources using the principle of "least privilege". This ensures that user, role, group or service is granted the minimum permissions necessary and no more, through policies that are attached.

Policy Language

You will likely be presented with policy statements in the exam, so you need to understand policy language. When you define an IAM policy you specify which IAM principals are allowed to perform which actions on specific AWS resources and under which conditions, using the following structure:

{
    "Statement": [{
        "Effect": "Allow/Deny",
        "Principal": "principal",
        "Action": "action",
        "Resource": "ARN",
        "Condition": {
            "condition": {
                "key": "value"
            }
        }
    }]
}

One thing that will almost certainly appear in the exam is knowledge around conditions. The Condition element or block lets you specify conditions when a policy comes into effect. For example, the snippet below will deny all access to the S3 bucket that doesn't use HTTPS:

{
    "Principal": "*",
    "Action": "s3:*",
    "Effect": "Deny",
    "Resource": [
        "arn:aws:s3:::awsexamplebucket1",
        "arn:aws:s3:::awsexamplebucket1/*"
    ],
    "Condition": {
        "Bool": {
            "aws:SecureTransport": "false"
        }
    }
}

The snippet below will deny all access to the S3 bucket that doesn't originate from the specified VPC endpoint:

{
    "Principal": "*",
    "Action": "s3:*",
    "Effect": "Deny",
    "Resource": [
        "arn:aws:s3:::awsexamplebucket1",
        "arn:aws:s3:::awsexamplebucket1/*"
    ],
    "Condition": {
        "StringNotEquals": {
            "aws:SourceVpce": "vpce-1a2b3c4d"
        }
    }
}

IAM Policy Types

The following are the different IAM policy types you need to be familiar with:

Identity-based policies - Attach managed and inline policies to IAM identities
Resource-based policies - Attach inline to resources like Amazon S3 buckets, AWS KMS keys and VPC endpoints
Permission Boundaries - A managed policy that defines the maximum permissions that an identity-based policy can grant to an entity, but does not grant to an entity
Organization SCPs - Service Control Policies grant the maximum permissions for account members or an organization or organizational unit (OU). Common examples include restricting AWS services or regions that can be used. Remember that these do not grant permissions themselves, and SCPs don't affect users or roles in the management account. They affect only the member accounts in your organization.
Access Control Lists (ACLs) - Amazon S3 ACLs that allow you to manage access to buckets and objects. This was the original access control mechanism in S3 that predates IAM. AWS now recommend that ACLs are disabled using the bucket owner enforced setting for S3 Object Ownership
Session Policies - Limit permissions for a created session, but do not grant permissions

Policy Evaluation

Another important area to understand is how policies are evaluated, with AWS providing this handly flowchart. The key point is that an explicit deny always results in access being denied.

Permissions across AWS accounts

Enterprises today will operate across multiple AWS accounts, which means situations occur when an identity in one account needs access to a resource in another account.

When two accounts are involved, both accounts need to be involved in the authorisation. In the example below, the resource policy (S3 bucket policy) states in the Principal element that it trusts the AWS account specified to write policies to allow access.

As you scale up, you can use Condition keys to simplify access from the resource policy:

aws:PrincipalOrgID - you can use this condition key to support any account in the specified AWS Organization
aws:PrincipalOrgPaths - you can use this condition key to support any account in a specified organizational unit within an AWS Organization

In other situations, you need to access a resource in another account that doesn't support resource policies like a DynamoDB table. In this case you create a role in the same account as the DynamoDB table that has permissions to access the table. You create a trust policy for this role by trusting the other AWS account to write policies to assume this role. The calling identity does not have permission to make DynamoDB calls, but it has permission to assume the role in the target account, which will then allow it to access the resource.

Assuming Identities

The other topic you need to understand are the different options to become an identity, including when to federate a directory service to IAM. These range from:

IAM users - users created in IAM that have long term credentials and should be avoided where possible
AWS SSO user pool - for a relatively small number of users with no user directory. A user in AWS SSO is assigned to a group in one or more AWS accounts that has a permission set defined. AWS SSO creates corresponding AWS SSO-controlled IAM roles in each account with these policies attached. This means you assume a role as part of a session with temporary credentials
AWS SSO wth Azure AD, ADFS or Custom Directory Integration - allows you to use an existing user directory of record

For applications that need permissions, you associate your EC2 instance (instance profile) or Lambda funcion (execution role) with an existing role and the compute environment takes care of managing the temporary credentials.

Further IAM Resources

To get a better understanding of IAM, and understand the different types of policies, I strongly recommend starting with this brilliant introduction to the world of AWS Identity by Becky Weiss:

AWS re:Invent 2019: Getting started with AWS Identity - an amazing introduction to IAM by Becky Weiss from ReInvent 2019

Following this, you can start diving into even more detail, with the growing series of talks from the awesome Brigid Johnson:

Infrastructure Security (VPC)

Infrastructure security makes up 26% of the exam, so this is a topic you need to know like the back of your hand. The starting position is the basics of how network routing takes place within a VPC as shown in the diagram below:

Your VPC has an implicit route, and you use route tables to control where network traffic is directed. Each subnet in your VPC must be associated with a route table, which controls the routing for the subnet. Every route table contains a local route for communication within the VPC. This route is added by default to all route tables.

A network access control list (NACL) is an optional layer of security for your VPC that acts as a firewall for controlling traffic in and out of one or more subnets. Each subnet in your VPC must be associated with a network ACL. If you don't explicitly associate a subnet with a network ACL, it will be automatically associated with the default network ACL. This allows all inbound and outbound IPv4 and IPv6 traffic. A network ACL has separate inbound and outbound rules, and each rule can either allow or deny traffic. They are also stateless, which means that responses to inbound traffic are subject to the rules for outbound traffic (and vice versa).

A security group acts as a virtual firewall, but operates at an instance and not a subnet level. Security groups are stateful, which means that if you send a request from an instance, the response traffic for that request will be allowed to reach the instance regardless of the inbound security group rules. You can specify allow rules, but not deny rules. You can also associate multiple security groups with a single instance.

There were several marks that could be easily gained (or lost) in my exam through understanding these components.

The exam also touches on more advanced networking topics which you can see in the diagram below:

By far the best way I found to understand these topics were to watch the series of talks from re:Invent by Matt Lehwess. These started out from a foundational level, and built up to cover more advanced topics. What worked for me was to watch them in order going back a number of years, so that the foundational level information was reinforced.

I would strongly recommend making sure you are familiar with AWS PrivateLink, and the differences between an internet and gateway VPC endpoint, and how you would enforce this through policies, and allow access through route tables.

This topic also covers off additional AWS services such as AWS Shield and Shield Advanced for DDoS protection, AWS WAF to block malicious traffic, and Inspector.

Data Protection

A whole 22% of the total exam is given to Data Protection, covering the design and implementation of key management, troubleshooting key management, and options for data encryption at rest and in transit.

Key management in this context covers both AWS KMS and Cloud HSM, and you need to understand when you might choose one over the other. However, the bulk of this domain requires a detailed knowledge of KMS.

A great place to start, and to help summarise some of the other content in the last few sections, is with another talk from Becky Weiss:

AWS re:Inforce 2019: The Fundamentals of AWS Cloud Security

This talk covers permissions management with IAM, network security controls with VPC, and data encryption with KMS.

I also wrote a previous blog post looking closer at AWS KMS in relation to QLDB, which looks at how to protect data in your QLDB ledger. This goes through the different types of CMK supported by KMS and dives into key policies. The other topic that comes up frequently in the exam is a key grant. These are used for temporary permissions as it does not impact your key policies or IAM policies. Grants are commonly used by AWS services that integrate with AWS KMS to encrypt your data at rest.

The following white paper is worth reading which describes the design and controls implemented within KMS to ensure the security and privacy of your data:

AWS KMS Cryptographic Details

Getting hands-on with AWS Organizations

Finally, the activity I did that helped me the most was to build out my own multi-account AWS environment using AWS Organizations. I did this using an open source tool called AWS Organization Formation (OrgFormation) by Olaf Conijn.

I wrote up the steps involved in the following blog posts:

This brought to life AWS best practice as part of their security reference architecture. The posts build out an environment that includes SCPs and permission boundaries, which really help position how they can be used. It also uses services such as AWS CloudTrail, CloudWatch Alarms, AWS Config with managed rules, conformance packs, and aggregators, and Amazon GuardDuty.

Conclusion

From watching the videos linked to throughout this post, and building out my own multi account AWS environment, I was able to comfortably pass the AWS Security Speciality exam. More importantly, I felt that the hands-on activities had left me with a long lasting understanding of some of these critical topics, as opposed to cramming in theory from a white paper which could be forgotten the week after. Hopefully this will encourage some of you to give the security speciality exam a go, and please reach out if you have any questions.

Top comments (1)

Serhii Vasylenko • May 26 '22

Well done! Thank you for sharing your experience and all learning materials!

DEV Community