Device management

For a company, a necessary part of users connecting to resources is having devices that can successfully connect, and this holds true even for cloud environments. Although many companies have adopted bring your own device (BYOD ) policies for accessing some or all company assets, in most cases,those devices require some form of device registration and security policy and posture management to prevent the risk of unauthorized or compromised devices from gaining access (Figure 3.12):

Figure 3.12 – Example Microsoft Azure device policy overview

There may be some default features within the portal environment for managing devices; however, in most instances, additional applications or specialized licensing for endpoint and mobile device management (MDM) is required to enforce and gain full visibility into device health and security compliance.

Important things to note for each cloud provider are assessing which administrators can modify device registration policies or register devices in the customer cloud and how these devices are validated. Another thing to consider is the impact and requirements of device policies for hybrid environments.

Now that we’ve reviewed important aspects of device administration in a portal environment, let’s discuss ways to review activity logs related to IAM within a cloud environment.

Reviewing activity logs

As an auditor, one method that may be used to correlate processes and procedures that mitigate risk is to review activity logs. In cloud environments, these logs may be made up of separate sign-in and activity logs that are capturing activity for user accounts and service or workload identities. The activity may be occurring directly within the portal UI or through API calls by an identity. An important step in ensuring these various sign-ins and activities are being captured is to ensure that auditing has been enabled. Thisshould not be assumed. There may be some auditing features enabled as default; however, this may not be a full set of what is required to satisfy a company’s control process, and the company should not rely on the cloud provider for managing the capture of these logs (refer to shared responsibility, discussed in Chapter 1, Cloud Architecture and Navigation, and Chapter 2 , Effective Techniques for Preparing to Audit Cloud Environments). In addition to the possibility that logs maynot be enabled by default, the amount of logging details retained may be limited unless administrators are intentional about updating the retention period and storage of log information, and this retention may carry a cost or require additional applications or tools, such as exporting the logs to a Security Information and Event Management (SIEM) tool. A list of logs and identity auditing features that should be enabled or considered for auditing use is included next.

AWS

Within AWS, there are several logging and auditing features that are natively available that will facilitate control test evidence and monitoring for IAM controls. These include (but are not limited to):

  • Amazon CloudWatch—Leverages AWS CloudTrail logs and provides the ability for alerts to be created for identity scenarios. An example use case is to trigger an alert if an IAM policy has been changed.
  • AWS CloudTrail—Captures IAM user activities and provides a way to audit, either through CloudTrail directly or by sending this to other tools (such as CloudWatch). You should ensure this is enabled for all regions and for all billing accounts within scope.
  • Amazon GuardDuty—Captures and alerts on cybersecurity-related identity risk based on information from AWS CloudTrail.

You can find more information about each of these features at https://docs.aws.amazon. com/whitepapers/latest/introduction-aws-security/monitoring-and-logging.html.

Azure

Similar to AWS, Microsoft Azure provides some native logging abilities that an auditor should review to confirm they are enabled, and also take advantage of as part of conducting the audit and collecting control evidence. In Azure, logging and monitoring areas for IAM include the following:

  • Audit, activity, and sign-in logs—These are enabled by default; however, there should be awareness of the retention period and length of time for which the logs are available. This may be dependent upon your organization’s licensing.
  • Azure Monitor and Log Analytics—This requires enabling diagnostic settings and configuration

within Microsoft Azure and provides a way to query various types of logs, as well as create “workbooks” for continued access to queries, and also offers alerting capabilities.

  • Azure Active Directory Identity Protection—As mentioned in an earlier section, Azure offers a way to monitor and alert on cybersecurity-related identity risks. Certain features may be dependent upon the level of your organization’s licensing.

To find out more information about these features, please visit https://learn.microsoft.

com/en-us/azure/active-directory/reports-monitoring/.

GCP

As with AWS and Azure, GCP offers some native options for identity-related audit logging and monitoring. Many of the logging options for GCP (such as Admin Activity logs) are enabled by default and cannot be disabled; however, it’s important to thoroughly review the logging settings across the entire GCP environment to ensure there is full coverage. You can learn more about GCP Cloud Logging at https://cloud.google.com/logging/docs/audit/.

Summary

In this chapter, we looked at where configuration options exist for IAM within the three major cloud providers. We covered where to find settings for authentication and authorization, permissions, and access management. We also reviewed concepts around device management, which is another type of identity, as well as the importance of understanding how logging may or may not be configured for a cloud environment.

In our next chapter, we’ll look deeper into network, infrastructure, and security controls within cloud environments.