Some SaaS applications provide the ability to enhance the security settings further using a custom HTTP header (Like domains whitelisting or enabling restriction mode)
CloudSOC policies can be used to leverage those headers to enhance the security settings.
This article assumes that the Gatelet in question is enabled and working properly.
Here are the steps to follow to create a policy to insert/inject a custom HTTP header:
Here is an example of the final policy:
Each SaaS application has a different list of headers to restrict the access further, here is a list of the well known ones:
Google Suite (GSuite) Applications
Header Name |
Possible Values |
Example |
X-GoogApps-Allowed-Domains |
Comma separated list of google registered workspace domains |
Example.com, example.org |
Microsoft Office 365 & Azure
Header Name |
Possible values |
Example |
Restrict-Access-To-Tenants |
Comma separated list of registered MS tenants |
contoso.onmicrosoft.com |
Restrict-Access-Context |
Single Directory ID |
xxxxxxxx-XXXX-xxxx-XXXX-xxxxXxxxxXxX |
Slack
Header Name |
Possible Values |
Example |
X-Slack-Allowed-Workspaces |
a comma-separated list of allowed workspace and/or org IDs |
TxxXXXXxxxx |
X-Slack-Allowed-Workspaces-Requester |
the workspace or org ID representing your Business or Enterprise Grid account. |
TxxxxxXXXxX |
YouTube (to enable restriction mode)
Header Name |
Possible Values |
Example |
YouTube-Restrict |
Strict | Moderate |
Moderate |
Webex Teams
Header Name |
Possible Values |
Example |
CiscoSpark-Allowed-Domains |
enterprise domain(s), comma separated |
example.com,example.org |
Note: Webex works a bit differently, the restriction is imposed on the domains which the users are logged from. if the header contains "example.com" , then only the users with an id/email from that domain would be allowed to use Webex and get access to any tenant in Webex ([email protected] can access any webex tenant *.webex.com). Visit the link in the additional information for more details from Webex.