Guidelines for GDPR readiness

Information about features that you can configure, and aspects of using the product that can help your organization with GDPR readiness.

Notice:

This document is intended to help you in your preparations for GDPR readiness. It provides information about features of Decision Runtime for z/OS that you can configure, and aspects of the product’s use, that you should consider to help your organization with GDPR readiness. This information is not an exhaustive list, due to the many ways that clients can choose and configure features, and the large variety of ways that the product can be used in itself and with third-party applications and systems.

Clients are responsible for ensuring their own compliance with various laws and regulations, including the European Union General Data Protection Regulation. Clients are solely responsible for obtaining advice of competent legal counsel as to the identification and interpretation of any relevant laws and regulations that may affect the clients’ business and any actions the clients may need to take to comply with such laws and regulations.

The products, services, and other capabilities described herein are not suitable for all client situations and may have restricted availability. IBM® does not provide legal, accounting, or auditing advice or represent or warrant that its services or products will ensure that clients are in compliance with any law or regulation.

Table of Contents

  1. GDPR
  2. Product Configuration - Considerations for GDPR Readiness
  3. Data Lifecycle
  4. Data Collection
  5. Data Storage
  6. Data Access
  7. Data Processing
  8. Data Deletion
  9. Data Monitoring
  10. Responding to Data Subject Rights

GDPR

General Data Protection Regulation (GDPR) has been adopted by the European Union ("EU") and applies from May 25, 2018.

Why is GDPR important?

GDPR establishes a stronger data protection regulatory framework for processing of personal data of individuals. GDPR brings:
  • New and enhanced rights for individuals
  • Widened definition of personal data
  • New obligations for companies and organizations handling personal data
  • Potential for significant financial penalties for non-compliance
  • Compulsory data breach notification

Read more about GDPR

Product Configuration - Considerations for GDPR Readiness

Offering Configuration

Terminology

  • Customer: individual or business which purchases, installs, configures, and operates Decision Runtime for z/OS.

Data handling in Decision Runtime for z/OS

In Decision Runtime for z/OS, data resides in the following databases or directory services:
  • The Decision Runtime for z/OS databases stores rule projects, rule artifacts, and user roles and permissions.
In addition to these three centralized databases, user data and configuration data can be located in other files. For example:
  • Deployment descriptor files in the application server's file directory
  • Decision Runtime for z/OS related files, where the customer's project files are stored locally on the workstation.
  • Other resource or property files. They can be configured or updated when users want to isolate credential or configuration information in these files to add more protection.
  • Log files. Some log files that are generated by the Decision Runtime for z/OS applications might contain personally identifiable information (PII) for debugging purpose. A user (user name) can be often identified as the author of certain actions, which is traced or logged. Aside from the user name, the PII should not be in the log files, but the customer must verify their content.

Data privacy and security

The customer is responsible for data privacy and security of their LDAP and should follow the secure privacy and protection guidelines.

General privacy and security rules

  • Access control must be effective and enforced properly.
  • Credential strength must be high and strong.
  • Default passwords should be removed or at least changed. Decision Runtime for z/OS is delivered with default credentials that are created for testing purposes. For more information, see the following topics:
  • Encryption or hashing (even hashing with salt) of user passwords in LDAP should be implemented or configured.

Customer's directory service

  • Access control must be effective and enforced properly.
  • Encryption or hashing of credential information, such as passwords, should be implemented or configured.
  • Backups and restoration tests must be conducted regularly.

Personally identifiable information (PII) in the files

Any PII, credential information, or configuration information that is personal or sensitive should be isolated in specific files. Files that might contain PII, such as ANT, resource, or property files, must be protected by setting file permission. Implementing additional controls, such as access controls, logging, or encryption, are required to provide appropriate level of protection.

Decision Runtime for z/OS

For Decision Runtime for z/OS, the security framework is provided by certain systems, such as Resource Access Control Facility (RACF®), to build security features. RACF provides various security functions, such as:
  • Authenticating and authorizing users
  • Protecting system resources
  • Logging accesses to protected systems and resources
  • Certificate management

The users of Decision Runtime for z/OS must use this type of standard security framework in their Decision Runtime for z/OS applications.

Security as a whole

Security and data privacy of Decision Runtime for z/OS depends on the configuration of underlying software and the security features provided by the application server. The Decision Runtime for z/OS data privacy and security should be considered and implemented in conjunction with the security features of Java™ and the application server.

Decision Runtime for z/OS also uses a number of third-party JAR files. Decision Runtime for z/OS keeps the JAR files as current as possible when there are security patches according to the product release planning and capability. When a JAR file is exposed to a new vulnerability, the Decision Runtime for z/OS product team assesses the impact and might provide intermediate fixes based on the IBM PSIRT process.

Data Lifecycle

The data lifecycle of Decision Runtime for z/OS corresponds to the lifecycle of rule projects:
  • The customer installs the product and does an integration of their LDAP.
  • The customer provisions the databases during the product configuration.
  • The customer imports user information into a collaborative environment for rule authoring.
  • Users collaborate to build rules. Rule projects are created with the data to be protected.
  • Users deploy the rule projects.
  • Integrators invoke the rule projects by passing the payload.
  • The projects are decommissioned.
  • Data can be backed up and securely deleted from the disk.

Data Collection

In general, data used for basic authentication is brought by the customer's directory service or LDAP. This data is required when the customer uses Decision Runtime for z/OS. LDAP is integrated into Decision Runtime for z/OS while Decision Runtime for z/OS applications are being deployed. LDAP is managed outside of Decision Runtime for z/OS, and any changes will be synchronized with Decision Runtime for z/OS.

The databases for Decision Runtime for z/OS and Rule Execution Server are provisioned by the customer. Decision Runtime for z/OS stores rule projects and decision services in these databases. The databases evolve with the rule projects and deployment of the decision services:
  • The databases must be maintained throughout the lifecycle of the Decision Runtime for z/OS product use.
  • Data must be backed up regularly based on the customer's business needs and risk level.
  • When Decision Runtime for z/OS is no longer used, the databases can be securely deleted or backed up for future use. The customer is responsible for deleting and backing up the databases.
  • As a data controller, the customer should provide means to satisfy data access requests for personal information or other compliance requests.

Decision Runtime for z/OS requires basic personal data for authentication in its applications.

In collaborative environment, certain user information is collected, including:
  • User name
  • User ID (email address)
  • User's photo (optional)
  • User's role and assigned permissions
User activities can be tracked during rule authoring and governance phases.

Data Storage

The databases and LDAP should be protected by using appropriate security controls. This includes but is not limited to:
  • Encryption at rest, with keys stored separately in a secure location with a key management tool. The encryption can be done at database or file system level. LUKS (Linux® Unified Key Setup) is one sample technology for achieving this encryption.
  • Access controls to the databases.
  • The customer's IT infrastructure and security topology should implement:
    • Tracking and logging of user activities
    • A security event management system (SIEM) to monitor the connections and security events
  • Encryption of the data backups

Data Access

The customer should implement protective measures concerning data access.
  • Access control to the databases should be in place and effective.
  • Decision Runtime for z/OS provides API (REST and SOAP) to access project data and runtime decision services. The customer should consider implementing certain protections, including:
    • Use of HTTPS for all the connections
    • Use of basic authentication or other authentication methods
    • Proper authorization, so that only authorized roles can use the corresponding API
  • The runtime REST API can be protected.

Data Processing

When rule projects are deployed, a new endpoint for each decision service becomes available. The customer invokes a service by passing payload and obtains decisions.

The customer should consider implementing the following security guidelines when invoking the REST APIs with Decision Runtime for z/OS:
  • HTTPS with secure ciphers should be used.
  • The input payload should be properly sanitized.
  • The output from Decision Runtime for z/OS should be manipulated carefully, although it has been sanitized by Decision Runtime for z/OS.
  • The security infrastructure should protect against DOS attacks.

Data Deletion

Right to Erasure

Article 17 of the GDPR states that data subjects have the right to have their personal data removed from the systems of controllers and processors - without undue delay - under a set of circumstances.

The customer should implement appropriate controls and tools to satisfy the right to erasure.

The Decision Runtime for z/OS offering does not require any special method for data deletion. The customer is responsible for implementing appropriate methods for their storage media to securely delete data, which includes media zeroization if necessary. The customer is also responsible for deleting data.

Data Monitoring

The customer should regularly test, assess, and evaluate the effectiveness of their technical and organizational measures to comply with GDPR. These measures should include ongoing privacy assessments, threat modeling, centralized security logging, and monitoring among others.

Responding to Data Subject Rights

The personal data stored and processed by Decision Runtime for z/OS falls under the following categories:
  • Basic personal data, such as names, user names, and passwords
  • Technically identifiable personal information, such as IP addresses and hostnames to which user activity could potentially linked
  • Personal data that could be stored in the text of the rules. As a rule author, the customer should control the rules they write.
  • Data stored in Decision Warehouse. The customer can configure what information should go into Decision Warehouse.
This data is essential to the operation of an effective decision system. The customer should consider and implement methods so that they can securely and responsibly respond to a request to:
  • Delete data
  • Correct data
  • Modify data
  • Extract specific data for export to another system
  • Restrict the use of the data within the overall system