Home>Blog>Part 2: Your Security Operations Cheat Sheet for Cloud Logs (And How to Tie Them to the MITRE ATT&CK Framework)

Part 2: Your Security Operations Cheat Sheet for Cloud Logs (And How to Tie Them to the MITRE ATT&CK Framework)

9 Min read
Last Updated Thursday, March 17, 2022

Written by Dan Kaplan

Written by Dan Kaplan

Cloud adoption is growing at astonishing rates, and more than 90 percent of organizations are now operating a multi-cloud strategy. While data protection concerns are obviously not restraining cloud adoption, seven out of ten businesses remain concerned about covering all of their security blind spots.

Watch On Demand: Debunking Cloud Security Myths Webinar

Anton Chuvakin, a Google Cloud security solutions strategist, recently shared a helpful list of challenges facing security teams when it comes to thriving in the cloud, specifically around detection and personnel issues. Here are a few impediments he identified:

  • Alien detection context — instances, containers, microservices, etc — has confused many teams born and raised on server names and IP addresses for context. This topic is big enough to be explored in a dedicated post later.
  • Lack of clarity on cloud detection use cases is there despite useful resources like ATT&CK Cloud. Sadly, cloud providers haven’t necessarily simplified this journey for customers either, and many traditional SOC teams are not sure what to detect in the environments that their business is using today (“is this container access bad?”).
  • Also, there is a lot of cloud; this means governance sprawl causes visibility gaps for the SOC. Examples include shadow IT (“BYOCloud” and SaaS purchased by departments) as well as other cloud sprawl (that is why people are reaching for all those novel attack surface management tools; this should help).
  • SOC teams lacking cloud skill in general; complex public/hybrid/multi- cloud scenarios require more extensive knowledge of various technologies, their security implications, diverse (and alien) data sources, while SOC teams are too busy doing D&R to grow their cloud skills.
  • Lack of input from SOCs into cloud decisions, ranging from provider choices to IT architecture (and even security architecture). Frankly, many SOC teams are too busy and too focused on threats and don’t have a dedicated headcount focused on preparing their organization for the cloud change.

And where there are detection tools in place, there are alerts – sometimes too many of them, which can range from important events being missed to major “emotional consequences, including burnout. With SOC teams already overwhelmed by alerts, cloud environments are only intensifying this burden.

SOCstock 2021: The Cloud-Native SOC [Watch On Demand]

One way to help control alert overload is by managing the log data produced by point systems, devices and applications living across the enterprise environment. But as Chuvakin reminds us, collecting logs and making sure the right ones make it to the SIEM is no guarantee in the cloud world. According to him, this is because of:

  • Uncommon log collection methods (compared to on-premise systems). Cloud providers haven’t necessarily simplified this journey for customers, even though, compared to 2012, decent logs actually exist today in many cases.
  • Telemetry data volumes may be high; this has sometimes led to “log fragmentation” where cloud logs never make it to a SIEM, but are left to rot in some storage buckets in the cloud.
  • For those organizations trying to stick to old on-premise tools many other challenges abound; tools don’t support many cloud telemetry sources — they lack collection machinery, parsing/analysis, use cases, useful visuals, etc. Also, log support is often not done at “cloud speed.”
  • Egress costs are there sometimes, especially if you want to move the logs from one cloud to another for analysis.

Identifying and assessing the most relevant log sources from which to draw data and prioritize alerts (which, by the way, can be automatically assigned for investigation and response through playbooks within a SOAR platform) are among a security analyst’s biggest challenges. We recently shared with you a popular “cheat sheet,” compiled by Google Cloud Technical Solutions Engineer Ivan Ninichuck, of high-priority Windows and Linux logs – and mapped them to key tactics and techniques of the MITRE ATT&CK framework.

In part two, we have included the top security logs to monitor by cloud platform: Google Cloud, Amazon Web Services and Microsoft Azure. Next to each log file is a link to the MITRE ATT&CK subtechniques, which describe how adversaries accomplish their goals. In this context, these listed subtechniques help to supply SOC teams with practical mitigation and detection steps for cloud-related threats.

Cloud security can be tricky, and threat modeling for cloud, although industry-wide efforts are underway to help define it, is still in its nascency. Of course, you must continue practicing essentials like authentication and network access monitoring, as you would in an exclusively on-premises environment. But now you also must consider new vectors specific to the cloud, such as account management, instance images and serverless services like Lambda functions. 

The below list, while not exhaustive or definitive, is a fine starter sampling of critical cloud logs to monitor. Leveraging it will help to ensure you are devoting know-how to detecting potential malicious activity across this new paradigm. Enjoy!

Google Cloud Platform Logs

Location Description ATT&CK (Sub)Technique
Admin activity audit logs Admin activity audit logs contain log entries for API calls or other actions that modify the configuration or metadata of resources. For example, these logs record when users create VM instances or change identity and access management permissions. T1525: Implant Internal Image
Data access audit logs Data access audit logs contain API calls that read the configuration or metadata of resources, as well as user-driven API calls that create, modify, or read user-provided resource data. T1562.007: Imapair Defenses-Disable or Modify Cloud Firewall
System Event Audit Logs System event audit logs contain log entries for Google Cloud actions that modify the configuration of resources. System event audit logs are generated by Google systems; they aren’t driven by direct user action. T1078.001: Valid Accounts – Default Accounts
Policy-denied Audit Logs Policy-denied audit logs are recorded when a Google Cloud service denies access to a user or service account because of a security policy violation. The security policies are determined by VPC service controls, which provides the policy-denied audit logs to cloud logging. T1190: Exploit Public Facing Application

 

Amazon Web Services Logs

Amazon CloudWatch Events Amazon CloudWatch events deliver a near real-time stream of system events that describe changes in AWS resources, or when API calls are published by AWS CloudTrail. Real-time stream makes it possible to create detection rules that fire based on chosen events. T1525: Implant Internal Image
AWS Config Config is a service that enables you to assess, audit, and evaluate the configurations of your AWS resources. Config continuously monitors and records your AWS resource configurations and enables you to automate the evaluation of recorded configurations against desired configurations. With Config, you can review changes in configurations and relationships between AWS resources, manually or automatically. T1562.007: Impair Defenses-Disable or Modify Cloud Firewall
Amazon S3 Access Logs If you store sensitive information in an Amazon S3 bucket, you can enable S3 access logs to record every upload, download, and modification to that data. T1530: Data from Cloud Storage Object
Amazon CloudWatch Logs You can use Amazon CloudWatch Logs to monitor, store, and access your log files (such as your operating system, application, and custom log files) from your Amazon Elastic Compute Cloud (Amazon EC2) instances using the CloudWatch Logs agent. Additionally, Amazon CloudWatch logs can capture logs from AWS CloudTrail, Amazon Route 53 DNS Queries, VPC Flow Logs, Lambda functions, and other sources. You can then retrieve the associated log data from CloudWatch logs. T1562.008: Disable Cloud Logging
Amazon VPC Flow Logs VPC flow logs enable you to capture information about the IP traffic going to and from network interfaces in your VPC. After you’ve created a flow log, you can view and retrieve its data in Amazon CloudWatch logs. VPC flow logs can help you with a number of tasks. You can also use flow logs as a security tool to monitor the traffic to your instance. T1046: Network Service Scanning
AWS WAF Logs AWS WAF now supports full logging of all web requests that are inspected by the service. T1190: Exploit Public Facing Application

 

Microsoft Azure Logs

Azure Active Directory Reporting Reports user sign-in activities and system activity information about users and group management. T1078.004: Valid Accounts-Cloud
Activity Logs Provides insight into the operations that were performed on resources in your subscription. T1525: Implant Internal Image
Azure Resource Logs Provides insight into operations that your resource itself performed. T1562.007: Imapair Defenses-Disable or Modify Cloud Firewall
Azure Storage Analytics Provides insight into trace requests, analyzes usage trends, and diagnoses issues with your storage account. T1530: Data from Cloud Storage Object
Process Data / Security Alerts Provides security information and alerts. T1562.008: Disable Cloud Logging
Network Security Group (NSG) Flow Logs Displays information about ingress and egress IP traffic through a network security group. T1046: Network Service Scanning
Virtual Machines and Cloud Services Captures system data and logging data on the virtual machines and transfers that data into a storage account of your choice. T1190: Exploit Public Facing Application

 

Sign up for our newsletter and join thousands of your peers who receive monthly security operations tips and tricks.