Derek from Missouri

Security Hygiene Topics You May Not Have Considered

Introduction:

Workday is a large and complex system with thousands of capabilities across numerous modules. On top of that, users in your organization have requirements for access and limitations to data and functions.

Our Workday tenant security configuration has well over 50,000 secured items. Those are associated with one (or many) of 3600 security domains (All Domains) across 104 functional areas (Functional Areas). And don’t get me started on all the actions applied to security groups in business process policies.

Simply put, Workday has an expansive and complex security model that provides a highly flexible, adaptable, and consistent application of security policies. But, this can also be very overwhelming at times.

Organizations work to monitor and optimize their Workday security configuration. That means applying security appropriately but also seeking out configuration items that may not be necessary and could be an open door to accidental or intentional exploitation. Below are four actions that can be taken to ensure that you are running a tight ship.

Tip #1 - Report Sharing This is a relatively quick win and will ensure reports are accessible to those that need the reports, but also automatically adjust access as workers move around the organization.

Do not share with all authorized groups users - There are reports that a worker has the security access to run but may not be appropriate for them to run. Sharing with all authorized users opens the door to anyone with access to the data source. If you genuinely need all authorized groups to have access, you can assign that explicitly using the next step.
Share with explicitly chosen authorized groups - You can be more specific with sharing than with the last option. If you need to have all groups have access, you can explicitly choose all of them in the list of available groups. Will that ISSG in the list of security groups realistically run this report? Then don’t include that group in sharing; that is one less vector for accessing the report. A step in our Termination BP removes workers from user-based security groups, automatically removing their access to the reports.
Avoid sharing with individual users – This one can’t always be avoided. Sometimes there isn’t a group that includes/excludes workers as required. As people move through the organization, they will retain shared access to the report, even if their security group no longer provides access to the data source. We have a custom report identifying terminated employees who have been granted individual security to clean those up.

Tip #2 - Reuse Old Security Groups – I’m sure none of you have ever done this, but occasionally I will create a security group and then realize that I don’t need it or it won’t meet the needs I thought it would. Or maybe a security group is no longer required for another reason. Security groups can’t be deleted once they are created. You’re stuck with them, and they can start to pile up. Discarded security groups can provide access that you don’t intend. So, let’s recycle. When we encounter this situation, we do the following steps.

Rename the security group to *** Available for Reuse with a sequence number if one already exists for that security group type. This identifies it as one that should no longer be used.
“Neuter” the security group by removing all security domains and BP policy permissions. If assigned, this makes the security group meaningless and doesn’t provide access inadvertently. Ensure you activate the security policy changes.
Remove security group members. This is easiest for user-based groups. For others, based on criteria, remove the criteria to minimize membership. In the example below, the role is also made available for reuse and emptied of members.

Next time we need to create a new security group, we look for one that is available for reuse and repurpose it for the new security group’s purpose. That removes one more unused security group and recycles it for a new life.

Tip #3 - Security Timestamp documentation – You must enter a description every time you activate a domain security policy change. It is easy to throw junk in there and move on with life, but we get value from investing some effort in this step. You should use a semi-standard format (example described below), to help document the reason behind the changes. You can use security audit reports to see what happened and when. But these timestamps can provide the “why.”

Initials – Identifies who made the change
Security Group(s) impacted – Identifies the security group(s) impacted
Domain(s)/BP Policies impacted – Identifies the BP policy changes that are being made
Access granted/removed – Describe the changes for the groups on the domains/BP policies
Ticket reference and description – reference the associated story in your ticketing system and provide a more narrative description of the changes and what drove them.

Sometimes these get more complex when adding/removing multiple groups/domains, etc., in the same activation. Still, we are all dedicated to communicating the change and its intent using this format.

Tip #4 - Removing unnecessary domain/BP security policies– This is related to a more general review and evaluation of groups and what they need. You can review the details on the security group itself or look at the Action Summary for Security Group report to get a complete overview of domains, secured items, and BP actions granted to the security group.

Does the HR Administrator need Get and Put integration permissions for Set Up: Background Checks? Are they actually using an API or an EIB to set up background check configuration? If not, remove the integration permissions and button up one more potential access point you probably didn’t know existed.
Much of what was set up during implementation may not be relevant anymore.

Conclusion:

In summary, every organization should make an effort in identifying and automating system hygiene practices to ensure that the system doesn’t become cluttered and that security risks are discovered and resolved in advance. The security aspect of those practices is only a portion of the efforts needed to keep a system clean. You should also track and clean up unused and duplicated fields (from report copies, etc.) I encourage you to take some time and dig into some of these topics and invest in cleaning up a bunch of small messes now to avoid big messes in the future.