Welcome to newest post in our series on how to protect your API Connected Apps using Microsoft Cloud App Security (Microsoft CAS).
As our first App, we'll discuss easy steps to protect and gain more visibility and control on GitHub. We'll publish other Blogs on Salesforce, Box and AWS in the coming weeks. If there is an App you would like to be covered in future blogs, let us know in the comments.
Why connect GitHub?
Connecting GitHub to MCAS will get you the following benefits:
|
Benefit |
Description |
Policy or template |
|
Compromised account or insider threat |
The built-in Threat Detection policies in Microsoft Cloud app Security will apply to GitHub as soon as you have connected it. No additional configuration is necessary: by simply connecting you will start seeing new alerts when applicable.
|
"OAuth app creation (GitHub)" |
|
Data Leakage Protection |
While the GitHub API connector does not allow content inspection, you can use MCAS to view and alert when a GitHub repository is shared, or when files are being downloaded at a high rate (mass download)
|
"Repository access level becomes public (GitHub)"
|
|
SaaS Security Posture Management (SSPM) |
Some developers may not be network security experts and we often see risky settings in our customers' GitHub environments, such as allowing repositories to be shared or changing admin permissions. MCAS can notify you if such action happens, empowering you to act fast, rather than react after a misconfiguration lead to data leakage.
|
"Enablement of private repository forking (GitHub)"
|
Connect GitHub to Microsoft Cloud App Security
To get these benefits you will need to connect Microsoft Cloud App Security to your enterprise GitHub instance.
We have already documented the steps to connect MCAS to GitHub in the step-by-step guide here.
Or if you prefer, check our video below.
Quick config - Quick Value!
To ease your MCAS configuration protecting your GitHub environment, we have added a few built-in templates for Activity Policies, that will simplify your tasks.
These built-in templates are available out of the box, and they can be used to create policies after you have connected MCAS to GitHub.
You can see the use of these templates in action in our video:
We recommended that you enable all these templates in your environment (by default they have no impact on end-users at all). Once the policies are created, they can be adjusted and filtered if the alerts become too chatty or too quiet.
GitHub Template list:
|
Template |
Description |
|
Repository access level becomes public (GitHub) |
This template will help generate an alert when a repository becomes accessible publicly. If the data in this repository is business critical, or represents corporate IP, it could be posing a high risk of data leakage.
|
|
Enablement of private repository forking (GitHub) |
This policy template will trigger an alert when an admin changes a key security setting "Enablement of Repository Forking". When repository forking is enabled, users accessing a repo could duplicate ("Fork") it, making it potentially easier to exfiltrate. Note that this policy does not alert when a repository is forked, but rather when forking becomes allowed. Of course, if Repository Forking is something that your GitHub team needs to allow, do not enable this template.
|
|
OAuth app creation (GitHub) |
Oauth apps can be a very easy way for attackers to take control of an app account without requiring a username and password. As for many other apps, GitHub allows Oauth apps to connect to it and potentially access its data, download code, or change administrative configuration. For that a token must generated. By creating a policy based on this template, you can be alerted when a new Oauth app token is created in your GitHub environment, letting you know ASAP when a potential risk is detected. Note: in addition to detecting new OAuth tokens, it is also recommended to integrate GitHub with Conditional Access App Control and prevent downloads altogether from risky sessions. More info here. |
Below is an example of the configuration of one of our templates:
Of course, after creating a policy from one of these templates, you can edit them to add any additional filters to tailor them to your specific needs.
Create your own policy and use advanced configuration.
The templates we discussed here are all activity policies. They can allow you to quickly configure very common use cases.
However, for any advanced, or less common scenario, activity policies can be configured manually, using the Activity types presented by MCAS from the GitHub API (a real-life example is presented below).
Here are a few best practices when configuring these:
- Single or repeated activity?
- That would depend fully on your needs, but cases where several repositories are shared in a short period of time could be a good indicator of data loss.
- Activity filters: filters are the most important part of the Activity policy as they allow to device what kind of event must be captured.
- App: always start with selecting the App you are creating the policy for (here, GitHub). This will limit the number of entries when trying to apply a filter on the Activity Type.
- Activity Type: this is often the most important filter. The list of activities caught by MCAS for each app can be very broad. For GitHub, it can be a sharing activity, or adding users to a repository. Based on your needs, review them, and select the appropriate filter. When in doubt, a good way to validate the behavior of a specific activity is to use the Activity Log in MCAS and filter on the type of Activities being evaluated. Another, more advanced option to get a better grasp on each of the activity is to view the GitHub API reference.
- Other filters can bring additional value, whether it is for GitHub or other apps, and they should be reviewed as needed.
Now let’s review a more concrete example, with a real-life use case:
Allowing Deletion or Transfer of Repository was enabled.
Following the same principle as some of the templates defined above, this policy will trigger when an admin changes the GitHub tenant's setting allowing a repository to be deleted. This does not mean that the action has happened, but rather that it was allowed and there may have been a malicious or erroneous configuration.
To configure that, apply the following filters in your Activity Policy:
You can add additional filters, such as location, usernames, etc. to personalize the policy.
Real time control
The policies and controls we have discussed above are all relying on GitHub’s APIs to query activities and information about the current user context. While this allows monitoring activities very specific to GitHub, 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 GitHub or any other Cloud App:
- Control file downloads
- Control file Uploads (including malware detection)
- Control or prevent Cut/Copy/Paste/Print
Some of the most common scenario used with Conditional access app Control with GitHub are:
- Block download of code files to unmanaged devices
- Prevent upload of code containing malware.
- Prevent copying data from an unmanaged device.
More info on how to use Conditional Access App control is available here:
- Protect apps with Microsoft Cloud App Security Conditional Access App Control
- Deploy Conditional Access App Control for featured apps (including GitHub)
- Configure Session policies
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 use case!
Now that you know all you need to get started with protecting GitHub using Microsoft Cloud App Security, please share with us your thoughts and your use cases. We would love to hear your feedback on our GitHub integration.
(By@Gershon Levitz, Idan Basre and @Yoann_David_Mallet)