Managing security group configurations and maintaining tight control over organization relationships are critical factors in safeguarding Workday deployments from potential security breaches. Organizations need a comprehensive solution that not only enables them to manage user access efficiently but also empowers them to identify and address security compromising anomalies in their configuration. Among her many other talents, the Netskope SaaS Security Posture Management (SSPM) can help system administrators streamline security group management and detect policy violations within Workday deployments. With this article, we'll present a few practical recipes you can deploy with Netskope SSPM to monitor and harden your Workday deployment.
Unlike other solutions on the market, Netskope's approach is based on building an up-to-date model of the target systems as accurately as possible. We provide our administrators complete visibility to this model and the tools to navigate and query for various anomalies and configurations of interest. In this article, we show a few simple demonstrations on how this capability can be used to perform Workday Security Group management and for automating detection for excessive permissions.
For this exercise, we are using the SSPM inventory query tool along with the Netskope Governance Language (NGL). You can learn more about these from the Netskope Documentation.
Find external employees from unauthorized security groups
A common use case for custom rules and NGL is to build alerts on external accounts having elevated access privileges. Let's say that we want to find all user accounts without a @netskope.com email address registered to those who have access to the Workday security group "Compensation Administrator". You can use the following NGL within the inventory field to find matching resources:
Workday WorkdayAccount should-have
textmatch(emailAddress, "@netskope.com") = false
and securityGroups with-any-element
[textmatch(descriptor, "Compensation Administrator") = true]
With the Workday security model, there might be multiple groups that have elevated privileges of interest, so we would like to also search all entries that match "Payroll Administrator" as well. You can easily add that as an additional selector to our query:
Workday WorkdayAccount should-have
textmatch(emailAddress, "@netskope.com") = false
and (securityGroups with-any-element
[textmatch(descriptor, "Compensation Administrator") = true]
or securityGroups with-any-element
[textmatch(descriptor, "Payroll Administrator") = true]
)
Ensure special user groups use hardened configurations
Our organization uses an external identity provider (IdP) to provide our employees access to various SaaS applications like Workday. In our configuration, we use Okta as our IdP and everyone who has been onboarded to it has been assigned to the Workday security group "OktaLoginGroup." However, we also have to provide access to some accounts without the centralized IdP for use cases. For example, contractors who work with recruitment functions or Workday implementer accounts and service accounts who might come from external sources could be granted access on the side. However, since these accounts bypass our central identification and authentication process, we want to ensure their workday accounts have additional hardenings in place.
As an example, we want to ensure that any account that is not using our centralized IdP should be forced to use a multi-factor authentication device. We can write an NGL to find for any accounts where this might be disabled like this:
Workday WorkdayAccount should-not-have
securityGroups with-any-element
[textmatch(descriptor, "OktaLoginGroup") = false]
and one_TimePasscodeAuthenticationExempt = true
Note that we used the "should-not-have'' expression in this rule instead of the "should-have" we presented earlier. Now this rule only lists resources which are passing the check and thus will have either the OktaLoginGroup security group present or the OTP requirement enforced. We did this as we want to save this rule as a continuous monitoring check into our policies and get alerted for any configuration drift. We can save this rule and add it to a policy by clicking the "Create Rule" button and following the instructions on security posture policy creation.
Tip: If you just want to investigate and search for any accounts that might not be compliant with the policy right now without saving it to a continuous monitoring policy, you can modify the above rule by changing the "should-not-have" to "should-have". You will then get a up-to-date listing of any resources where the conditions described above evaluate to true.
Netskope Governance Language is an incredibly powerful tool and exactly the same language we are using to build the out-of-the box detection content available to all our customers. These rules are all open and available to our users as well and we recommend you to check them out for more ideas and examples on how to customize the SSPM to your needs. By customizing your own rules, you can expand the SSPM beyond static configuration checks and known best practice monitoring to suit your unique business and policy requirements where required.
To learn more about NGL and how it can be used in your daily security workflows, check out our earlier community site articles for using NGL with Azure AD and Salesforce.