Managing Risk & Protecting Your Workday Data With Security Testing

Date posted
1 December 2019
Reading time
18 Minutes
Shelly Wilson

Managing Risk & Protecting Your Workday Data With Security Testing

As you develop and build your Workday configuration, your security configuration is what you rely on to shield you from data being compromised or from risk of financial fraud. How confident are you right at this moment that your data is adequately protected? How certain are you that:

  • all new and amended securable items are correct;
  • nobody in your workforce can see data that 's off limits;
  • your security groups are providing or preventing access to secured items accurately;
  • when you last made changes to membership or configuration of a security domain, there were zero knock-on effects;
  • your segregation of duties controls are working correctly for all workers.

Because when security testing isn 't a component of your testing strategy, the impact of issues like these can be significant for you and your business.

Four Types of Security Testing

4 types of Workday security testing There are four types of security testing that we recommend: testing of security groups, domain testing, and testing of BP controls (both positive BP testing and negative testing of segregation of duties BPs).

Testing security groups

This first type of testing verifies your security configuration by examining the permissions granted to your key security groups. It validates the data and business processes that the security group has access to.

Domain testing

Domain and business process policies are grouped into more than 40 functional areas. You can edit which security groups can access the securable items in a domain or business process security policy, and changes to the policies require testing.

Testing BP controls

Testing of controls is probably the type of security testing you 're most familiar with. This is BP testing, and with positive scenarios, you 're seeking to confirm that the expected handovers defined in a process are in fact triggering accurately and handing over to the authorised roles for those tasks. For example, the tester is the first approver for bonus payments over $10,000. Does he or she get the approval notification? And finally there 's negative testing of controls. These are also BP tests, but in contrast to positive scenarios, these tests look for the unexpected and the undesirable.They examine what happens when a user tries something they shouldn 't be able to do. And they ensure that any given user on your Workday tenant cannot perform any of the 'toxic combinations' of actions that are part of your segregation of duties matrix. For example, this might include a test that checks that no worker can create a supplier and also create a supplier invoice and pay that supplier invoice.

When to Run Security Regression Tests

Because your key security groups, domains, and BP controls change over time as your business evolves—and because of the highly intersectional nature of Workday security—there are a number of periods during the life of your system where comprehensive security regression testing is critical.

Initial deployment

The obvious one is during initial deployment projects. Often, security does not get the right level of focus during phase-one projects because it gets deprioritised for BP and integrations testing when time or resource pressures arise.

Change releases

Day to day business as usual changes will inevitably impact on security, so regression testing of your security should be built in to your release management process.

Workday updates

Another critical period is during Workday updates. Security is dynamic within Workday, and even during weekly patch releases, Workday will add, remove or amend items in domains.

Mergers, acquisitions and significant projects

As your organisation changes, or is redesigned to incorporate, divest or restructure organisations, this will inevitably mean substantive change to the configuration of your existing security groups or where they are assigned, which introduces risk.

Compliance periods

And finally there are your audit periods. Ensure you have a testing schedule that aligns with audit periods so you can show auditors evidence that you're doing your due diligence to monitor your system and can show them the test results that prove processes and controls are operating accurately.

Ongoing Security Verification—Resolving Critical Security Issues

There are a couple of regular checks that you should be doing:

  • verifying that security groups are assigned appropriately across your organisation; and
  • ensuring that there are no errors on the configuration of domains, policies and groups.

Workday provides a number of key reports that can be very useful for testing of security groups; these reports should be used on a regular basis as part of your overall testing regime.

Workday's Unassigned Roles Audit report

Workday Unassigned Roles Audit report The first of these is the Unassigned Roles Audit. This report allows you to see where there may be critical roles in your organisation that are not currently assigned, which could be causing problems with approvals/actions on BPs. Run this report on a regular basis, especially when you're doing a business reorganisation.

Workday's Security Exception Audit report

Workday Security Exception Audit report The Security Exception Audit report identifies any problem area with your security configuration. Workday explains the problem and solution for each exception. Generally, all you have to do is remove the invalid security group from the policy or business process to resolve the exception. You can also use this report to find intersection security groups that include organisation-based security groups based on organisation types that aren 't actual organisations.

Workday Security Exception Audit report BP security policy exceptions will flag issues at a BP policy level. For already-started BPs, either reassign the step that routes to an invalid user or rescind the process. In either case, change the BP definition for that organisation to specify only valid security groups.

How to Test Individual Security Groups

Relying on real workers for as test subjects is problematic because a) they're often assigned multiple security groups (making it difficult to identify changes to configuration) and b) real workers' data composition will change over time (for example their salaries increase, they change supervisory orgs or location, they're benefits change). One testing approach is to remove all other security assignments from your own worker record and assign to yourself only the security group that you want to review. Then, check what this group can do on the tenant. Another approach is to hire some synthetic or 'test' workers and assign them a security group that you wish to review. Whichever approach you choose, we recommend that you focus on your critical or highly-configured security groups when doing this type of testing. The objective is to assess what the security group can see and do against different Workday objects (e.g. workers, organisations, positions). So you 'll want to create a testing grid with detail on what you expect the security group to be able to do and see on given Workday objects.

Workday's Action Summary for Security Group report

Workday's Action Summary for Security Group report can be very helpful here. It gives an overview of what each security group has access to in terms of domains, with a total of secured items for each security group.

Workday's Action Summary for Security Group report

It also links to detail of secured items under type category—which defines at a BP level the allowed initiation, action, and action steps for each security group.

How to Test Segregation of Duties

Segregation of duties testing, should ideally align with any controls framework that you need to comply with (e.g. good practice to have three roles involved with every finance transaction on your tenant). If there is an identifiable controls framework in place for your organisation, you should:

  • select critical transactions (focus on financial and data risk items);
  • verify that only allowed roles can perform these transactions; and
  • ensure that where there are 'toxic combinations' (e.g. a single worker can create a supplier and raise supplier invoice and complete a settlement run for suppliers) that these are validated

Some negative testing is required here to ensure that workers cannot complete these combinations of actions inappropriately on your tenant. How often should you test segregation of duties? At the very least, this should coincide with your audit schedule.

Workday audit dashboard

There are a number of available reports to assist with this testing, which can be accessed through the Audit dashboard on Workday. There are two worth calling your attention to:

 width=

One is Segregation of Duties—Potential Customer Conflicts.

 width=

The other is Segregation of Duties—Potential Supplier Conflicts.

Test Smarter, Not Harder

 aria-hidden=

Note that security can be tough to test pervasively on a regular basis, as there can be so many objects to consider. So we wanted to finish off by showing you how automation can speed up your security testing. The webinar excerpt above is a demo of how our automated testing tool Kainos Smart carries out Workday security configuration tests.

Kainos Smart Security test runs screen

In addition to testing individual security groups, Smart can execute the critical security audit reports mentioned earlier as part of ongoing test runs. You can also use Smart to compare reports, including their structure and the output values. You can used this on an ongoing, scheduled basis to check if configuration data is changing within a tenant, or it can be used to check for data configuration and report definition (and availability) differences between tenants.

Kainos Smart security change tracking

In this screenshot above, you can see that the Security Change Tracking group membership test has run several times. This test executes the report in Workday, and compares the output to the previous test run. In this example, the latest run has failed, which indicates there were changes between this and the previous test run.

Kainos Smart Security Group membership

Within the comparison section, Smart provides an easy way to spot the differences between the test run outputs, highlighting any changes found.

Kainos Smart security comparison

In this case, changes that have been detected include addition and removal of reports and tasks for Absence Administrator and Absence Calculations Administrator.

Want to Learn More About Kainos Smart's Security Testing Capabilities?

Request a demo today. Over 350 Workday customer trust Kainos Smart Test to handle their security configuration testing.

About the author

Shelly Wilson