Look to the Mainframe
In order to meet GDPR compliance, organizations need to demonstrate they are putting forth their best possible effort in protecting customer data. But “trying” does not mean “doing,” and even though they may have addressed the two most well-known and understood mandates – the right to erasure and the right to consent – many organizations still have a lot of work to do.
The EU’s GDPR compliance mandates officially took effect on May 25, following four long years of intense debate and preparation. The scope of GDPR and its most clear-cut requirements – the “right to consent” and the “right to be forgotten” – is reaching deep into many far-flung and sometimes unexpected areas of the enterprise.
Fortunately, achieving GDPR compliance does not require organizations to have each and every one of these dark corners identified and addressed. Rather, achieving GDPR compliance means an organization has demonstrated they are putting forth their best possible effort when it comes to protecting sensitive customer information. That’s a good thing, because the reality is that more areas and processes impacted by GDPR are likely to come to light over time. Several of these are based in the mainframe and mainframe-related processes, as this platform continues to be a central repository for huge volumes of sensitive customer information. Consider the following:
The Need for Test Data Privacy
Studies(1) have shown that a very high percentage of organizations needing to comply with GDPR use live customer data when testing applications. They believe the use of live data ensures the most reliable testing and accurate representation of their production environment and shows how an application will perform “in the wild.” Today’s modern applications increasingly span multiple platforms, starting on front-end systems of engagement (like web servers) and reaching all the way back to the back-end system of record (the mainframe) for transaction completion and recordkeeping. This makes mainframe data an essential component of the end-to-end application testing process.
The problem with this approach is that unless customer consent is explicitly secured to use their data in testing, this is a direct violation of the “right to consent.” There are simple techniques to circumvent the need for consent, including data masking, which can be as fast and easy as scrambling data in a database’s “name” field in order to disassociate real customers with their personally identifiable information. As long as it is reasonably difficult to associate customers with their true identities, live customer data can continue to be used in testing, without the need to secure consent.
Unfortunately, only a minority of companies anonymize or leverage other techniques to depersonalize customer data before using it in application testing environments.(2) The trend toward faster software development overall will only lead to faster, more frequent testing cycles and, in turn, a greater opportunity for sloppiness and noncompliance risk. Development teams need the ability to access reliable, secure test data, quickly and efficiently.
Running Analytics Against Customer Data
Data analytics are an invaluable resource for many companies, helping them identify trends and patterns across their customer base in order to maximize operations and profits. Many analytics projects are run on the mainframe, against the vast customer data sets residing there.
The challenge with GDPR is that even if a customer consents to having their data used in an analytics effort, such consent does not have a time stamp to distinguish which customer interactions with the company are fair to include in broad analysis efforts and which ones aren’t (i.e., those interactions that took place before the consent was granted). Additionally, GDPR has no “grandfather” provision making it legal for a company to include all of a customer’s historical interactions in their successive analysis efforts, once consent is given.
Many companies are blissfully unaware that they may be doing something wrong by running analytics against historical databases. Once again, a possible solution is data masking – disguising individuals by randomly re-assorting values in one’s own database. This type of masking can be helpful for retroactive analytics aimed at identifying broad trends across a customer base – for example, which products are top sellers in various regions.
However, there are limits. Currently, masking can only be used to disguise copies of live data before batch analytics projects, though not live production data as it travels across the network. This means masking falls short when it comes to applying real-time analytics at the point of customer interaction. For example, a service agent speaking with a customer cannot access that customer’s buying history for real-time analysis supporting point-of-purchase upsell opportunities without having and using the true name tied to that purchase history.
Managing Authorized User Credentials
Another GDPR tenet is that even when customers provide consent for their data to be used in ancillary business processes, this data should be retained for the least amount of time possible. This aligns with the long-held security best practice of “least privilege,” which restricts worker access only to those resources absolutely required for them to do their jobs.
Mainframe user organizations must ensure worker credentials are properly managed, especially with the crown jewels of enterprise data continuing to reside there. The challenge is that when workers change roles, they are often not removed from their previous role definitions and privileged access points, but simply given new ones. Since they may no longer need their old credential sets, this represents a significant security threat, as over time, the number of workers with access to mainframe data (often unauthorized) will accrue, elevating risk.
For those individuals who are rightfully authorized, it is also important to carefully monitor their behavior and interactions with mainframe data sets – going beyond just understanding the start and stop time of their sessions to precisely what data fields were accessed and manipulated, with a high degree of granularity.
Insider threats are the biggest cybersecurity threat faced by organizations today,(2) with many threats deriving from employees unwittingly engaging in risky behaviors. Many may view employee monitoring as a “big brother” behavior, but with so much sensitive data continuing to reside on the mainframe, it is vital to protecting both the enterprise and workers.
Greater levels of granularity can also ease the time and work involved in reporting breaches. Achieving GDPR compliance does not mean you will never have a breach; it only shrinks the time window required to report the breach – to 72 hours after becoming aware of it. If an organization can verify that only one particular data set within a larger database was accessed/exposed, this can greatly limit the number of individuals that must be notified, as well as the work, time and resources this process requires.
Achieving GDPR compliance does not mean that an organization has crossed the finish line or that it’s immune to risk. For most organizations, May 25 was just the starting point, and they must continue to identify areas of the enterprise where the GDPR mindset – protecting sensitive customer data above all else – must be applied. The mainframe, and processes and procedures involving mainframe data, are a logical and solid place to continue the process of becoming more universally GDPR-compliant across the entirety of enterprise operations.
John Crossno is the Product Manager for Compuware’s Security Solutions. In addition to his history of a pragmatic approach to product management in various mainframe software and storage environments, he has an extensive background in development and field technical services. 
