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. 

Cet article Microsoft Defender for Cloud Apps: how to secure cloud applications use  est apparu en premier sur RiskInsight.

Against a backdrop of an acute shortage of cybersecurity skills, these issues cannot be addressed solely by increasing the size of SOC teams. The use of new tools, based on four strategic areas, is essential in enabling SOCs to stay ahead of threats.

Here, extending the scope of detection enables the protection of new areas of the IS that are not sufficiently secure (such as the cloud) and of resources that are increasingly being chosen as targets (through ransomware attacks on terminals, targeted attacks using ADs, etc.).

At the same time, new approaches need to be adopted to detect targeted attacks (0-day, “low signal”, etc.), whose increasing sophistication is undermining existing security measures.

In addition to these new detection tools, an advanced knowledge of threats and attackers can improve existing detection capabilities, help prioritize incidents to be dealt with, and increase the effectiveness of the response.

But SOC teams are already struggling to process the events generated by existing tools. As a result, it’s essential to standardize and automate interactions between teams and systems, and, wherever possible, the sequence of analysis and response.

Follow our series on the topic and learn how to tool up in these four strategic areas!

Extending the scope of detection to new perimeters

A unique solution to secure all clouds: CASB

Cloud Access Security Brokers (CASBs) address an area of the IS that is poorly served by traditional security measures: the cloud. The very nature of the cloud means that protection in this area requires a different approach to that used for a conventional IS; there is little or no control of resources (infrastructure, OSs, or applications—depending on the type of offering), assets are located outside the IS, etc.

CASBs aim to centralize and ensure that security policies are applied. Some cloud providers offer their own CASB security services (for example, Microsoft’s Cloud App Security); but, depending on the needs, it may be preferable to use third-party solutions, even though there is a cost to adding in another player. While CASBs aim to ensure security levels in the cloud, relying on the cloud service providers to perform this monitoring role can be counterproductive: it’s preferable to make use of a “trusted third party”.

In all cases, CASBs offer a diversity of solutions that can include a very large number of services—their degree of maturity depending on the solution’s publisher, the cloud provider, and the type of hosting (IaaS, PaaS, SaaS, etc.).

On the one hand, CASB solutions make it possible to deal with specific cloud issues, by addressing the lack of visibility in these environments (through shadow IT detection, usage statistics, etc.) and ensuring that they are compliant (verification of configurations, etc.).

On the other hand, they play a part in the application of traditional security measures in this cloud. In particular, data security issues (such as DLP and encryption measures, which are of special concern to regulators) and threat detection (centralization of cloud logs for transmission to SIEM, detection of abnormal behavior using UEBA (see our dedicated article on this), etc.) are parts of a CASB traditional capabilities. In addition, some stakes associated with IAM can also be addressed by these solutions (SSO, access contextualization, etc.).

There are two main modes of deployment when putting these features in place, each with its advantages and disadvantages. Proxy-type solutions are placed between users and the cloud service.

In contrast, when using API-type solutions, which are sometimes called “out-of-band”, the cloud service’s consumers communicate directly with it. Each time it’s accessed, the service queries the CASB’s APIs to evaluate the risks and authorize (or prohibit) the consumption of the service. However, to operate, API solutions rely on the interfaces offered by the cloud provider, which may limit the options.

At present, CASBs are relatively new and immature solutions, and their deployment is limited. However, given the increasingly broad adoption of cloud services (already well advanced), CASBs undoubtedly have a bright future. They’ll enable SOC teams to extend their surveillance to this area, which will soon represent a large proportion of any IS.

Examples of CASB publishers:

The new Swiss army knife for securing terminals: endpoint detection and response (EDR)

Endpoint Detection and Response (EDR) solutions are set to enhance SOC’s detection and response capabilities for terminals (PCs, servers, etc.).

As the name implies, EDRs play a part in detecting attacks. In fact, they are plugging the gaps in anti-virus solutions (and other HIPSs) which make use of specific attack signatures and are therefore unsuited to detecting certain attack types—in particular advanced attacks (APTs). EDRs are based on other detection methods, with publishers generally offering a combination of techniques commonly used elsewhere.

Among these techniques, a large number of solutions detect the exploitation of known vulnerabilities or attack patterns (the opening of suspicious ports to dubious addresses, etc.), the analysis of files using a sandbox (local emulation, submission in the cloud, etc.), and behavioral approaches based on Machine Learning (in particular UEBA solutions—see the dedicated chapter on this). Depending on the SOC’s needs, the alerts produced can be integrated as SIEM sources, or made available directly from the solution management console.

In addition to their advanced detection capabilities, EDR solutions also result in a considerable increase in visibility on devices: lists of processes and services launched, lists of files in certain system directories, as well as other information that facilitates investigation in cases where an alert is raised. Some solutions go beyond mere recovery of the state of the terminal at the time of the request, enabling its history to be recovered too: generation of logs, recovery of deleted files, etc.

But EDRs’ features don’t end at the detection and analysis phase. In fact, these solutions enable remote remediation actions to be performed, and the complexity of these depends on the publisher: deleting or quarantining files, ending processes, quarantining the terminal from the network, modifying registry keys, etc.

EDRs, thus, are comprehensive solutions that come into play at every stage of the process: from detection, through analysis, to response. However, they are not intended to replace anti-virus solutions: it’s always more effective to block known attacks, even though publishers are increasingly offering solutions that combine these two types of functionality.

For more details on EDR solutions, read our dedicated article here.

Examples of EDR publishers:

Protecting the keys to the kingdom: Active Directory supervision

Directories are among an IS’s most critical components. They provide the authentication and authorization functionality for almost all IS resources—both technical and business function—including the most critical ones. It’s therefore not surprising that compromising the AD is one of the most frequent attack methods used, since it opens numerous doors to an attacker.

Despite this criticality, and the fact that AD architectures are well known and have evolved little in recent years, their security has scope to improve. This is due, in particular, to their specific mode of operation (OUs, domains, trees, forests, users, etc.), which renders traditional protection and surveillance methods ineffective; a significant concern given that any vulnerability can represent a major risk for the rest of the IS.

AD surveillance solutions aim to overcome this problem by supervising (in real time, or during an audit) the specificities of directories (configuration, status of accounts, etc.) and detecting vulnerabilities that could result in them being compromised. To do this, AD supervision solutions have a highly detailed knowledge of how ADs function, and, in particular, the associated security issues.

When the solution detects a vulnerability, it raises an alert (via the SIEM, or directly) and can provide remediation advice to facilitate the work of the teams responsible for rectifying the problem.

AD supervision tools also enable the SOC to detect any changes in configuration (legitimate, accidental, or malicious) and continuously assure security levels for these critical components. In doing so, they make the task of numerous attackers decidedly more complex.

In addition to directly strengthening the AD’s security levels, such solutions can also be used to ensure compliance with standards or regulatory requirements (for example PCI DSS, etc.).

These solutions are not widely applied today, and their use is generally limited to one-off audits. However, given the considerable security improvements associated with the provision of detection and remediation advice, and their ease of use, such solutions have strong potential and are likely to find their place among the tools used by SOCs.

Examples of AD supervision publishers:

You can find our second article in the series here.

Cet article SOAR, UEBA, CASB, EDR and others: which tools do you need for you SOC? (1/3) est apparu en premier sur RiskInsight.