Security Monitoring and Posture Management in Multi-Cloud Scenario – Overview

As many of you already know, I have spent last couple of years purely focusing on security monitoring, leveraging Microsoft security solutions in the cloud. Even though, my work is focused on Microsoft technologies and how to get the most out of the MS security tools I’m more and more working with multi-cloud environments. The cloud environments typically are: Azure, AWS & GCP but also AliCloud is seen and naturally on-premises environment with hybrid identity still remains in the different ecosystems.

The purpose of this blog series is to shed light on how aforementioned can be built in multi-cloud scenarios, what are the possible options with pros & cons. There are always alternative options, so don’t expect this blog series to cover all possible solutions and all alternative approaches.

This is the first part of the series and will describe a high-level approach for building effective security monitoring & posture management with Microsoft security tools such as: Azure Sentinel, Azure Security Center & Microsoft Cloud App Security.

Take into account that scenarios vary. I have been involved in cases where all data (raw, alerts, events, signals) are collected to Azure and also in cases where only relevant important information is collected to the centralized repo.

Update 09/22/2021 – Architecture picture updated to contain centralized AWS S3 bucket where Azure connector can ingest AWS GuardDuty findings.

Architecture

Base of the architecture is one example case I have been working with. The idea in this architecture is to leverage Microsoft security solutions as much as possible in security monitoring & posture management. In the picture below, there are four (4) major log sources sending audit trail (alerts, data & signal, events / raw logs, recommendations, etc) to Microsoft security solutions (Azure Sentinel, Azure Security Center & Cloud App Security).

Azure & M365
- D365
Amazon Web Services (AWS)
Google Cloud Platform (GCP)
On-premises environment

All of these sources have multiple solutions & resources which needs detailed planning and configuration from security monitoring point of view. These will be addressed in later blog posts.

Solutions for Centralized View

The ultimate goal in this monitoring architecture is to build centralized multi-cloud view into Microsoft cloud. At the time of writing, it’s possible to build single pane of glass view to Azure Sentinel but I would still use all of the security solutions: Azure Sentinel, Azure Security Center (+AzDefender) & Cloud App Security.

Why? Azure Sentinel does provide effective view for security monitoring (and related activities such as Threat Hunting & SOAR) but when eyes turns to security posture management Azure Security Center (ASC) CSPM (Cloud Security Posture Management) capabilities jumps on the game.

Solution	Purpose	Sources	Notes
Azure Sentinel	Collect data (alerts, raw, events) from connected sources	Azure resources, M365 workloads, M365 security solutions, AWS CloudTrail, GCP Workspace	Collecting data into Azure Sentinel is relatively easy but in multi-cloud scenario there are things to consider: – Do you collect all raw logs or only alerts from other clouds? – Everything costs, is there a need to bring same data second time to centralized log repo? – Data normalization (every log is different)
Azure Security Center (Azure Defender)	Collect security configuration recommendations from AWS & GCP	Azure resources, AWS Security Hub,	Azure Arc adds capability to manage workloads in 3rd party cloud or on-prem (overview of Azure Arc) Provides cloud security posture management (CSPM) & cloud workload protection (CWP) capabilities in multi-cloud scenario. Side note: CSPM works in multi-cloud scenario for now, CWP doesn’t in all workloads.
Microsoft Cloud App Security	Collect events from the supported APIs and security configuration recommendations from AWS & GCP	CloudTrail, IAM, S3, AWS Security Hub	MCAS has two different API connections available for AWS & GCP: Security auditing: This connection gives you visibility into and control over AWS / GCP app use. Security configuration: This connection gives you fundamental security recommendations based on the Center for Internet Security (CIS) benchmark for AWS or GCP.

Microsoft Cloud

To build effective security monitoring in MS cloud you should cover Azure resources, Azure AD and M365 workloads but also consider how to cover the on-premises environment. The following picture presents ‘Azure Sentinel positioning’ in the Microsoft ecosystem.

In Azure resources side it’s critical to cover both, management & data plane activities in the audit monitoring strategy. Azure Activity Log contains operations in the Azure Resource Manager (ARM) level but not operations to objects in the resources. The latter one is configured with Azure diagnostics settings and is often overlooked.

Side note (credit to Thomas Naunheim): Azure Sentinel is collecting Activity Logs on Subscription-Level, MCAS on Root-Level. Consider monitoring Azure Activity Logs on “Management Group” level. Currently, they can not be collected by the native Azure Sentinel connector.

Alternative solution: Use MCAS or AzOps to analyze changes of Azure RBAC & Azure Policy on your top-level hierarchy in Azure. If you are interested how to establish this one with Azure Sentinel & MCAS see me earlier blog – ‘Monitor Elevate Access Activity in Azure with Azure Sentinel’ or MS Tech Community blog – ‘How to audit management groups in Azure Sentinel’.

Amazon Web Services (AWS)

On the AWS side, there are several native security solutions that provides information about the activities performed in the AWS environment. These tools can be naturally used without any integration with Microsoft solutions. A typical situation is that security monitoring data is ingested from AWS to Azure Sentinel and security posture related data to Azure Security Center. Is all the data ingested depends on many factors such as use cases, costs & responsibilities.

AWS Monitoring & Logging

AWS documentation states following about the monitoring and logging:

With AWS CloudTrail, you can monitor your AWS deployments in the cloud by getting a history of AWS API calls for your account, including API calls made via the AWS Management Console, the AWS SDKs, the command line tools, and higher-level AWS services. You can also identify which users and accounts called AWS APIs for services that support CloudTrail, the source IP address the calls were made from, and when the calls occurred.

Amazon CloudWatch provides a reliable, scalable, and flexible monitoring solution that you can start using within minutes. You no longer need to set up, manage, and scale your own monitoring systems and infrastructure.

Amazon GuardDuty is a threat detection service that continuously monitors for malicious activity and unauthorized behavior to protect your AWS accounts and workloads. Amazon GuardDuty exposes notifications via Amazon CloudWatch so you can trigger an automated response or notify a human.

Azure Sentinel grand connectors list has AWS solutions listed that can be used to send necessary audit data to Azure side.

The native connectors are:

Connector	Source	Reasoning
Azure Sentinel built-in connector	CloudTrail	Stream CloudTrail logs into Azure Sentinel
Microsoft Cloud App Security App connector	CloudTrail	Gives you visibility (API connection) into and control over AWS app use
Microsoft Cloud App Security App connector	Security Hub	To get AWS security configurations recommendations to MCAS
Azure Security Center	Security Hub	A single view showing Security Center recommendations and AWS Security Hub findings

Alternative approaches can be found from the Azure Sentinel grand connectors list and in some scenarios built-in connectors might not fulfill the needs.

Source	Type	Instructions
CloudTrail S3 logs	Custom	andedevsecops/AWS-CloudTrail-AzFunc: Azure native Sentinel Data connector to ingest AWS CloudTrail Logs (github.com) andedevsecops/aws-data-connector-az-sentinel: AWS CloudTrail Logs Ingestion (github.com)
CloudWatch	Logstash	Cloudwatch input plugin \| Logstash Reference [7.13] \| Elastic
Kinesis	Logstash	Cloudwatch input plugin \| Logstash Reference [7.13] \| Elastic
Object Level S3 Logging	Logstash	Hunting for Capital One Breach TTPs in AWS logs using Azure Sentinel – Part II – Microsoft Tech Community
Security Hub	Custom	andedevsecops/AWS-Security-Hub-Data-Connector (github.com)

Google Cloud Platform (GCP)

On Google Cloud side the workloads are basically divided to two (2) different areas, Google Cloud Platform (IaaS & PaaS) and Google Workspace.

Connector	Source	Reasoning
Azure Security Center cloud connector	Security Command Center	Security Center’s GCP connector connects your Google Cloud resources at the organization level. Take into account: – You can connect multiple organizations to one Azure subscription – You can connect multiple organizations to multiple Azure subscriptions – When you connect an organization, all projects within that organization are added to Security Center (this can be changed in GCP side)
Microsoft Cloud App Security App connector	Aggregated export sink – Organization level Pub/Sub topic – GCP project level Pub/Sub subscription – GCP project level Security & Command Center	The connection gives visibility into and control over GCP app use. The Cloud App Security auditing connection only imports Admin Activity audit logs; Data Access and System Event audit logs are not imported To get GCP security configurations recommendations to MCAS
Azure Sentinel built-in connector	Google Workspace API	The Google Workspace data connector provides the capability to ingest Google Workspace Activity events into Azure Sentinel through the REST API

Summary

This blog post only touches the surface and gives very high-level view of the possibilities in multi-cloud security monitoring and posture management. I’ve seen multiple different approaches in this area, for example, some organizations want to have all the possible data ingested to Azure Sentinel and some want to have only alerts/incidents from AWS side. The path that is chosen is related to use cases, costs, service responsibilities, SLA’s etc.

In the next posts I will go more deeply into the tech side of things, and the goal is to describe how multi-cloud monitoring can be built to ingest the needed data into Microsoft solutions; Azure Sentinel, Azure Security Center & Microsoft Cloud App Security.