Auditing Cloud Administrator Behavior as a Matter of Data Breach Preparedness

Image

New technologies often present interesting challenges for security teams, with cloud services such as AWS, Azure and GCP providing particularly novel cases in comparison to “classic” on-premise systems. As cloud services race to add new features that drive new customer interest and increase retention of existing clients, there is a very real risk of exposing new threat vectors to the business if even the most minor of misconfigurations occurs. This makes the role of cloud administrators and their daily security practices all the more important. Auditing administrator behavior has stood out as a must for many years, but as more and more administration functions move to hosted services, I’m seeing increasingly large gaps in the monitoring profiles of businesses. Specifically, I’m noticing that the tight controls that have been developed and refined for traditional IT are no longer in place. Fortunately, the Center for Internet Security’s (CIS’s) guidelines around securing cloud platforms are largely in line with what many security teams would be familiar with. They include key controls such as:

AWS – 1.1 Avoid the use of the “root” account

The "root" account is the most privileged AWS account. Minimizing the use of this account and adopting the principle of least privilege for access management will reduce the risk of accidental changes and unintended disclosure of highly privileged credentials. I’m sure most would agree that a control such as this would almost seem to be “common sense,” but the added pressure on cloud administrators to rapidly respond to new requirements as part of a Dev-Ops style workflow means that even simple controls like these can fail due to a desire to be seen to be responsive to the business’ needs. Such a perilous approach means that ensuring constant monitoring of the “fundamentals” is required. Indeed, a clear mandate of “security first” for all cloud processes should be in place to ensure that new cloud services are provisioned with the security team’s full understanding and agreement. After all, being the first to implement an insecure system should not be considered an achievement in anyone’s cloud strategy! Automation of service provision and self-service portals raise other interesting challenges and make it all the more important for the security controls that already exist to be designed as workflows and consistently implemented via automation tools. Teams should make sure to apply these workflows prior to letting end-users and developers carry out activities that might inadvertently expose data not just to internal system users who should not have access but also globally to anyone who might be interested in testing or probing your cloud hosted systems. Once these fundamentals are in place, though, there is further consideration required about the new sources of auditing data made available from many cloud platforms. New log collection sources and functionality means that there is increasing pressure to ensure that systems are appropriately configured “out-of-the-box” with system monitoring in place—not just at the cloud server provisioning stage, for example, but also at the administration consoles for each web platform you implement. Again, CIS does provide some guidance with relevant controls such as:

AWS - 2.1 Ensure CloudTrail is enabled in all regions

AWS CloudTrail is a web service that records AWS API calls for your account and delivers log files to you. The recorded information includes the identity of the API caller, the time of the API call, the source IP address of the API caller, the request parameters, and the response elements returned by the AWS service. CloudTrail provides a history of AWS API calls for an account, including API calls made via the Management Console, SDKs, command line tools, and higher-level AWS services (such as CloudFormation). and

Microsoft 365 - 5.1 (L1) Ensure Microsoft 365 audit log search is Enabled

Enabling Microsoft 365 audit log search helps Office 365 back office teams to investigate activities for regular security operational or forensic purposes. Both of these controls focus on new, cloud-oriented, auditing mechanisms that need to be set up to support your audit trail creation. And once you’ve got an audit trail for your cloud infrastructure,  it’s critical to ensure you close up the gaps that come from each system and ideally develop the methods that allow you to bring all the data together for forensic investigation cases so that you can quickly gather context around behaviors that might span multiple cloud platforms and potentially multiple types of systems (server-less architectures, virtual machines, hosted database and storage services, etc). I’ve previously posted about the security challenges cloud platforms present. Even so, making sure you’ve got the full picture remains the key takeaway regardless of the approach. Part of that is ensuring your cloud user and administrators behaviors can be scrutinized in the event of a breach so as to make sure that you understand when and where a compromise could have occurred.