SSPM : Monitoring Salesforce Delegated Group settings with SSPM

  • 18 September 2023
  • 0 replies

Badge +1

During the development of Netskope Next Generation SaaS Security Posture Management (SSPM )  capabilities, one key decision was made to replicate the data models and resource relationships of the monitored systems as closely as possible with our graph-based engine. This choice has yielded a significant advantage, allowing us to swiftly adapt to changes and new features within the target systems represented in our model whenever the need arises.


An illustrative case is the management of Salesforce Delegated Group policies through SSPM. Delegated administration is a feature that permits Salesforce administrators to grant specific users (and user groups in the future) in designated roles the authority to manage users even profiles on their behalf. The Salesforce Spring ‘23 update introduced the ability to access Delegated Group Information via their API. This update allowed Netskope SSPM to add support for these resources, as managing delegated group policies properly is a valuable asset of Salesforce security administrators.

How do you find these components in SSPM?

To browse the delegated groups in your Netskope tenant, you can utilize the SSPM Inventory view that locates under "API Enabled Protection -> Security Posture SaaS -> Inventory". By using the filters for App Suite "Salesforce" and Resource Type "DelegateGroup", you can easily discover all of your DelegateGroup resources from your monitored tenant.


In addition, one should know the existence of DelegateGroupMember resources, which serves as the relationship table nodes connecting individual DelegateGroups to their respective users. These can be accessed in the inventory as well.

Using NGL to monitor Delegated Group Settings

For the rest of this article, we will leverage the powerful capabilities of Netskope Governance Language (NGL) queries. NGL is the tool we are using to power all of our built-in rules and provides users with the flexibility to implement their own detection logic. This can be achieved by modifying any of the rules we offered or by crafting entirely new recipes from scratch as defined in the language manual. Our community site contains numerous articles demonstrating NGL's effectiveness in performing various tasks within our supported app suites. These articles can serve as valuable sources of ideas and inspiration for users who want to enhance their detection and monitoring capabilities.

To access the NGL query prompt in the inventory view, simply navigate to the "resources" tab and click the "Switch to NGL" icon in the filters bar.


Let's get into Delegated Group context with a NGL query such as : 

Salesforce DelegateGroup should-have id exists

This query prints out every delegate group in your inventory as there does not exist any without a Salesforce object id. Such queries are useful for getting started as one can open the resource views presented for discovering any additional attributes that might be interesting to dig deeper into.


And if you want to filter out delegate groups with the "Contact Center Admin" permission set from others. You can modify the NGL as following : 

Salesforce DelegateGroup should-have permissionSets with-any-element ["Contact Center Admin"]


You can also combine multiple conditions in the NGL query. For instance, if you want to create an alert when a delegate group with "Contact Center Admin" permissions which also has custom object administration privileges related to user settings, this can be achieved by using the following query :

Salesforce DelegateGroup should-not-have permissionSets with-any-element["Contact Center Admin"] and customObjects with-any-element ["UserSettings"]

Please note that in the query above, we utilized the "should-not-have" expression instead of "should-have" because of the inventory search only shows the resources that are passing the condition given, ie. the-non violating resources. Furthermore, if you save the rule using the "Create Rule" button located on the right side of the prompt and add it to a continuous monitoring policy, it will generate alerts for the violating resources.


It's advisable that one should test out how different queries treat various resources by experimenting them both with the "should-have" and "should-not-have" expressions. It's important to emphasize that even though both inventory queries and continuous monitoring rules use the same NGL, yet their use cases work in an inverted manner.

More advanced use case of Delegated Group settings

Exploring the DelegateGroup element can lead to the creation of robust continuous monitoring policies. However, the true power lies in the connected nature of our resource model and the fact that you can join connected resources as components in your query. The DelegateGroup object is linked to other resources via the DelegateGroupMember object, which can be queried as well. 


As a simplest example of a connected rule, let’s search for any delegate groups that have had membership additions during the last week. This can be achieved using a function such as : 

Salesforce DelegateGroup should-have DelegateGroupMember with-attribute { age(CreatedDate , "days" ) < 7 }


Or if you have the exact Salesforce object id of a user and would like to find any delegate group membership changes made by them, you can use query as follows : 

Salesforce DelegateGroup should-have DelegateGroupMember with-attribute {CreatedById = "0058Z000007H2NbQAK" }


As we can see, the DelegateGroupMember objects may not contain much human readable information, which can make writing rules that target this resource less intuitive. Fortunately, we can continue following our connections further with the User resource to create more intuitive queries. For example, you can use the following query to find any delegate group memberships for a specific user : 

Salesforce DelegateGroup should-have DelegateGroupMember with-attribute { User with-attribute { Username = "" }}


Or you can identify lists of users with specific DelegateGroup permissions in a reversed process, which initiate the query from a Salesforce user and perform the query as: 

Salesforce User should-have DelegateGroupMember with-attribute {any DelegateGroup as dg with-attribute { dg.permissionSets with-any-element ["Contact Center Admin"]}}


Some may find other attributes of the user resource more valuable. For instance, if you wish to identify Delegate Groups that include users who are no longer active within the Salesforce tenant, you can accomplish this with the following NGL query : 

Salesforce DelegateGroup should-have DelegateGroupMember with-attribute { User with-attribute { isActive = false }}



Netskope SSPM and NGL are designed to be incredibly flexible and customizable. Being able to connect and model resources in a graph by their native references helps the security administrators understand the environments they are protecting in a deeper and unified way. Making queries to this graph and writing enforcement rules will help them maintain the integrity of their security model in a business-aware fashion.



The SSPM team will continue posting more samples and ideas for customizing the tooling to your requirements to the Netskope community site. Should you have questions on how to tailor the tooling to your needs, don’t hesitate to post your own questions on the forum or be in contact with your Netskope partner.


0 replies

Be the first to reply!