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.
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)"
|
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.
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.
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:
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.
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:
Some of the most common scenario used with Conditional access app Control with GitHub are:
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:
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)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.