Back to Course

Incident Response with CloudTrail and Athena

0% Complete
0/0 Steps
Lesson 8 of 49
In Progress

Creating the SecurityAnalyst role

Christophe January 24, 2024

Now that we know what roles we need in our accounts, let’s go ahead and create them with baseline permissions.

In order to create these roles, we’re going to create Identity Center permission sets, which is a different process than you might be familiar with if you don’t have much experience with Identity Center. Don’t worry, we’ll walk through it step by step!

Before we create our roles, let’s start by creating a new group in Identity Center.

Create a group in Identity Center

Navigate to Identity Center and click on Groups.

You should already see an AdministratorAccess group from the lesson when we enabled Identity Center.

Let’s click on Create group.

Name this group IncidentResponse and set a description like:

Group for incident response

Select your user to be added to this group. Go ahead and create the group.

We’ll come back to this in a bit, but now let’s navigate over to Permission sets.

Create the SecurityAnalyst role

On the Permission sets page, click on Create permission set.

Here you have the option of either using a Predefined permission set or Custom permission set.

The predefined sets provide multiple options we can choose from, and they’re great for getting started. For the role we want to create, we can select the ReadOnlyAccess permission set.

On the next page, rename to SecurityAnalyst and then give it a description of:

Role for security analysts to investigate incidents

You can change the session duration if you would like, but I’ll stick to 1 hour.

Click on Next.

Review and then Create.

Now that your permission set has been created, we’re not quite done. The permission set has to be assigned to an account to get created in that account.

This may seem odd at first, but it makes a lot more sense once we look at multi-account setups later in the course.

Deploy the permission set to your account(s)

For now, click on AWS accounts in the left menu navigation, and then select your primary account. Mine is named cybr_demo_management and it’s my management account.

By default, we should be on the tab named Users and groups. There, click on Assign users or groups and then select the IncidentResponse group we just created.

Click on Next.

On this next page, we’re asked to select permission sets. This is where we can select the SecurityAnalyst permission set we just created, so let’s do that and click on Next.

Review and then Submit.

As we can see, it both added this IncidentResponse group and it added the SecurityAnalyst permission set to this specific AWS account.

As you create these permission sets and deploy them to your AWS accounts, and as you assign a user or group in Identity Center to a permission set, AWS will automatically deploy the corresponding role to those accounts for that user to be able to assume. Let’s see what that looks like.

View the role in IAM

Open up the IAM dashboard and go to Roles.

You should see a role that’s named something like AWSReservedSSO_SecurityAnalyst_d903bb75ee330a49. Yours will look a little bit different but it will start with AWSReservedSSO and then your permission set name and then some random characters.

These aren’t the most user friendly names, but let’s click on it to see what it looks like.

This is just like roles we’ve created in other courses. It has the permissions policy of ReadOnlyAccess which is what we selected, and it has a trust policy under the Trust relationships tab.

Mine looks like this:

    "Version": "2012-10-17",
    "Statement": [
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::299551924423:saml-provider/AWSSSO_6934c0a233058b4f_DO_NOT_DELETE"
            "Action": [
            "Condition": {
                "StringEquals": {
                    "SAML:aud": ""

Code language: JSON / JSON with Comments (json)

The Principal value is set to Federated and it has an ARN value automatically set by AWS behind the scenes.

You can learn more about IAM SAML identity providers here, but for the scope of this course just know that the role is dynamically assigned to a federated user that’s authenticated by your organization’s identity provider — which is what we enabled by using Identity Center.

Because of how this role is configured, you can now request temporary credentials to access AWS by assuming this role, and you will inherit whatever policies are assigned to the role.

This is confirmed by the allowed action of sts:AssumeRoleWithSAML.

How Identity Center roles differ from IAM Roles

IAM Identity Center automatically creates an IAM role whenever you assign an Identity Center user to a permission set. However, they are slightly different than IAM roles:

  • IAM Identity Center owns and manages these roles, and only that service can modify the roles (if you try to modify it another way, it will generate an error)
  • The roles are configured to only be assumed by Identity Center users — IAM Users, IAM federated users, and service accounts cannot assume these roles
  • You can’t edit these role trust policies to change them even if it looks like you can through the console

So they are still IAM roles, they’re just IAM roles with more restrictions, and for security purposes, that tends to be a benefit.

Conclusion and next step

Now that we’ve created a role by creating a permission set, we need to learn how to assume this role to be able to use it. That’s exactly what we’ll do in the next lesson, so go ahead and complete this one and I’ll see you in the next!


Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.