Data security is one of the most important priorities for any organization. Loss of employee, business, or customer data can have drastic consequences ranging from negative impacts on brand reputation, all the way to the complete destruction of the business. Security breaches undermine trust and can have both short-term and long-term impacts that are irreparable.
At Dispatch, we work with our clients to design and implement workflow automations that must be built with a security-first mindset. Many of our projects center around Workday, and because many HR and HRIS practitioners are not cybersecurity experts, we often get asked to guide our clients through security topics.
The purpose of this article is to give practitioners an overview of how Workday keeps data secure and what security controls are in the hands of Workday administrators. Workday has world-class security controls, and there are a lot of security configuration options at the administrator level that require an understanding of Workday’s security philosophy and framework. It’s vital to understand the security and operational implications of security settings and controls to ensure your instance of Workday is configured to meet your security and privacy requirements at your organization.
Workday’s security framework ensures data security and data privacy by employing security measures at the following levels:
Let’s talk through each of these in a bit more detail below.
The largest security risk factor in most organizations is at the human level. Hackers and malicious actors have long recognized that the easiest way to access an organization’s data is through its people. Phishing, spear-phishing, vishing, water-holing, and plain old spam are used to probe and exploit weaknesses at the organizational level. Malicious actors see the data contained within Workday as a valuable target.
Creating, training, and enforcing robust data security policies is a foundational element of keeping data secure. While most organizations have data security policies, ongoing training and reinforcement can’t be emphasized enough. It only takes a moment of inattention to click on a malicious attachment or inadvertently share credentials through an unsecured channel. Often employees will circumvent security procedures to be more “efficient,” often because they don’t realize the potential consequences of their actions.
We recommend Workday administrators understand how users interact with Workday in their various roles and ensure Workday is configured to comply with your corporate security policies. Similarly, HRIS should contribute to security policies and training content. Very few applications have users that extend company wide as Workday does, and fewer still contain the sensitive business and PII content as Workday.
Training and reinforcement of security policies and procedures should explicitly include procedures for how users, managers, and administrators log in to Workday and interact with the data. Workday should also be included in the scope of internal security audits.
Because Workday is the source of truth for organizational data and a destination for data flowing from other applications and services, security controls should include the interfaces between Workday and the outside world. This is critical; it doesn’t matter how secure Workday’s security is at the user interface level if integrations are not architected to be secure or reports and data extracts from Workday are not encrypted and treated as secure and confidential documents.
Understanding Workday’s Architectural Security
Most SaaS applications, including Workday, define their customers as the data controllers, while Workday is the data processor. This means that the customer has full control of all the data entered as well as all setup and configurations. Since the customer controls the data, they do not have to rely on Workday for the following tasks:
- Assigning security authorization and establishing roles.
- Creating new reports and worklets.
- Configuring business process flows, alerts, rules, and more.
- Creating new integrations with Workday utilities or incumbent tooling.
- Changing or creating new organizational structures.
- Monitoring all business transactions.
- Looking at all historical data and configuration changes.
You, the customer, have the responsibility to define and maintain the above security configurations. While Workday has defaults and recommendations, it is ultimately up to you and is your responsibility to ensure Workday security is configured for your needs. You need to understand the way Workday security works and what the impacts of these configuration options have on your business operations and security stance.
Workday encrypts every attribute of customer data before it’s persisted in the customer’s tenant. Since Workday is an in-memory, object-oriented application instead of a disk-based relational database management system (RDBMS), it can provide the highest level of encryption commercially available. Workday uses the Advanced Encryption Standard (AES) algorithm with a key size of 256 bits and a unique encryption key for each customer.
Transport Layer Security (TLS) protects user access via the internet, helping to secure network traffic from passive eavesdropping, active tampering, or message forgery. File-based integrations can be encrypted via “Pretty Good Privacy” (PGP), or a public/private key pair generated by Workday using a customer-generated certificate. Web Services Security (WS-Security) is also supported for web services integrations to the Workday API.
A weak point we often see is how companies transmit files to and from Workday. It is not uncommon to see unencrypted and uncontrolled files and reports generated by Workday and shared via insecure channels. This should be seen as unacceptable. Files transferred or transmitted to or from Workday must be encrypted. The most common way of protecting files generated through integration is using a PGP public/private key pair. Files should also only be shared via secure channels, such as SFTP data transfers, and NEVER emailed or transmitted using other methods.
What is PGP File Encryption?
PGP is a public key encryption standard. Generally, there is a public key and a private key. The Public key is used for encryption. Think of this as the lock on your data. The Private key is used for decryption. Think of this as your key to opening the lock on your data. So, the system that decrypts the data puts the lock on your data and sends the associated public key for encryption, which is basically the key for opening the lock on the data.
Managing Log Files
Another common security vulnerability that we see specifically with custom integration tools like Workday Studio is logging sensitive information in the log files of the integration. This can lead to the exposure of PII and other confidential data if the log files are intercepted by a malicious vector. Workday does not encrypt log files, and if sensitive information like encryption keys or passwords is included in a log file, this can lead to a more serious security breach.
As a best practice, we recommend that all Studio clar files that are deployed to production environments be stripped of all logging components. Also, for the integration launch parameter or integration attribute, make sure the data type is set as “password” instead of “text” so that the sensitive information is masked with asterisks.
Named Accounts vs. Integration System User Accounts
We have come across many scenarios where integration schedules and integration runs are owned by a named personal account instead of an Integration System User (ISU) account. We highly discourage using named accounts for any operational processes. By using named accounts, you risk unexpected interruptions to your integration schedules if the named user’s account expires or the person leaves the organization. It is always a best practice and recommended approach to ensure all integration schedules and events are run as an ISU.
A big advantage of ISUs is that ISU account passwords can be randomly generated and do not need to be stored. Since the passwords are randomly generated and stored internally within Workday, the chances of the account getting compromised are minimal.
New Integration Security Reviews
Integrations should be considered custom-coded solutions that manipulate sensitive data, and therefore we recommend that they be subject to architectural and code reviews, including security reviews, prior to go-live. The exact method and criteria for these reviews will be based on each company’s security policies, but we recommend that these reviews address the following, at a minimum:
- Are systems in scope accessed using secure methods (e.g., no FTP file transfers allowed)?
- Are there adequate controls on credentials (e.g., no unmasked credentials, no hard-coded credentials, secure credential management methods with limited access)?
- Are downstream applications secured with limited access rights to PII/PHI and other sensitive data fields? Is there any risk that this data may be further propagated to other systems (e.g., data warehouses)?
- Do development environments contain PII/PHI or other sensitive data, and if so, are the developers authorized to access this data?
- Are data flows encrypted in flight and at rest, and are individual files encrypted?
- If data flows across borders, do any data sovereignty regulations apply?
- Do any error or exception handling alerts or notifications contain PII, PHI, or other confidential data?
- Are all systems, including the integration platform, accessed with a least privilege model?
- Does the operating model potentially expose confidential data to unauthorized users or support personnel?
- Is there a formal code review process to assess the security characteristics of the integration (e.g., OWASP Top 10)?
- Does the integration design generate logs and event records to facilitate auditability and traceability?
Inadequate change management for integrations in production is another common security vulnerability. In many cases, security reviews are not done when changes or updates are made to existing integrations. We’ve seen situations where sensitive data was added to integration outputs that were not part of the initial go-live requirements. While there might be business rationales for these changes, we believe it is imperative that security reviews be conducted, and potential new vulnerabilities flagged and addressed. The reality for many change requests is that these mini projects do not have the same level of governance and controls as larger projects, and developers may be tempted to take shortcuts that can reduce security compliance for the sake of speed.
Permissions and User Access
Workday security access is role-based, supporting the Lightweight Directory Access Protocol (LDAP Delegated Authentication), Security Assertion Markup Language (SAML) for single sign-on, and x509 certificate authentication for both user and web service integrations.
Single-Sign-On Support (SAML) allows for a seamless, single-sign-on experience between the customer’s internal web portal and Workday. Customers access their company’s internal web portal using their enterprise username and password and are then presented with a link to Workday, which automatically gives them access without having to log in again. Workday also supports an alternative approach to SAML called OpenID Connect.
Workday Native Login
For customers who wish to use native login, Workday only stores the Workday password in the form of a secure hash as opposed to the password itself. Unsuccessful login attempts are logged as well as successful login and logout activity for audit purposes. Inactive user sessions are automatically timed out after a specified time, which is customer configurable by the user.
Customer-configurable password rules include length, complexity, expiration, and forgotten password challenge questions.
Our general recommendation is to use Single-Sign-On whenever possible. This has much stronger governance than using native logins and is far better for automated identity management. If you do elect to use Workday native logins, we believe MFA should be mandatory. In many cases, companies end up with SAML as the standard approach, with exceptional access provided natively.
Multifactor Authentication (MFA)
Workday recommends that customers use multifactor authentication (MFA) and allows customers to bring in their own MFA provider that is backed by the time-based one-time passcode (TOTP) algorithm. With this setup, customers can easily integrate MFA providers with the native Workday login. Workday also allows end users of customers to receive a one-time passcode delivered via an email-to-SMS gateway mechanism. Lastly, Workday supports challenge questions as an additional mechanism to prove a user’s identity.
Organizations that use SAML can require an additional level of verification for critical functionality in Workday. Step-up authentication allows customers to force a secondary authentication factor that users must enter to access those items.
Workday configurable security enables security administrators to control the items users can view and the actions they can perform in their tenant. The administrators can manage security access in a scalable way by establishing security groups. Each security group can have items and actions defined by administrators, and then users are added to or removed from security groups as needed. Using security groups enables automations to be established if users change roles or organizations.
Workday’s Approach to Operational Security
Like all modern enterprise SaaS applications, Workday is hosted in state-of-the-art data centers designed to protect mission-critical computer systems with fully redundant subsystems and compartmentalized security zones. Workday data centers adhere to the strictest physical security measures, including, but not limited to, the following:
- Multiple layers of authentication for server area access.
- Two-factor biometric authentication for critical areas.
- Camera surveillance systems at key internal and external entry points.
- 24/7 monitoring by security personnel.
All physical access to the data centers is highly restricted and stringently regulated.
Workday has established detailed operating policies, procedures, and processes designed to help manage the overall quality and integrity of the Workday environment. Workday has also implemented proactive security procedures, such as perimeter defence and network intrusion prevention systems (IPSs).
Network IPSs monitor critical network segments for atypical network patterns in the customer environment as well as the traffic between tiers and services. Workday also maintains a global Security Operations Center 24/7/365.
Workday has implemented an enterprise Secure Software Development Life Cycle (SDLC) to help ensure the continued security of Workday applications.
This program includes an in-depth security risk assessment and review of Workday features. In addition, both static and dynamic source code analyses are performed to help integrate enterprise security into the development lifecycle. The development process is further enhanced by application security training for developers and penetration testing of the application.
Workday contracts with third-party expert firms to conduct independent internal and external network, system, and application vulnerability assessments.
The firm performs testing procedures to identify standard and advanced web application security vulnerabilities, including, but not limited to, the following:
- Security weaknesses associated with Flash, Flex, AJAX, and ActionScript.
- Cross-site request forgery (CSRF).
- Improper input handling (such as cross-site scripting, SQL injection, XML injection, and cross-site flashing).
- XML and SOAP attacks.
- Weak-session management.
- Data validation flaws and data model constraint inconsistencies.
- Insufficient authentication or authorization.
- HTTP response splitting.
- Misuse of SSL/TLS.
- Use of unsafe HTTP methods.
- Misuse of cryptography.
External vulnerability assessments scan all internet-facing assets, including firewalls, routers, and web servers for potential weaknesses that could allow unauthorized access to the network. In addition, an authenticated internal vulnerability scan logs into the device and performs detailed checks on the system patch level, permissions, installed applications, and more. This is similar to having the keys to the house and looking inside for problems.
Additional Workday Security Controls
There are a few additional security controls that administrators can configure based on the policies they wish to implement:
You can mask sensitive data in your tenant. Data masking either masks or substitutes dummy values for actual values to hide data from Workday users. Data masking also hides profile pictures from these users. Workday applies these restrictions when displaying data to individual Workday accounts and security groups with data masking enabled:
- ***** replaces text values in fields.
- 01/01/2000 or ***** replaces date values.
- ***** replaces numeric values.
- Profile pictures are hidden.
- You cannot save changes if any field contains sensitive data.
While data masking is not enabled by default, we recommend turning on this functionality whenever possible. One of the first principles of data privacy is to minimize exposure to Personally Identifiable Information (PII), and data masking helps achieve this. It will require thought regarding what to mask for each security group or user.
Workday customers may have an obligation under data protection laws to remove personal data when it is no longer needed. In the past, you have had to contact Workday to remove this data. Now Workday has released functionality to enable customers to directly address this requirement. Purge Person Data enables you to purge data based on criteria you set. You select the person whose data is to be purged by creating a custom report that filters the results to include those individuals. By selecting the appropriate data types within the Purge Person Data task or within a purge plan, you choose which data will be purged for the people returned by the custom report you have created.
Workday’s Data Scrambler Framework allows you to replace elected fields permanently and irreversibly with randomly generated new values in a Workday implementation tenant. The scrambler alters the original values in such a way that they cannot be easily derived from the scrambled data. To perform this operation, you need to create Scramble Plans and execute them. Data scrambling is especially useful for development projects where you are giving access to external implementers. By scrambling data in development and test tenants, you protect sensitive data and PII from being exposed to developers but still provide these developers with “fake” data in the correct formats to complete test and validation cycles. Data scrambling can also prevent data leakages from non-production tenants through integration output files, as the values in the integration output will also be scrambled.
Workday Security Configuration can feel like a maze with all the different security controls and tools at your disposal. Understanding and planning on an effective framework and solution is extremely important to ensure data privacy and maintain the security of your core HR application. There is no one-size-fits-all strategy for Workday Security, so it is extremely important for HRIS administrators to be knowledgeable about security vulnerabilities, best practices, and company security policies.
Workday security controls can be especially challenging if you are trying to navigate or explore them on your own. Dispatch has resources who are experts in this field. We can be a resource if you have Workday security questions and can assist you in establishing the right security configuration for your organization. We can also conduct a review of your existing security profiles and provide you with a vulnerability assessment and recommended courses of action.