Similar to our earlier showcasing of Microsoft365, AzureAD and Salesforce, we have decided to dive deep into the Google ecosystem for enterprise SaaS. We have recently added Google Workspace components to our SSPM (SaaS Security Posture Management) solution.
Following suit with our other app-suites, customers that are on our SSPM platform will have access to filter and view their Google Workspace assets from the Inventory view, as well as out-of-the-box predefined rules, control mapping into a variety of compliance standards and domain categories, and the ability to execute custom queries and rules for continuous monitoring using Netskope Governance Language (NGL). Using the Google Workspace Admin-SDK as a source of truth, we pull all available information related to the following components::
- Roles and Privileges
- Third-party application tokens
... with more on the way.
How do you find these attributes and components?
We have designed a 1:1 mapping from the Google Workspace API to the Netskope SSPM model, i.e. you will see components and attributes named the exact same way as you do in Google documentation. You may explore your assets in a tabular view through the inventory section, or explore rule-writing and search through the NGL search console aided by the auto-suggest features, or simply refer to the documentation below:
- For help with the attributes and type-definitions for these components, refer to the Google Workspace DOM Documentation.
- For help with NGL and how to address these types, refer to Writing Custom Rules with Netskope Governance Language.
Sample User metadata returned from NGL-search or the Inventory-view:
To help you get started, we show you how to perform a few real time queries on the SSPM inventory using NGL below. Both of the rules below have also been included as predefined rules, so, if you are on the SSPM platform and have a Google Workspace instance configured, you can enable these through a simple policy configuration for continuous monitoring.
Ensuring that all users have listed at least one recovery email address
To address use-cases such as user verification, password-recovery and recovery from account compromise, it is crucial that users have a way to prove their ownership of an address. One way to do this is to have each user register and verify a back-up email address or phone number that can be used in break-glass situations. The following NGL asserts that each user has at least one recovery email address registered.
GoogleWorkspace User should-have recoveryEmail exists
If you would like to check for phone numbers instead, simply change the term recoveryEmail to recoveryPhone in the NGL statement above, i.e.
GoogleWorkspace User should-have recoveryPhone exists
Any users failing the above check will result in a finding. If you would simply like to interactively search for users that do not have a recovery email registered, you may check for precisely that condition in the NGL search console, i.e.
GoogleWorkspace User should-have recoveryEmail not-exists
GoogleWorkspace User should-not-have recoveryEmail exists
These types of queries help in establishing an interactive point-in-time investigative workflow. You may choose to search for entities matching some criteria and then contact stakeholders to remediate the resulting issues.
Ensuring that all users have enrolled themselves in 2-FA
In terms of protection against account compromise and dictionary attacks, and for general proof of identity, the importance of multi-factor authentication cannot be emphasized enough, and in the case of an application that serves as the source of identity and communication across your organization, even more so. The following NGL code demonstrates a simple check on the User instance pulled from the Google Workspace Admin API, which asserts that each User instance has enrolled at least one additional factor apart from their primary log-in mechanism.
GoogleWorkspace User should-have isEnrolledIn2Sv = true
Any users failing the above check will result in a finding. If you would simply like to interactively search for users that do not have MFA enabled, you may check for precisely that condition in the NGL search console as shown below.
GoogleWorkspace User should-have isEnrolledIn2Sv = false
Stay tuned for upcoming articles, in which we will be discussing and demonstrating NGL definitions for advanced, cross-component use-cases and customizing rules to your own unique business requirements.