The GDPR Is New, but the Requirements Aren’t
Data breach studies are revealing shocking statistics. In a 2017 study (ibm.co/2Bir60B), IBM and Ponemon Institute found that the average time it took to discover a data breach was 191 days. In addition, a recent Protenus study (bit.ly/2jUv7gI) found that it took one healthcare organization over four years to discover a data breach.
With digital modernization fully in play, more sensitive data is shared online and stored in your company’s databases. And according to the latest European Union (EU) law—General Data Protection Regulation (GDPR)—your organization is now legally culpable if you suffer one of these data breaches and any of the data belongs to EU citizens. The most taxing part of GDPR is the 72-hour requirement to report breach activity to the supervisory authority. Given the aforementioned statistics, this part of the regulation is especially problematic.
How Is GDPR Unique?
GDPR is different because it’s law. However, it’s not that different in that it asks you to do the same things other data security compliance standards require—monitor the event log data, have an audit log of that monitored activity, archive the data with encryption and prove you’re doing all of this along with a few other stipulations. The main difference is that GDPR was created by the government to protect the personal identity information of its citizens, wherever they or their data might reside. The other data security standards are mostly managed by companies (PCI DSS and other major credit card standards) or organizations (ISO 27001).
GDPR also comes with hefty penalties and fines for habitual offenders that can tally up to 4 percent of a company’s annual revenue, with a cap at 20 million euro. If you don’t have up-to-the-second event log management across both mainframe and Windows*/UNIX* systems in your Security Operations Center (SOC), the 72-hour advisory rule presents a serious problem for your organization. To stay in front of the GDPR’s 72-hour reporting requirement, you need end-to-end visibility to all data stores that can be accessed across all OSes.
The Mainframe and GDPR
Many in the mainframe world have a false sense of security about the data they manage on z/OS*. However, GDPR doesn’t stipulate managing data security by specific OSes. It’s imperative that we communicate to the marketplace that when GDPR states (bit.ly/2L17ZK6) “such processing of personal data should be adapted to the principles and rules established in this Regulation,” it doesn’t translate to “all the data that’s not on a mainframe because you guys are so good at data security.” GDPR, like all other data standards, stipulates the need to secure all data—wherever it resides, on whatever systems. We need to break down this false sense of security on the mainframe.
Mainframes today process approximately 80 percent of the world’s corporate data (bit.ly/2GivsCY), are used by 71 percent of the Fortune 500 (bit.ly/2KpCVT7) and according to IBM, manage 29 billion ATM transactions per year—worth nearly $5 billion per day (ibm.co/2fzkphp). They contain the world’s most sensitive data, and hackers are aware of that. Whenever you use your credit card, chances are your data touches a mainframe.
Protecting the mainframe should be every enterprise’s first priority. With all of this information processed across mainframes, it’s unlikely we’ll see the end of them anytime soon. We see customers log data every day, and the data says the mainframe is a highly targeted asset by hackers. A serious mainframe breach could be the end of your organization’s good brand reputation and its leaders’ careers, so there’s a lot at stake when it comes to your GDPR compliance.
Two Things to Know About Mainframe SIEM Practices
In order to keep tabs on your data and who’s accessing (or even looking at) your data, you need a 360-degree view of all user activity surrounding it. At the heart of these security information and event management (SIEM) practices is log management in conjunction with event correlation. Here are two things to know about SIEM:
- Collecting event logs from endpoint devices, firewalls, routers/switches, desktops, servers and applications (log management), and then correlating them against norms of user behavior (events) are the basics of SIEM. But the volume of metadata surrounding GDPR—names, photos, email addresses, bank details, social media posts, medical information or computer IP addresses—can slow systems resources. Your correlation engine doesn’t need all of the log data, so you’ll want to get a handle on your process and find a security system with efficient indexing and filtering rules to help manage log volume.
- All of this event logging and event correlation must be rolled up into a single view of data security truth within your IT SOC. Securing your data means knowing and visualizing enterprise user interactions to your data in real time and forwarding the events in real time to your SIEM. Theoretically, we’ll never be able to build a hack-proof data store because humans are prone to mistakes. The latest Verizon Data Breach Investigations Report (bit.ly/2tWIWCZ) reveals that 81 percent of hacking-related breaches leveraged stolen and/or weak passwords. Security industry pundits agree that breach is inevitable, and the focus should be on real-time threat visibility with instantaneous notifications of a breach, followed immediately by corrective action to stem the bleeding (the EU, with GDPR, believes this too).
The Importance of a Security Policy
A security policy based on 100 percent visibility of activity across all the threat vectors in your SOC makes this possible. This visibility gives GDPR data protection officers a path to validate the technical and organizational measures they’re undertaking to maintain compliance. In the event of breach, the officer will also have an audit trail of forensics with which to determine the who, what, when and where of the breach.