Part 2: Your Security Operations Cheat Sheet for Cloud Logs (and How to Link It to the MITER ATT&CK Framework)
Cloud adoption grows at astonishing rates, and more than 90% of organizations are now implementing a multi-cloud strategy. While data protection concerns obviously aren’t holding back cloud adoption, seven out of ten organizations remain concerned about covering all of their security blind spots.
Anton Chuvakin, a Google Cloud security solutions strategist, recently shared a helpful list challenges security teams face when it comes to thriving in the cloud, especially around detection and staffing issues. Here are some obstacles he identified:
- Extraterrestrial detection context– instances, containers, microservices, etc. – confused many born-and-bred teams on server names and IP addresses for context. This subject is large enough to be explored in a dedicated article later.
- The lack of clarity on cloud detection use cases exists despite helpful resources such as ATT&CK Cloud. Unfortunately, cloud providers haven’t necessarily simplified this journey for customers either, and many traditional SOC teams don’t know what to detect in the environments their enterprise uses today (“Is this container access Wrong ? “).
- Also, there are a lot of clouds; this means that the sprawl of governance leads to visibility gaps for the SOC. Examples include shadow IT (“BYOCloud” and SaaS purchased by departments) as well as other cloud proliferations (which is why people are looking for all these new attack surface management tools; this should help).
- SOC teams lack cloud competence in general; complex public/hybrid/multi-cloud scenarios require deeper knowledge of various technologies, their security implications, diverse (and foreign) data sources, while SOC teams are too busy doing D&R to develop their cloud skills.
- Lack of SOC input into cloud decisions, from vendor choices to IT architecture (and even security architecture). Frankly, many SOC teams are too busy and too focused on threats and don’t have dedicated headcounts to prepare their organization for the cloud shift.
And where detection tools are in place, there are alerts – sometimes too many, which can range from important missed events for major “emotional consequences, including Burnout. With SOC teams already overwhelmed with alerts, cloud environments only intensify that load.
One way to control alert overload is to manage log data produced by point systems, devices, and applications in the enterprise environment. Corn as Chuvakin reminds us, collecting logs and making sure the right ones get to SIEM is not a guarantee in the cloud world. According to him, it is because of:
- Uncommon log collection methods (compared to on-premises systems). Cloud providers haven’t necessarily simplified this journey for customers, though, compared to 2012decent logs exist today in many cases.
- Telemetry data volumes can 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 cloud storage buckets.
- For organizations trying to stick with legacy on-premises tools, many other challenges abound; the tools don’t support many cloud telemetry sources – they lack collection machines, analysis/analysis, use cases, useful visuals, etc. Also, log support is often not done at “cloud speed”.
- The egress costs are sometimes there, especially if you want to move logs from one cloud to another for analysis.
Identify and assess the most relevant log sources from which to draw data and prioritize alerts (which, by the way, can be automatically assigned investigation and response via playbooks within a SOAR platform) are among the biggest challenges for a security analyst. We recently shared with you a popular “cheat sheet“ compiled by Google Cloud Technical Solutions Engineer Ivan Ninichuck, high priority Windows and Linux logs, and mapped them to the main tactics and techniques of the MITER ATT&CK frame.
In Part 2, we’ve 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 MITER ATT&CK sub-techniques, which describe how opponents achieve their objectives. In this context, these listed sub-techniques help provide SOC teams with practical cloud threat detection and mitigation measures.
Cloud security can be tricky, and cloud threat modeling, although industry-wide efforts are underway to help define it, it is still in its infancy. Of course, you should continue to practice essentials such as authentication and network access monitoring, just as you would in an on-premises-only environment. But now you also need to consider new cloud-specific vectors, such as account management, instance images, and serverless services like Lambda functions.
The list below, while not exhaustive or definitive, is a good starter sample of critical cloud logs to monitor. Leveraging this will help ensure that you are devoting your expertise to detecting potential malicious activity in this new paradigm. Enjoy!
Google Cloud Platform Logs
|Location||The description||ATT&CK (sub-)technical|
|Admin activity audit logs||Administrative activity audit logs contain log entries for API calls or other actions that modify resource configuration or metadata. For example, these logs record when users create VM instances or change Identity and Access Management permissions.||T1525: Internal image of the implant|
|Data Access Audit Logs||Data Access Audit Logs contain API calls that read resource configuration or metadata, as well as user-driven API calls that create, modify, or read resource data provided by the user.||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 resource configuration. System event audit logs are generated by Google systems; they are not driven by direct user action.||T1078.001: Valid Accounts – Default Accounts|
|Audit logs denied by policy||Policy denial audit logs are recorded when a Google Cloud service denies access to a user or service account due to a security policy violation. Security policies are determined by VPC service controls, which provide policy denial audit logs to cloud logging.||T1190: Exploiting a public application|
Amazon Web Services Logs
|Amazon CloudWatch Events||Amazon CloudWatch Events provide a near real-time stream of system events that describe changes to AWS resources or when API calls are posted by AWS CloudTrail. Real-time streaming lets you create detection rules that trigger based on chosen events.||T1525: Internal image of the implant|
|AWS Setup||Config is a service that allows you to assess, audit, and assess your AWS resource configurations. Config continuously monitors and records your AWS resource configurations and allows you to automate the evaluation of saved configurations against desired configurations. With Config, you can review changes to configurations and relationships between AWS resources, manually or automatically.||T1562.007: Alter 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 change of that data.||T1530: Cloud Storage Object Data|
|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 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 related log data from CloudWatch logs.||T1562.008: Disable cloud logging|
|Amazon VPC Flow Logs||VPC Flow Logs allow you to capture information about IP traffic entering and leaving your VPC’s network interfaces. After you create a flow log, you can view and retrieve its data from 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 traffic to your instance.||T1046: Network Services Scanning|
|AWS WAF Logs||AWS WAF now supports full logging of all web requests that are inspected by the service.||T1190: Exploiting a public application|
Microsoft Azure Logs
The post Part 2: Your Cheat Sheet for Security Operations for Cloud Logs (and How to Link It to the MITER ATT&CK Framework) appeared first on Siemplify.
*** This is a syndicated blog from Siemplify’s Security Bloggers Network written by Dan Kaplan. Read the original post at: https://www.siemplify.co/blog/part-2-your-security-operations-cheat-sheet-for-cloud-logs-and-how-to-tie-them-to- the-frame-mitre-attck/