Cloud App Security With Amazon Web Services

Many enterprises have a multi-cloud environment combined with some combination of Microsoft, Amazon and Google, the major cloud service providers. Even I work primarily with Microsoft world It’s crucial to protect and find possible malicious actors and activities from the whole ecosystem the organization is using. Microsoft CAS-B (Cloud App Security) product can offer visibility for this area.

In this blog post, I will go through how you can leverage Cloud App Security capabilities with Amazon Web Services and Identity Provider (IDP) is Azure AD.

Built-in Policies And Templates

If you are familiar with the MCAS you know that it offers wide range of built-in policies for various scenarios. When MCAS is enabled in the tenant these policies are automatically enabled with default settings which is monitoring mode.

At the time of writing, MCAS offers the following built-in templates to detect and notify potential threats. New detections are added on a regular basis, I encourage to check policy updates from the reference link list.

Type	Name
Activity policy template	Admin console sign-in failures CloudTrail configuration changes EC2 instance configuration changes IAM policy changes Logon from a risky IP address Network access control list (ACL) changes Network gateway changes S3 configuration changes Security group configuration changes Virtual private network changes
Built-in anomaly detection policy	Activity from anonymous IP addresses Activity from infrequent country Activity from suspicious IP addresses Impossible travel Activity performed by terminated user (requires AAD as IdP) Multiple failed login attempts Unusual administrative activities Unusual multiple storage deletion activities (preview) Multiple delete VM activities Unusual multiple VM creation activities (preview)
File policy template	S3 bucket is publicly available

Built-in policies are categorized into three different categories as seen in the table above. Description of unusual activities:

These policies look for activities within a single session with respect to the baseline learned, which could indicate a breach attempt. These detections leverage a machine learning algorithm that profiles the users log on a pattern and reduces false positives. These detections are part of the heuristic anomaly detection engine that profiles your environment and triggers alerts with respect to a baseline that was learned on your organization’s activity.

All anomaly detection policy descriptions are found from here.

Pre-Requirements

Here is a short version of pre-requirements in terms of configuration to leverage MCAS capabilities with AWS:

• Azure AD
  • AWS integration
  • The Conditional Access policy for session control
• AWS SSO enabled subscription
  • Create necessary provider
  • Create necessary roles
  • Assign necessary policies to roles
  • Role provisioning

I’m not an AWS expert and was stuck a couple of hours because of authentication errors, SSO problems to be specific. I missed role mapping between AAD and AWS and for that reason claims didn’t contain necessary roles and AWS was not able to do the mapping after Azure AD authentication was successful.

Note: configure user provisioning to make your integration smoother

• 

I highly encourage to read these links to get started

• Tutorial – AAD SSO integration with AWS
• Flux7 – Best practice for AAD SAML authentication for AWS console

Alert Configuration

For testing purposes, I created multiple alert policies to Cloud App Security but will highlight one from each category to demonstrate MCAS capabilities for detecting activities. The categories are:

• Activity policy
• Anomaly detection
• File policy – governance

• 

What’s Needed For Data Flow?

When planning the MCAS policies it’s critical to understand which connectors and integrations need to be in place. For example:

• To create “Activity policy” you need to have AWS app connector in place – not real-time detections
• To create “File policy with governance action” you need to have MCAS behaving as a proxy (Azure AD + Conditional Access) – session control policies

• 

MCAS has multiple activity policy templates that can be used to detect suspicious activity in the targeted application. The activity policies are based on the API provided by the application.

This means that MCAS is relaying the data it gets from the vendor API and that these detections are not real-time. Based on my experience, in some cases, it might take as long as 2-3 hours to get the data from the API. Governance actions are available for the API’s but you need to verify which actions are supported in the application through API, there are differences.

Example Policy 1: AWS – Logon from a risky IP-address

For this specific case, I created policy “AWS – Logon from a risky IP-address” to demonstrate logon from malicious IP, for example in TOR-network. Take into account, that anomaly policies have also detection capabilities for risky IP-addresses, such as: “activity from anonymous IP-address” and “activity from suspicious IP-address”. The latter one is based on Microsoft Threat Intelligence detections.

• 

Example Policy 2: Impossible Travel Activity

Docs.microsoft.com – Microsoft Cloud App Security’s anomaly detection policies provide out-of-the-box user and entity behavioral analytics (UEBA) and machine learning (ML) so that you can immediately run advanced threat detection across your cloud environment.

These anomalies are detected by scanning user activity based on MCAS default policies. The risk is evaluated by looking at over 30 different risk indicators, grouped into risk factors, as follows:

• Risky IP address
• Login failures
• Admin activity
• Inactive accounts
• Location
• Impossible travel
• Device and user agent
• Activity rate

• 

Example Policy 3: AWS – Publicly accessible S3 buckets

This policy is the interesting one. With governance policies you can control what will be the action is certain activity is detected. Governance policies are not supported by all apps integrated to MCAS and all apps doesn’t have all governance actions supported. So, pay attention when planning governance scenarios with MCAS.

In the example policy, the alert is generated if the App is “Amazon Web Services” and “Access level is public.

• 

• 

• 

Security Monitoring – The Results

Based on policies I received following alerts, both in the portal and in my iPhone.

• 

• 

Conclusion

The more I work with Microsoft Cloud App Security, the more I like it. It has extremely broad set of detection capabilities available straight out of the box. It also supports quite many applications already as this blog post demonstrates.

App connectors are available through vendor API which provides greater visibility and control to app. More information about different API capabilities found from this link.

If you want to read more of Microsoft Cloud App Security detection capabilities here are links to my earlier postings, all from H2 2019:

• Cloud App Security with Power BI
• Cloud app Security integration with Defender ATP
• Monitoring capabilities for detecting suspicious apps
• Detect suspicious OAuth apps
• Azure ATP integration with MCAS

Happy Detection’s!