DEV Community: rowan

Passing the AWS Security Speciality in 2024 (SCS-C02)

rowan — Mon, 11 Mar 2024 02:21:15 +0000

Last week I passed the latest version of the AWS Security Speciality (SCS-C02). The Security Speciality certification assesses your knowledge of the various AWS security services, and the security capabilities of more general services offered by AWS.

I really like this exam, and have been taking it since it was announced in beta back in early 2018:

It helps that I like AWS IAM more than most, and IAM is a big part of the exam. That being said, I think the new version of the exam (released in 2023) is a really good update that gives it more breadth, while still focusing on the most relevant security-related services in AWS - it helps that there are so many of them now!

If you want to pass the Security Speciality, you need know the official exam guide (PDF) intimately. All the exam questions are written with the guide in mind, so you can't be too familiar with it.

Here are the high level observations from my experience with the exam, keeping in mind that the questions are pulled from a large pool and are continually updated (I know because I wrote a few of them), so your milage may vary!

Exam Impressions

For all questions, even for other AWS certification exams, keep in mind the following:

Focus on the specific services mentioned in the question, as this will help you eliminate some of the distractor responses. Look specifically for services not mentioned by function rather than name, for example "global cache" is CloudFront, "object storage" is S3, "threat detection" is GuardDuty, etc.
Be clear what the priority is: the common ones are operational overhead or cost efficiency , which will enable to you pick between two similar responses. In most cases, a question that asks "least operation overhead" generally wants you to pick the response(s) with more AWS services.

Specific Examples

Systems Manager Parameter Store (specifically Secure String parameters) is often positioned as a cheaper (aka. "cost-effective") option to AWS Secrets Manager. Just remember that only Secrets Manager can automatically rotate secrets, so some solutions will require it, regardless of cost.

Know the differences between AWS KMS and AWS CloudHSM. This is particularly relevant when deleting keys: KMS has a mandatory waiting period, but CloudHSM can delete keys immediately. KMS also supports different types of key material, and there are limits to when you can/can't use them which you should know. Spend some time understanding KMS key grants - they are like resource policies for KMS keys, and will definitely feature in your exam.

IAM policy syntax and evaluation is a must! You will have multiple questions in this exam that will require you to read, understand, and choose between different policies. Of course if you need help with that, I got you 😉

This also includes SCPs, which are technically part of AWS Organizations but follow the same policy syntax as IAM. You should also know some of the common AWS IAM Conditions like those for checking MFA is present, etc. I had a couple of questions which required NotAction, which can be counterintuitive, but required to achieve some scenarios.

Know the difference between gateway endpoints and interface endpoints for VPCs. Gateway endpoints are an older (pre-PrivateLink approach) only for S3 and DDB, and require routing updates; Interface endpoints support more services.

Know the difference between services like Amazon GuardDuty (which detect anomalous behaviour and threats) and Amazon Inspector (which is for vulnerability management).

Any mention of PII usually means Amazon Macie.

Encrypting data is a key strategy to prevent the accidental leakage of data. By controlling access to the decryption keys, you give yourself another layer of control to prevent unintended exposure of sensitive data, regardless of the services being used.

Security Hub aggregates the result from other services (such as Config, Inspector, WAF, Macie, etc) to generate its reports and alerts, so make sure they're available.

AWS Service Catalogue featured in multiple questions where it was used to limit deployments to approved resources and configurations.

When quarantining a compromised instance, pay attention to the uptime requirements. You can quarantine by changing its security groups, or by moving the instance in to an isolated subnet; but changing an instance's subnet will require you to take it offline, but changing its SG won't.

Knowing how to set up a SAML identity provider in IAM helped on a few different questions about federation and SAML metadata changes.

Don't forget that AWS Certificate Manager certifications for CloudFront need to be provisioned in the us-east-1 (N. Virginia) region.

There were quite a few questions including CloudWatch Log. Keep in mind that CW Logs's IAM actions are in the logs: namespace, not cloudwatch:, and log deliverability is usually handled by the SSM agent.

Amazon Identity Center has a built-in user directory that can be used as an IdP for AWS-only solutions.

Know the difference between VPC NACLs (stateless, coarse) and Security Groups (stateful, fine-grained), as well as their defaults, features, and limitations. By default, Security Groups will allow all outbound traffic, and no inbound traffic.

Both S3 lifecycle configuration and DynamoDB item TTL provide a way to expire data for security reasons, limiting the potential for unintended exposure.

AWS Audit Manager featured in multiple questions; keep in mind it can work with on-premises resources for hybrid reports.

Know the various ways for delivering notifications: Amazon SNS can be used for low-cost email notifications (aka. "cost-effective"), Amazon SES (preferred for scale and deliverability), and Amazon SQS (used for messaging, but not email!)

Surprises

Fortunately, there were only a few surprises for me on this exam:

I had a question about DNSSEC for Route53 which caught me unawares.
X-Frame-Options headers can be added to origin response policies in CloudFront distributions.
Somehow I'd managed to skip AWS Signer in my review, but it only featured lightly and unlike a lot of other AWS services, the name actually tells you what it does (code signing for containers and functions) 🙃
I haven't had a chance to use Glacier Vaults, so I wasn't sure if or when you could change them; it turns out you have a 24-hour window to abort the lock and update the policy before it become immutable.

There were also a few omissions that surprised me, but this could have just been luck of the draw:

I didn't get any questions about session policies.
I only saw AWS CodeArtifact in distractor responses.

Having seen the exam evolve and change over time, I think this new version of the certification is an improvement over previous iterations, and would recommended it to people working with AWS seriously or on a daily basis - it's hard to overstate the importance of security in the cloud!

Being able to build secure applications on AWS, or assess an existing solution for potential security issues or improvements is a valuable skill, and one that I think will only become more important in the future. I think this exam is a good measure of someone's understanding of the security offerings and features on AWS.

External ID policy review

rowan — Tue, 14 Nov 2023 08:41:38 +0000

Granting 3rd parties access to your AWS resources via roles should always use external ID condition. If a vendor asks you to provision an IAM user with access + secret key in 2023, they're doing it wrong.

External IDs are used as part of the condition block on a role's trust policy, which is another name for an IAM role's resource policy. It controls cross-account access to assume a role by principals in other zones of trust/AWS accounts.

In this example, the role this trust policy is attached to will allow principals in the AWS account 123456789012 to assume the role using the sts:AssumeRole permission, as long as they include and match the external ID "94d44a42-eb49-4944-8a09-47fd68e2dbd5".

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "94d44a42-eb49-4944-8a09-47fd68e2dbd5"
        }
      }
    }
  ]
}

This external ID is just a UUID, but it can be any string value. This role can be assumed programatically using the SDKs or via a CLI command with the appropriate parameters:

aws sts assume-role \
    --role-arn arn:aws:iam::111111111111:role/RoleName \
    --role-session-name SessionNameIsRequired \
    --external-id 94d44a42-eb49-4944-8a09-47fd68e2dbd5

As the example suggests, you must include the role session name and it must be unique, even though it doesn't impact the session directly. The session name is used for logging purposes, and makes it easy to track in CloudTrail what was done by the assumed role, even if there are concurrent sessions.

Buy Why?

Using an external ID prevents the confused deputy problem, similar to what the iam:PassRole permission does for AWS services: AWS IAM:PassRole explained.

This condition acts makes sure that the delegated/trusted party double-checks that they're using the right delegation when accessing your account. If the external ID supplied as part of the assume role command doesn't match what the resource policy condition the API call will fail, just like any other policy with a condition blog. Without the external ID, a malicious user of the vender could potentially use the service to access a different customers' AWS resources.

You shouldn't be able to set the external ID. If you can, there's no point to having it! Even big security companies like Trend Micro have gotten this wrong in the past:

If you previously added an AWS account using a cross-account role, you might have specified a user-defined external ID. To better align with AWS best-practices, Trend Micro recommends switching to the Workload Security-defined external ID.

The external ID is not a secret, and is not treated as such by AWS. Similar to your AWS account number, it's not bad for external parties to know it (but I probably wouldn't be handing it out on the street either). Being able to re-generate the external ID is OK, as long as you can't actually set it, and it has a sufficient amount of randomness to it (e.g. a UUID or similar).

Relevant Links

CloudFormation Registry Cheatsheet

rowan — Wed, 04 Aug 2021 09:01:00 +0000

A few weeks ago the AWS CloudFormation Public Registry was announced. It makes it easier to distribute and consume CloudFormation resource types (sometimes called resource providers) and modules, which are referred to as extensions collectively. It doesn't support CloudFormation custom resources, which seem to be legacy functionality these days. Resources that are missing CloudFormation coverages are tracked in the roadmap repo on GitHub.

The registry documentation is as extensive and detailed as you'd expect from the official documentation. This can be hard to get started with, so here's a quick summary...

Extensions

CloudFormation Modules

Modules are pre-configured snippets of CloudFormation. They let you define how resources should be created in CloudFormation, but they don’t let you do anything that CloudFormation doesn’t already support.

CloudFormation Resource Types

Resource Types allow you to define resources that then can be created via native CloudFormation. They allow you to do things that CloudFormation cannot do e.g. create resources outside of AWS, managed via CloudFormation, or create AWS resource in a very specific/prescriptive way.

CloudFormation Registries

Private Registry extensions are a per-account registration of resource types and modules. This means you have to take care of provisioning, using, and updating the resource providers yourself. For me personally, this per-account limitation dramatically reduced the usefulness of resource providers, given the multi-account environments I usually work in, and that are encouraged by AWS's own best practices.

Public Registry extensions are published publicly for everyone on AWS to see and use. They can take advantage of drift detection (private types can't). They can also be integrated with AWS Config, so that you can see a history of changes to your deployed resources.

Public registry publishers must be one of:

AWS Marketplace seller, which is probably not you unless you’re already in the marketplace
A GitHub user
A BitBucket user

Publishing

Register in a particular region
Publish the resource provider in to private registry in that same region
Test the extension meets requirements, specifically the resource type tests

Consuming

Public registry extensions come in two flavours:

Amazon extensions are public and active by default, so you don't need to do anything to start using them.
Third-party extensions must be activated by account and region. When activating (only!) you can set an alias for the extension, and if you want automatic minor/patch version updates (extensions follow semantic versioning).

Activated extensions are replicated to your account. Types can be activated across an Organization using service-managed StackSets. Requires a service role that allows sts:AssumeRole by the service resources.cloudformation.amazonaws.com.

Cost

There is no cost associated with the public or private registries, only the costs incurred by the resources created, and the resources used when running the extensions in your account.

A Practical Guide to AWS IAM

rowan — Wed, 23 Sep 2020 09:59:07 +0000

Ever felt you didn't really know how to use AWS IAM?
Confused where to start learning?
Wonder no more, because I'm writing the guide for YOU!

In all seriousness, I'm writing the Practical AWS IAM Guide because I would've loved to have it 5 years ago. Now that I've learnt about IAM the hard way, I want to save others the trouble and pain.

I'm about 20k words in to the book, and still looking for practical things about IAM to include.

If you have any areas of IAM you'd like explained, please let me know in the comments! I'll be releasing plenty of content for free as part of the process.