Blog Post

Security, Compliance, and Identity Blog
6 MIN READ

Protect your Slack environment using Microsoft Cloud App Security

Yoann_David_Mallet's avatar
Aug 02, 2021

Protect Slack using Microsoft Cloud App Security 

 

Following popular demand, we are happy to publish our Slack app connector for Microsoft Cloud App Security!

Slack is a widely used communication and collaboration app, and like other applications, it can host critical data, and be compromised by malicious users.

Why connect Slack?

As one of the means of communication and data exchange within the company, Slack is prone to be a target for malicious actors. Slack could be used to access corporate data, to impersonate users, conduct phishing attacks, etc.

Therefore MCAS can be used to protect Slack in the following ways:

 

Benefit

Description

Policy or template

Compromised account or insider threat

The built-in Threat Detection policies in Microsoft Cloud app Security will apply to Slack as soon as you have connected it. No additional configuration is necessary: by simply connecting you will start seeing new alerts when applicable.

 

Activity from anonymous IP addresses

Activity from infrequent country

Activity from suspicious IP addresses

Impossible travel

Activity performed by terminated user (requires Azure Active Directory as IdP)

Multiple failed login attempts

Unusual administrative activities

Unusual impersonated activities

 

Prevent Data Leakage

Custom policies can be used to be alerted when users perform activities that may cause data leakage, such as creating shared links, adding new users to channels, files being downloaded by anonymous users, etc.

Custom Policies:

·       Public Share link created

·       Download by Anonymous user

·       User(s) added to Channels

SaaS Security Posture Management (SSPM)

Custom policies allow you to detect when critical security settings are being modified, such as allowing public share links to be created

Custom Policies:

·       Public Share sharing setting changed

·       Users allowed to manage a Channel are changed

 

Admin Role management

MCAS can detect when new users are granted administrative rights to Slack. This can be used to detect malicious attempts by attackers to become Owner of the environment

Custom Policies:

·       Role change to Owner

 

How to connect Slack?

First things first, you need to connect Slack to MCAS.

Review the video below for detailed steps on how to connect Slack to MCAS.

The connection process is fairly simple and takes less than 2 minutes.

 

Should you prefer reading about it, check out our official documentation

NOTEs:

    • Your Slack tenant must have an Enterprise Grid or Enterprise Select license. Cloud App Security doesn't support non-enterprise licenses.
    • For the slack connector to function properly, the Discovery APIs need to be enabled on Slack. For that, you will need to contact Slack customer service.

 

 

 

Threat detection

 

As soon as you connect MCAS and Slack, the built-in policies below will start applying and will trigger should any of these risky events occur:

 

Policy name

Description

Activity from anonymous IP addresses

This policy profiles your environment and triggers alerts when it identifies activity from an IP address that has been identified as an anonymous proxy IP address. These proxies are used by people who want to hide their device’s IP address and may be used for malicious intent.

Activity from infrequent country

This policy profiles your environment and triggers alerts when activity is detected from a location that was not recently or never visited by the user or by any user in the organization. Detecting anomalous locations necessitates an initial learning period of 7 days, during which it does not alert on any new locations.

Activity from suspicious IP addresses

This policy profiles your environment and triggers alerts when activity is detected from an IP address that has been identified as risky by Microsoft Threat Intelligence. These IP are involved in malicious activities, such as botnets C&C, and may indicate a compromised account.

Impossible travel

This policy profiles your environment and triggers alerts when activities are detected from the same user in different locations within a time period that is shorter than the expected travel time between the two locations. This could indicate that a different user is using the same credentials. Detecting this anomalous behavior necessitates an initial learning period of 7 days during which it learns a new user’s activity pattern.

Activity performed by terminated user (requires Azure Active Directory as IdP)

This policy profiles your environment and alerts when a terminated user performs an activity in a sanctioned corporate application. This may indicate malicious activity by a terminated employee who still has access to corporate resources.

Multiple failed login attempts

This policy profiles your environment and triggers alerts when users perform multiple failed login activities in a single session with respect to the baseline learned, which could indicate an attempted breach.

Unusual administrative activities

This policy profiles your environment and triggers alerts when users perform multiple administrative activities in a single session with respect to the baseline learned, which could indicate an attempted breach.

Unusual impersonated activities

This policy profiles your environment and triggers alerts when users perform multiple impersonated activities in a single session with respect to the baseline learned, which could indicate an attempted breach.

 

 

 

Best practices and recommended custom policies

As you know, the sky is the limit when it comes to configuring custom policies in MCAS.

We know this can make it challenging to identify standard policies that can help most customers. Therefore, below you will find the top 3 use cases that we recommend most customers set up in the area of data exfiltration.

 

Through that, you will also learn more about the type of activities that MCAS can gather within Slack, and you will be empowered to create your own policies, for your own business needs.

 

First, you can see a quick demo of all these scenarios in the video here:

 

 

Now a quick written summary of what you just saw.

 

Scenario

Description

Activity policy filters

Creation of external share link

Slack allows creating external share links that provide unauthenticated external access to a specific file. This can lead to data leakage or exfiltration, and MCAS can help to gain visibility to these events.

"App" Equals "Slack"

 

"Activity type" Equals "File Public Link Created"

 

Filter Capture:

 

Download from an anonymous user

When a public link is created, we may also want to know if the files have actually been downloaded by an anonymous user. For this, we can actually filter the download activities in Slack to the reserved username "USLACKUSER". This will return all anonymous downloads.

"App" Equals "Slack"

 

"user name" Equals "USLACKUSER"

 

Filter Capture: 

 

Configuration change: Allow public sharing, public posts, etc

In order to fully remove the risk of users creating share links of critical corporate data, Slack allows disabling that feature altogether. When doing that it is important to ensure that no admin will revert that change back. Here MCAS can see when some configuration settings are being changed, such as Allowing public links, or allowing public posts. It is then possible to create a policy to detect these activities and notify the MCAS administrator.

This kind of policy detects high risk behavior and we recommend configuring it with a high severity.

"App" Equals "Slack"

 

"Activity type" Equals "Preference - Disallow public file Urls"

 

Filter Capture:

 

Permission monitoring

One of the critical aspects of maintaining a high level of security in a cloud app is to ensure that we can detect when administrative roles are changed. One activity that MCAS can detect is when a user's role is changed to "Owner". Detecting this can be critical to maintain a proper security posture.

"App" Equals "Slack"

 

"Activity type" Equals "Role Change to Owner"

 

Filter Capture:

 

 

Real time control

The policies and controls we have discussed above are all relying on Slack’s APIs to query activities. While this allows monitoring activities very specific to Slack, it is an out of band connection (cloud to cloud, users are never aware of this connection) and as such, data is received by MCAS in Near Real Time.  

 

For use-cases where real time controls are required, we can leverage another component of MCAS: Conditional Access App Control. 

This feature allows MCAS to act as a reverse proxy in the cloud, and allows for a real time control of several activities, for Slack or any other Cloud App: 

    • Control file downloads 
    • Control file Uploads (including malware detection) 
    • Control or prevent Cut/Copy/Paste/Print 
    • Control over messages sent (select apps only)

 

Some of the most common scenarios used with Conditional access app Control with Slack are: 

    • Block download of sensitive data to unmanaged devices 
    • Prevent upload of malware. 
    • Prevent copying or printing data from an unmanaged device. 
    • Prevent messages containing sensitive content from being sent 

 

More info on how to use Conditional Access App control is available here: 

 

You can also learn about how to deploy Conditional Access App Control in the videos here: 

 

Configuring real-time monitoring and Control with Microsoft Cloud App Security 

 

Configuring a policy to block uploads in real-time with Microsoft Cloud App Security 

  

Share your thoughts! 

We hope this will help you get the best value out of MCAS and secure your environment. 

Have you found a scenario that we haven't covered here? Please share with our community and let us know in the comments below. 

 

Updated Aug 02, 2021
Version 1.0
  • IMFerret's avatar
    IMFerret
    Copper Contributor

    Hello,

    Is it possible to monitor active Slack sessions for inactivity and terminate the sessions after a specified period of inactivity?

    Thanks.