Data and collaborative spaces migration to the cloud has created new data breach possibilities and has particularly extended the attack surface of companies. Furthermore, cloud applications increasing utilization and new ways of working have considerably widened – whether voluntary or not – Shadow IT, that is to say cloud applications that are not validated by the organization, managed by IT teams or approved by security.
One of the solutions to these new use cases is the implementation of a Cloud Access Security Broker (CASB), e.g. Microsoft Defender for Cloud Apps (MDCA). What is the real contribution of these solutions? The first part of the article introduces CASB general features, the following parts focus on Microsoft solution, MDCA.
Cloud Access Security Broker (CASB), a way to reduce cloud applications related risks
A solution to secure cloud environment
A Cloud Access Security Broker (CASB) is a security checkpoint between company IS users and cloud applications. Analyzing internet flows from and to cloud services, CASB enables the organization to extend its security beyond its own infrastructure.
CASB have several key features:
- Apply security policies on cloud applications uses (granular access policies, authorized activities…)
- Detect Shadow IT, categorize and identify risk level associated to “Shadow” in-use applications
- Control Bring Your Own Device (BYOD), that is to say personal devices (laptops or phones) owned by collaborators.
A solution built on 4 pillars
To provide these key features, CASB is built on 4 major pillars:
Figure 1: CASB pillars
- Visibility: in order to manage cloud applications that are not supervised by IT tools, CASB provide visibility on cloud activities of collaborators, enabling the identification of unauthorized usages, associated data volumes, and business needs requiring other coverage
- Compliance: many cloud applications are not compliant or not enough protected. A role of CASB is to inform about application compliance and security, as a way to evaluate risks and thus to take wise decisions (addition to the app catalog, application blockage and associated communication to users…)
- Data security: enhanced DLP strategy (Data Loss Prevention) through CASB bring stronger control on sensitive data breaches from cloud sources, securing company-authorized use cases
- Threat protection: CASB provide defence against malware from cloud storage services and thus prevent threat spreading over enterprise network from cloud environments.
Microsoft CASB solution: Microsoft Defender for Cloud Apps (MDCA)
Microsoft Defender for Cloud Apps, a tool among an enriched security ecosystem
As Microsoft is aware of cybersecurity challenges, they have massively invested in their security solutions in order to improve features and their management, resulting in the release of the unified security portal Microsoft Defender XDR (formerly Microsoft 365 Defender). This portal meets the common issue of security teams – which was information scattering – by gathering 4 major tools features:
- Microsoft Defender for Office 365: secure messaging and collaborative spaces (e.g. incoming mails analysis, especially sender, content, attached files…)
- Microsoft Defender for Endpoint (Microsoft EDR): manage endpoint and prevent associated attacks, apply security policies, block possibly malicious programs
- Microsoft Defender for Identity: manage identity access and lateral movement attempts to compromise privilege accounts
- Microsoft Defender for Cloud Apps: enhance visibility and control over data transiting from and to the IS and cloud applications.
In addition to access to content facilitation for security administrators, Microsoft strengthens the correlation between pieces of information included in each tool. This correlation brings two major advantages:
- The expansion of the number of detection points, that increase the likelihood to promptly detect attacks, as several tools must be encountered to succeed an attack
- The correlation between tools and signals, that not only eases the understanding of the kill chain, but also provides a better incident contextualization and an easier sorting of numerous alerts from these 4 different tools. Figure 2 shows the solicitation of each Microsoft security tool according to the attack steps:
Figure 2: Several detection points of an attack in Microsoft Defender suite
As MDCA ecosystem is now explained, let’s look deeper into the tool.
Microsoft Defender for Cloud Apps, a set of additional strategies to configure to protect cloud applications and their utilization
Microsoft Defender for Cloud Apps deals with the notion of protection and detection rules, also called policies. Policies produce alerts when targeted events are logged to detect suspicious behaviour, they also can take pre-configured actions conditioned by these events. A MDCA committed menu gathers policies and alerts management. Several MDCA security policies exist, categories are detailed below:
- Threat Detection:
- Activity Policy: collect and monitor audit logs for embedded applications, through session control alerting when suspicious activity is triggered, detecting compromission or an internal user malicious activity
- OAuth app1 policy: manage application and user permissions on the environments to alert about OAuth applications at risk or overprivileged, in order to apply least privilege principle and improve detection on riskiest applications
- Information Protection:
- File policy: review and label files according to specified rules (creation date, modification date, contributors…) to protect data stored in the Cloud, e.g. by alerting when a file is dangerously shared on unauthorized domains, or when a sensitive data is detected on the Cloud
- Conditional Access:
- Access policy: real-time monitoring of cloud applications accesses (users, localisations, endpoints), enhancing Entra ID Conditional Access with granular filtering capacities
- Session policy: real-time management of user activities in order to immediately take action against suspicious or unauthorized activities, such as malicious files download, sensitive files download from specified risky areas
- Shadow IT:
- Cloud Discovery anomaly detection policy: alerts triggering when unusual behaviour is detected on managed cloud applications, based on machine learning capacities
- App Discovery policy: application flows analysis and data sorting (by user, by resource…) to associate a secure and compliance score to applications, to send alerts when a new application tagged popular or dangerous is used by specific groups of users inside the organization.
Which mechanisms are providing these diverse policies?
MDCA is composed of 3 major building blocks to be optimally integrated into an organization’s information system. Figure 3 points out the block “Cloud Discovery”, being an interface between MDCA and company firewall that analyse application flows inside the organization. “Cloud Discovery” also allows script configuration to restrict some uses. “Reverse proxy” block is placing MDCA between the IS and cloud applications, in order to continuously analyse sign-ins and policies (session, access…). Finally, “App connectors” block directly links MDCA to cloud applications to enable their analysis.
Figure 3: Monitoring mechanisms on cloud applications
Cloud discovery:
Cloud discovery operates with the logs collector of the company firewall, proxy or Microsoft Defender for Endpoint, which must thus be installed on every endpoint. Network logs contributes to cloud applications and associated network traffic analysis by MDCA. Then, this tool rates these applications based on current knowledge of several tens of thousands of applications, scoring being established from about 100 security and compliance criteria. Cloud discovery and cloud application
Reverse Proxy:
Session control relies on federated authentication. Once the Identity Provider is connected to Entra ID and the application to the environment, session is automatically captured and network traffic is routed towards a reverse proxy, when users log in using their credentials. Thus, some features can be implemented, such as blocking downloading, text copy, or asking for a multi-factor authentication before any action. Associated features are audit logs and session control mechanisms.
App connectors:
These are APIs connecting to most-used applications (particularly cloud storage services: AWS, Azure, GCP). Thanks to these connections, MDCA is able to regularly scan files online files, but also users reaching those documents. Provided features goes from accounts information and governance to application permissions through data analysis.
A wide range security & compliance use cases covered by MDCA
Many suspicious behavioural detection’s use case are enabled through the different MDCA’s strategy. Those detections can only raise one alert or trigger an instant remediation (e.g. blockage) according to the event’s gravity. Here are a few examples of those use cases:
- Creation of an alert:
-
- When connecting from an anonymous IP address (via Activity policy)
- When downloading a large quantity of data with an unusual user’s behaviour (via Cloud Discovery anomaly detection policy)
- When downloading a file with sensitive data (credit card number, passport number…) (via File policy)
-
- When an abnormal number of connections to a business application is observed (via App Discovery policy).
- Request of an MFA confirmation when a user tries to download a highly confidential file while being connected via Azure AD (via Session policy)
- Mandatory labelling before allowing a user to drop a file with sensitive information which isn’t labelled on the Cloud (via Session policy)
- Blocking the sending of a message from a user trying to send sensitive information to another user (e.g. bank account number) via instant messaging (via Session policy)
- Blocking the download from a cloud storage application of a confidential file if the user is connected with its personal computer (via Session policy)
Figure 4: Example of Session policy for controlling the use of an application
MCDA, a complex solution to implement
As seen previously, MCDA is a tool that offers several features that complement other of Microsoft’s security tools like DLP Purview or Microsoft Defender making the prioritisation of features to activate and to use a requirement. These features and the “policies” organization lead to a complex configuration which needs to be considered. It is then mandatory to target which use case needs to be covered and to test the effectiveness of the defined policies to ensure that on one side the risk coverage is effective and on the other to prevent the generation of too many false positives, as it can be seen when implementing some DLP rules.
Finally, the implementation of MDCA requires some non-trivial prerequisites such as:
- MDCA interconnection with the different Cloud applications used
- The implementation of mechanism to force passage through the CASB (blocking not compatible browser)
- Learning models’ formation and refining detection’s rules, whether they are provided by Microsoft or customised by the organisation to reduce the number of false positives.
As a conclusion, MDCA, as another CASB is a promising tool which need an advanced level of maturity
Microsoft Defender for Cloud Apps is naturally integrated to services and Microsoft security tools, has suspect activity detection strategies by default and allows you to get a first global view with a first assessment of the risks and of the interconnections between the organisation’s IS and cloud applications (Microsoft 365 included).
However, its apparent ease of implementation should not hide the need to setup some prerequisites like the refining of rules and the management of interconnections between the IS and the cloud’s environments (browsers’ management, interconnection of third-party applications…). It shouldn’t hide the efforts needed to implement detection’s strategies for the organisation (creation of rules, tests and corrections of false positives / negatives). Its implementation should be carried out as a part of a project and the creation of new strategies must be subject of a special attention and an iterative approach.
In summary, MDCA should be considered as a powerful security tool, which will need time to configure, refine and integrate to other additional features like data classification or conditional access rules. It will require a significant amount of time for configuration, which will only be possible after setting up a first level of security and acquiring a certain maturity level on the cloud applications and CASB’ use cases.
Thanks to Mathias COULAIS for his contribution to this article.
