8

Walk-Through – Assessing IAM Controls

From Chapter 1, Cloud Architecture and Navigation, to Chapter 6, Tips and Techniques for Advanced Auditing, we built foundational knowledge of cloud structure, navigation, and security controls, and in Chapter 7, Tools for Monitoring and Assessing, we learned about tools available for auditing. Now, it’s time to put our learning into practice by performing some example audit walk-throughs of basic controls within the major cloud providers.

In this chapter, we’ll cover the following main topics:

• Preparing to assess cloud IAM controls
• Assessing authentication and authorization
• Assessing access assignment controls
• Assessing privileged access controls
• Assessing device controls

We will pose an assessment question for each of the topic areas and execute a basic test procedure. By the end of this chapter, you will be able to perform a basic audit walk-through of a few IAM controls across the three major cloud environments.

Preparing to assess cloud IAM controls

As we covered in Chapter 2, Effective Techniques for Preparing to Audit Cloud Environments, developing a good audit plan requires a thorough understanding of how the enterprise environment is architected and connected. When it comes to IAM controls, knowing that the cloud environment is federated with another identity store versus using a localized identity store only, for example, will change the test procedures that should be used and the evidence that you would expect to gather. It may also influence the points of contact within the organization you would need to work with to obtain evidence details. In addition to understanding the architecture and integration design of the environment, like other audits, it’s essential to understand the risk and control objectives the organization is trying to address as part of the cloud audit process. As we’ve uncovered throughout Chapter 1, Cloud Architecture and Navigation, to Chapter 6, Tips and Techniques for Advanced Auditing, there is a myriad of options for configuring security controls within your enterprise cloud environments, and the configuration options an organization chooses should be reflective of their risk tolerance and control objectives.

In the sections that follow, as a prerequisite, you will require a minimum level of view or read access to obtain the test evidence independently. Depending upon your specific organization’s configuration and any additional customizations, you may require additional access rights or group memberships to directly access specific content, or you may be required to work with an administrative point of contact for your organization as you observe them pulling control evidence. For reference, any screenshots in the following sections are based on a user with administrative privileges to the cloud environment.

Another thing to keep in mind as you prepare to assess cloud IAM controls is that although some basic tenants are the same across the cloud providers, the nomenclature and structure vary. Please review Chapter 3, Identity and Access Management Controls, as a refresher on the IAM components across the three cloud providers.

Now that we have touched on a few points of preparation let’s perform our first walk-through challenge to assess authentication and authorization.

Assessing authentication and authorization

In the case of user authentication and authorization, it’s important to understand the source of identities and where they are managed. Cloud providers offer the ability to consume, share, and/or sync identity information within hybrid environments, across cloud providers, and with on-premise identity stores. As a brief reminder, authentication is the process of verifying an identity claim, and authorization is the process of verifying that the identity has the proper permissions to access content or resources. Both processes should be inclusive of human and non-human (service accounts, workload identities, and automation accounts) identities.

For our walk-through in this section, our control testing will determine whether the organization’s cloud environment adheres to a control policy that requires accounts that are inactive for 180 days to be disabled. In our example, we will walk through simple methods to obtain this information within AWS and Azure cloud environments; however, please keep in mind that there are often many other methods for pulling this information. Leveraging the established frameworks that we referenced in Chapter 2, Effective Techniques for Preparing to Audit Cloud Environments, may assist you in utilizing some of these other methods.

AWS IAM

In AWS, a convenient way to identify that users inactive for 180 days are disabled, is to execute the following test steps:

1. Navigate and log in to the AWS console.
2. Select the Identity and Access Management (IAM) service.
3. Select Credential report.
4. As shown in Figure 8.1, you will have the option to download this report locally. The downloaded report will provide you with a list of all users associated with the AWS instance and the status of their credentials, including the creation date and last login information:

Figure 8.1 – AWS IAM Credential Report

Once you’ve downloaded and opened the report, depending on the scope of the audit and the size of the user population, you may need to extract a sample from the list. However, within the report, as shown in Figure 8.2, you will be able to see two pertinent columns for the control – user_creation_time and password_last_used. This will give you an indication of the age of the account and the period for which it has or hasn’t been active. Based on the accounts here, our testing shows this control passes for the AWS environment:

Figure 8.2 – AWS credential report download

Now that we’ve performed the control assessment within AWS IAM, let’s look at performing the same control assessment in Microsoft Azure.

Microsoft Azure

To validate the control requiring that users inactive for 180 days be disabled, you can execute the following test steps to get an initial sample:

1. Navigate to the Microsoft Azure portal.
2. Select Azure Active Directory.
3. Navigate to the Users | All users blade.

Either select the option to filter users created within the last 360 days or edit the columns to include the Creation time field, as shown in Figure 8.3. If this is the first audit being conducted, you may want to go back further than 360 days for the user population:

Figure 8.3 – Microsoft Azure user list

After identifying your sample population, you will want to compare this with sign-in details for those accounts. In this example, we have found that Carmen Sandiego, as shown in Figure 8.4, meets our sample selection criteria, so now let’s see if our inactivity control passes for these users:

Figure 8.4 – Microsoft Azure filtered user list

To review the sign-in details for the selected users, you can execute the following test steps:

1. Navigate and log in to the Microsoft Azure portal.
2. Navigate to Azure Active Directory.
3. Navigate to the Users blade.
4. Perform a search for one of the selected users by entering the display name in the search and then selecting that user by clicking on the hyperlinked display name. Here you will be able to view sign-in details or directly access the sign-in logs for the user, as shown in Figure 8.5:

Figure 8.5 – Microsoft Azure selected user with sign-in details

Note that in our sample scenario, this control has failed. As shown in Figure 8.6, this user has no recent sign-ins, and based on the user creation date, it is clear that the user has been inactive for greater than 180 days:

Figure 8.6 – Microsoft Azure user sign-in history

Based on the previous steps, we can say that there are easy methods for gathering evidence for some basic IT general computing controls within cloud environments. We’ve also demonstrated the importance of assessing the control in multiple cloud environments if the organization is using more than one cloud provider for operations.

Now that we have performed a walk-through of a typical authentication and authorization control, let’s look at assessing access assignment controls.

Assessing access assignment controls

Beyond establishing who can access an environment and what they can do, another important area to assess is who can configure or modify access assignments for identities. In some environments, the assignment of access may be a completely automated procedure through account life cycle workflows. However, even with this automation, it’s important to establish who can modify it and influence the access being granted. It’s also important to clarify whether there are any exception processes in place that could potentially bypass that automation.

In this walk-through, we will assess which identities can perform user and access administration. For our control, we will look at testing Azure and GCP cloud environments to validate that all user access is provisioned through the organization’s entitlement life cycle process. For our example control, we need to verify that there is no evidence of access being manually assigned.

Microsoft Azure

To validate the control that access for the cloud environment is only assigned through an enterprise lifecycle tool, we will execute the following test steps to verify which accounts have provisioned access within our desired testing time frame:

1. Navigate and log in to the Microsoft Azure portal.
2. Navigate to Azure Active Directory.
3. Navigate to the Roles and administrators blade.
4. Select the Audit logs blade.

As shown in Figure 8.7, when accessing Audit logs from this navigational path, the results are automatically filtered on the RoleManagement category. You can do additional filtering as needed to get events for the desired date range and even filter on a more granular set of activities:

Figure 8.7 – Microsoft Azure role management audit logs

Within the list of audit log results, you can select each entry to get more details about the activity and what may have been modified. It’s important to note that in some cases, your report results will include default system maintenance activities, such as in Figure 8.8. These can be distinguished based on the Initiated by (actor) details:

Figure 8.8 – Microsoft Azure audit log entry performed by a default service

Now that we’ve determined a method for testing access assignment controls within Microsoft Azure, let’s look at testing this control in GCP.

GCP

Within the GCP environment, Google has provided resources that allow for the dynamic querying of policies and policy settings. As shown in Figure 8.9, you can develop your own custom query from scratch or use another query template to get started:

Figure 8.9 – GCP Policy Analyzer custom query

To effectively leverage this querying ability, you will need to understand the roles, permissions, and/or properties you want to assess. As shown in Figure 8.10, the query builder allows you to filter and select based on different options. In Chapter 3, Identity and Access Management Controls, we covered the resources available to help familiarize yourself with the roles and permissions within GCP.

Figure 8.10 – GCP Policy Analyzer custom query filter

After creating a query with a list of the permissions and/or roles that you want to validate, as shown in Figure 8.11, you will get some additional options to query based on options related to inheritance. Remember that inheritance is one of the constructs that GCP uses and that you will need to be aware of it as you perform control testing assessments. Once you have a list of users with permission to perform access assignments, you can then query activity logs to determine whether that access has been used:

Figure 8.11 – GCP Policy Analyzer custom query and inheritance options

Now that we’ve covered some ways to assess a basic control related to understanding who can perform access and assignments and when that ability may have been used outside of the control process, let’s look at performing an assessment of privileged access controls in AWS and Azure.

Assessing privileged access controls

As an auditor, it’s important to understand who has been granted privileged access within an environment. Knowing who has been granted privileged access and whether that level of access is appropriate given the individual’s job responsibilities is often a foundational step before assessing other IT general computing controls.

AWS IAM

One primary way of identifying users in AWS that have privileged access is by reviewing which users have access keys and when those access keys were last used. To pull this evidence, you can perform the following steps:

1. Navigate and log on to the AWS console.
2. Select the Identity and Access Management (IAM) service.
3. Select Users within the Access management option.
4. Within the Users report, you can review and filter users by a given set of criteria. To ensure all relevant options are visible in the report, you will need to open Preferences and ensure the options related to privileged access are part of your visible column list; as shown in Figure 8.12, you will have the following options:

Figure 8.12 – AWS EC2 Users report column selection

Once we have this list of users with privileged access, we can compare this with the expected list of users. Keep in mind this gives us one method to view users with privileged access; however, this is not the only method. Depending upon the configuration of the enterprise cloud environment, additional steps may need to be taken to obtain all users with privileges with access to cloud services.

Now that we’ve seen one method for pulling a list of privileged users with AWS IAM, let’s look at an option for pulling a list within Microsoft Azure.

Microsoft Azure

To validate a list of privileged users within an Azure environment, we need to execute the following test steps to verify the assignment of privileged access:

1. Navigate and log in to the Microsoft Azure portal.
2. Navigate to Azure Active Directory.
3. Navigate to the Roles and administrators blade.

As shown in Figure 8.13, when accessing the Roles and administrators blade, we have the option to select Download assignments. This will give us a comprehensive list of users with Azure Active Directory role assignments, from which we can validate the actual versus the expected list of users:

Figure 8.13 – The Microsoft Azure Roles and administrators blade

After selecting the Download assignments option, you then need to navigate to the Bulk operation results blade, as shown in Figure 8.14, to view and extract the report. A list of downloads that have been requested will be visible. To open the report, click on the entry under the Type column for the report that you wish to open:

Figure 8.14 – Microsoft Azure Roles and administrators bulk operation reports

Upon opening the report, as shown in Figure 8.15, you will find the role assignments (roleDisplayName) and users (displayName) to which they are assigned. You can also distinguish between built-in privileged roles (isBuiltIn) and the user type (objectType). Within this report, you can easily sort the specific privileged role assignments and see a list of users with this access. If you are unfamiliar with which built-in roles have privileged access, you can refer to the information shared in Chapter 3, Identity and Access Management Controls, on where to go for additional details.

Figure 8.15 – The AWS EC2 Users report column selection

Now that we’ve done a walk-through of identifying privileged users, let’s take a look at assessing device controls within a couple of cloud environments.

Assessing device controls

In our last walk-through session for IAM controls, let’s look at assessing a common control related to devices – the configuration of multi-factor authentication (MFA). In our sample walk-through, we will validate whether MFA is being enforced for all users and their devices in our AWS and Microsoft Azure cloud environments.

AWS IAM

In the previous section on assessing privileged access controls, we saw that AWS provides a Users report within the Identity and Access Management (IAM) service. As shown in Figure 8.16, we can see that MFA requirements for individual users can be found here. In the screenshot, we can see that the user is not enrolled in or required to use MFA, which would mean the control test fails in this instance:

Figure 8.16 – The AWS IAM Users report column selection

Another way to see the same information is within the credential report, which we reviewed in the section on assessing authentication and authorization controls. As shown in Figure 8.17, the report includes a field that indicates whether MFA is active for each user, providing an easy way to sort and determine whether the control objective is met:

Figure 8.17 – The AWS IAM Users report column selection

Now that we’ve seen how some of the previous testing procedures in AWS can also help in assessing device controls such as MFA, let’s take a look at reviewing MFA controls within Microsoft Azure.

Microsoft Azure

As we’ve covered throughout this book, there are often many paths within cloud environments to get to the same information, and reviewing device controls and compliance within Microsoft Azure is no different. One way that we can test that there are no exceptions to device control policies such as MFA would be to take the following steps:

1. Navigate and log in to the Microsoft Azure portal.
2. Navigate to Azure Active Directory.
3. Navigate to the Devices blade.

As shown in Figure 8.18, the overview shows that there are no devices that are uncompliant with the device policy. However, we should investigate this a little further:

Figure 8.18 – Microsoft Azure Devices | Overview

Prior to accepting the content of Devices | Overview as evidence that there are no exceptions to the policy, let’s check what the policy is by looking at the Device settings blade. Here, as shown in Figure 8.19, we can now see that there may be exceptions that allow MFA to not be enforced upon certain behaviors. This highlights why it is important for you as an auditor to understand not only what is being provided as test evidence but also how the specific cloud environment is configured to align with that test evidence.

Figure 8.19 – Microsoft Azure Device settings

In this section, we’ve performed a simple walk-through of device MFA enforcement settings, and we are now aware that in addition to overview reports showing compliance, we need to dig deeper and assess what is in the compliance policies to confirm whether control objectives are being met.

Summary

In this chapter, we performed a walk-through of common and practical IT general computing controls that may be performed when auditing cloud environments. We covered steps to assess authentication and authorization and reviewed that in a multi-cloud environment, these controls should be tested in all clouds. We also performed an assessment of access assignment controls and executed steps to determine who has privileged access.

We finished this chapter by performing a walk-through of a device-related control (MFA) and saw the importance of understanding how relying on overview details as test results could prevent the detection of configuration that does not align with the control objectives.

In the next section, we’ll continue with our walk-throughs – this time assessing policy settings and resource controls.