CyberWire Daily - Settling in with GDPR. [CyberWire-X]

Episode Date: December 3, 2018

In the second episode of our new, four-part series, called “Ground Truth or Consequences: the challenges and opportunities of regulation in cyberspace,” we take a look at the impact GDPR has had since it's implementation in May 2018. Joining us are Emily Mossburg from Deloitte, Caleb Barlow from IBM and Steve Durbin from ISF. Later in the program we'll hear from Jason Hart, CTO for enterprise and cybersecurity at Gemalto. They're the sponsors of this show. Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyber Wire Network, powered by N2K. Thank you. Are things proceeding as expected and have there been unintended consequences? And what's the best strategy for compliance in a rapidly evolving global regulatory environment? A program note, each CyberWire X special features two segments. In the first part of the show, we'll hear from industry experts on the topic at hand. And in the second part, we'll hear from our show sponsor for their point of view. And speaking of sponsors, a word from our sponsor, Gemalto. Your enterprise is rich with sensitive data at rest and in motion throughout the network. But what happens if that sensitive data isn't secure or if it's improperly accessed? We're guessing that regardless of what defenses you

have currently implemented, the thought of your data being stolen or manipulated keeps you up at night. Gemalto tackles the two main causes of cyber attacks, identity theft and data breaches. They do this by providing next-generation digital security built from two technologies, secure digital identification and data encryption. Gemalto already operates these solutions for many well-known businesses and governments, protecting trillions of data exchanges. And as independent security experts, they guarantee digital privacy and compliance with data protection regulations. Gemalto puts you back in control of your own data.

Visit Gemalto today to learn more about their access management and data protection solutions. You can also check out the most recent findings from the Breach Level Index, which tracks the volume and sources of stolen data records. Go to gemalto.com slash cyberwire to subscribe and learn more. That's gemalto.com slash cyberwire to subscribe and learn more. That's gemalto.com slash cyberwire. And we thank Gemalto for sponsoring our show. I do think that we've seen some perhaps byproduct benefit in terms of this global consistency that we're starting to see come about. That's Steve Durbin. He's managing director of ISF, the Information Security Forum.

They're a global authority on cyber, information security and risk management. I'm not going to say that it's the best piece of legislation that could have been created, but I think it's not bad. I think that it has caused organizations to react in a way that some of us would have liked them to react without the regulation being there. But if this is what it's taken to bring about a heightened degree of cyber awareness and security awareness, I think that's a good thing. If it's brought about a little bit more preparedness for organizations and how they respond to breaches and keep people informed and protect personal data, I think that's a good thing, too. I think one of the things we look at when we think about GDPR is that obviously the focus here is on protecting privacy, particularly of consumers.

That's Caleb Barlow. He's the VP of Threat Intelligence for IBM. It comes with a pretty stiff penalty. So, you know, for example, if a company doesn't disclose to European regulators within 72 hours, some of those penalties can be quite severe. And not only do those get people's attention, but they also drive some rather interesting, unforeseen consequences. We're still seeing this. What is this truly going to mean? How heavy are the fines? That's Emily Mossberg. She's a principal with Deloitte Risk and Financial Advisory. She leads the advise and implement practice within their cyber risk

services. I still think that we're a bit in the wait and see period. I mean, the first actual enforcement happened at the end of September. Now we're just now in November. I think that there's still some wait and see attitude. I think one of the challenges that every company is facing is that if you've just found out about a breach, you don't typically know a whole lot within that first 72 hours. And if you think of all of the emotion that's going on at that time, you're trying to figure out, are the bad guys still on the system? Have we contained this? How much is affected? And you may, you know, there's a very good chance you may not know.

You may know that you've got a problem, but you may not know if data is actually leaked out yet. So you've got this challenge of do I disclose, do I not disclose? Because obviously the last thing a company wants to do is disclose, risk that becoming public, and then find out later that actually there really wasn't a problem. It was a little bit more of a false alarm. And these types of things can happen often. Anybody who's been involved in a breach of any sort knows that, you know, in those first sort of early days, you really are struggling to try to understand how you can stop the bleed, how you can get it back together. And then you start to move on to

trying to figure out with forensics as to exactly what the problem has been, how it came about, and so on. So I think there was always some skepticism around whether or not the timescale for reporting was right. My own view on that is that it didn't matter what timescale you came up with, you were never going to get it right. So you were never going to please everybody. And I think we can argue whether 72 hours is the right amount or not, but that's what it is. So first of all, we have to remember that we haven't seen a whole lot of litigation or fines yet come out of GDPR. Obviously, that will happen over time. So I think if you think about where lawyers are and typically the advice they would give companies, they don't have a lot of case law to base that on yet. So those norms are still being figured out. But in addition to that, we're seeing the emergence of kind of two schools of thought here.

One school of thought is to lean into this, disclose rapidly and often when anytime you see any type of incident, and let those regulators know. Now, obviously, that starts to inoculate you from the potential fines and gets government involved. And I think that's ultimately what governments around the world are really asking for. There is, however, another school of thought where a lot of other companies are looking at this a little more of a conservative view and saying, look, we're not going to lean into regulators until we know for sure that we've actually got a problem and we can truly understand and have evidence to back that up. I'm not here to say which approach is right or wrong, but it's certainly creating a lot of discussion. I mean, the challenge with these kinds of laws and regulations are the devil is in the

detail as it relates to how it's written and then how it's interpreted. And I think that honestly that's probably why we aren't seeing as much traction at a national level related to these laws and regulations. I think that it becomes very sticky in terms of the actual wording and the way in which to write things because the space of technology and the space of cyber and protecting data and thinking about the different technical controls and process level controls that may need to come into this, it's an evolving space. Laws and regulations are meant to be longer term. And so I think that there becomes this back and forth in terms of being precise without being overly prescriptive.

And I think that in many cases, it causes a lot of circular conversation about what should be in the law and regulation. And sometimes it gets to a point where you become mired down in the detail. Not only do we have to deal with European regulations, but here in the United States now, there's 54 different breach disclosure laws. And they're all different, right? So, you know, once you start telling one, then you start to get into the question of, well, who else do we need to tell? Do we sell them the same thing at the same time or different things at different times? So we can create quite an interesting environment where a company is trying to navigate that, make sure they're not going sideways with a regulator,

but at the same time, they've got to work through this crisis. And let's also remember, particularly with larger scale breaches, you not only now have a technical crisis, you may have a communications and reputation crisis, but also now we see automated hedge funds automatically trading stock of companies that have been impacted. So at the same time, you add in a potential financial crisis. So there's obviously oftentimes some resistance to going public with this until you're ready and until you know all the facts. What this really all comes down to is how do you bring all of these different laws and regulations together into a framework where you can compare and contrast requirements, understand where there are similar or the same requirements across laws and regulations. And in some cases where you're talking about a privacy law or regulation versus

a security law or regulation, you might find things that aren't necessarily conflicting, but also come at the same problem from different angles. And so require you to sort of thread the needle carefully in order to think through how you're going to implement a program that is in compliance with this complete framework of laws and regulations that you're dealing with. There's been a general view that actually if you're handling European citizen data in any way, shape or form, then obviously you're going to have to comply with the GDPR. So, you know, we've seen countries such as India, for instance, we've seen countries such as Singapore, Australia, all coming out with national regulations that have set the bar in terms of personal data at the same level.

And for me, and certainly from the people that I talk to in organizations as well as in government, that's viewed as a very positive step because at least we're starting to get, by accident, some would say, a degree of global consistency around the way in which we manage personal data. We're also starting to see some other things coming about, which is also interesting, where certain countries are saying, well, hang on, if we're going to have to store and manage personal data, what about the cloud? Well, maybe you need to be making sure that your personal data, as it refers to a particular citizen, is held within national boundaries. We've seen that coming out of Russia. We've most recently seen that coming out of Vietnam. So I think we're starting to see some morphing and changing coming off the back of it. But overall, I think that sort of global consistency is something that we're starting to see come about. You know, I think anything that we start to do to have more of a dialogue about maintaining privacy is a really good thing. And, you know, if we look underneath the goals and objectives of GDPR, it's very noble in its pursuits. The challenge we run into is you end up with some

unintended consequences. So for example, one of the biggest things that we're all dealing with is the loss of who is data. And if you think about it, the internet was basically put together, and one of the primary principles was that we would all have free and unencumbered access to who is data, to know who is behind this interaction, who registered this domain. And even when bad guys register false domains, Dave, there's enough information there that we can correlate to go, oh, well, the entity behind this also registered a thousand other domains at the same time. So if one is bad, they're probably all bad. And security companies have had a longstanding history of rapidly working through that and blocking all of those potentially nefarious domains to prevent us all from accidentally getting phished.

But with losing that data, it gives the bad guys an edge because we can't correlate those domains. And in fact, we have to go through and mark each one bad individually and effectively wait till somebody's impacted before we can mark it nefarious. And I think the most logical place for regulators to start is to really engage in the conversation with ICANN and really get this who is data problem fixed. Because without who is data, we're all losing out. And ultimately, the loss of who is data, it's increased to the threat landscape, it's increased to the time in which it takes us to take down a bad domain.

Ultimately, that could cause the largest privacy breaches we've ever seen in history as an unintended consequence of GDPR. And so what we often advise our clients to do is create a singular framework that brings together all of the different laws, regulations, standards, in some cases, contractual requirements that they have around this space in order to come up with a complete framework that is inclusive of all of their requirements with a focus not necessarily on compliance across the entire organization at 100% of this framework, but likely a standard and a framework that meets 80 to 90 percent of these requirements with an understanding and an articulation and identification of the areas where

they need to then go back and make adjustments and customizations to the framework and the implementation of that for those areas that need that additional 10% or 20% based upon the type of business it is, based upon the location, based upon the type of data, etc. But what we really find is if you have a singular framework that you're working from, it really is helpful in terms of building an overall program and most importantly, reporting against and assessing against your programs and the laws and regulations. Because that's the thing about laws and regulations. You have to be able to prove compliance, which means you need to be able to do assessments on an ongoing basis to show that the programs, the processes, the tools, the solutions, the organizations that you have in place allow you to be compliant. And so by having this overarching framework, you are then able to really operationalize this complex web of legal and regulatory requirements. Because you don't have very

much time. You don't have that luxury of being able to sit back and plan it all out, you know, because you do have to notify not just the regulator, but also the people who've been affected. You have to keep them informed of what's going on. You have to put in place very quickly now some mitigation for them so that they're reassured that you've taken all of the reasonable steps. And so I think that that has really caused organizations, as I say, to make sure that their playbook has been written, is up to date, is rehearsed. And that, for me, again, is a good thing. It's moving into, I think, being able to tick the cyber hygiene response box that perhaps we didn't have before. I'm not saying everybody's in that position,

but I think there are a lot of people, I include myself in this, who, you know, if you're running an organization, you know that come the day that there is a breach, you're going to have to go out there and explain what's been going on to regulators, employees, shareholders, customers, press, everybody who's interested in it. And speaking personally, you know, I really want to make sure that I know what I'm supposed to be doing before that day arrives. And I think a lot of people share that view. Leading up to GDPR, from what I've seen, there was a lot of confusion that's jason hart he's cto for

enterprise and cyber security from our show sponsors gemalto more confusion than actually doing things i know very few organizations that were compliant to gdpr at the point of the required date i'm still aware of many organizations still going through the process and ensuring they are compliant with GDPR. Now, do you think there was sort of a tactical approach to this, that people were intentionally taking a wait-and-see attitude to see, as long as we show that we're working on this, then perhaps that'll buy us some time to see how strict the enforcement actually is? I think for me, what I was saying to organizations, it's a very good opportunity to start ensuring you're applying the basics from an information security point of view.

So the approach I was saying to organizations, providing you've gone through an appropriate risk assessment, you have an appropriate security framework in place, you understand the types of data, where the data is, the location of the data, and more importantly, you understand the risks and applying the appropriate security controls, you're some way forward in being compliant for GDPR. Now, can you describe to us, what was the spectrum of preparation that you saw in terms of how much work did companies have to do to be in compliance? So I think the first, the biggest challenge that I've seen was actually organizations understanding what data they had. And then secondly, where that data is. And for me,

that's the core foundation of information security. You know, I've been in information security for 26 years. Ultimately, from an attacker's point of view, they're after the data. They don't care what type of data it is. They're looking to basically gain ownership of the data, alter the integrity or breach the confidentiality, and then monetize it. So for me, what I was saying to any organization is, think like a bad guy, Be very situational aware. Understand the different types of people in your organization, the data they're actually accessing it and where they're accessing it from.

Understand the different types of data and understand the locations. So the starting position for any organization, be it for any regulatory requirement or even GDPR, but fundamentally from an information security point of view, is create free buckets, buckets of people, buckets of data, buckets of location. Once you have identified those free buckets, you start creating a process flow between people, data, and location. From there, then you identify, is it a confidentiality risk, an integrity risk, accountability, and auditability. That's 101 information security. And how much of this is a technology solution? Is that feasible?

Yes. So obviously, you know, the bigger the organization, you want to try and limit the amount of, you know, manual processing work or manual work as possible. There's technologies out there to do that. But as a very simple exercise, you know, the board or the management in the organization should quickly sit down and very quickly go for an exercise as an organization, what data do we actually hold, what types of data, and what's the implications based on certain scenarios. How did GDPR affect organizations' attitude towards data in terms of the amount of data they collect, whether or not it makes sense to hold on to data? Any organization, and we're in a world now where we're actually creating more and more

data than ever. And as the years evolve, that's going to double and double and double again. So we're in a data economy, data-driven economy. So fundamentally, from a board perspective or a management point of view, it should all be about the data. And my surprise was, when I sat down with many organizations and said, okay, let's talk about information security, you know, let's put GDPR to one side. When I say to an organization, what is it you're trying to protect in your organization? Very few organizations or individuals say we're trying to protect in your organization, very few organizations or individuals say we're trying to protect our data. So I think for me, the biggest surprise was that organizations who believe they were doing information security appropriately, were not actually doing it appropriately,

because at no point were they considering the risk to the data. I've heard people say that rather than this inclination that organizations had, many of them, to hoard as much data as possible, because you never know when you might need it next, that to actually consider data to be almost radioactive, that you don't want to have, you want to have as little data, you want to be responsible for as little data as possible. If I put my business head on, I want data. The more data I have about my organization, my customers, my users, I can use that data to enhance my business, my technology, and use it to drive ultimately revenue and market share. What needs to be considered is, on the basis that you need data now to make the appropriate business decisions, the question comes to, based on certain types of data, what security control should be applied to that data? That's the conversation.

What are the conversations that need to happen between the folks on the technical side of the organization and the board itself? So again, if we take this a step higher, security is a board issue. And I think that's what GDPR has done. It's actually made security or the consideration of security controls around data a board issue. I still feel that many organizations accept it's a board issue and it's an IT issue. But what it certainly started from what I've seen is that it is getting the IT and the board having a conversation about the protection of data, where is our data and security. Personally, I don't think it's gone far enough at the moment. You know, most boards don't actually see this as a board agenda,

but we're getting there. Take us through what a typical engagement is like for you when you're working with a client to make sure that they're approaching GDPR from a practical point of view. Where do you begin? When I go into, you know, organizations irrespective of the size, first of all, I'm trying to understand their pain and their problem. Every organization is different. So normally when we've come in, when we come in, they've identified there's a need on protecting data or applying access control authentication. So the first thing is, okay, what is it you're trying to protect and why you're trying to protect it? Most of the time, most organizations want to protect everything in the organization, when actually

it's not always necessary so you know to actually apply full-blown security controls and data protection across you know a global organization or even a small sme can be very very painful hence the challenge so first of all we need i take them through a process to say okay what does you need why are you trying to do this and then understand within that process actually the types of risks they're trying to mitigate most organizations assume just applying one security control actually mitigates all risk it's it doesn't so it's really walking them through the process identifying the real risks and then applying the appropriate security control could be a process it could be technology

it could be other controls which then start to mitigate the risk. So ultimately what you do is you try initially reducing the scope, create your scope on what you're trying to protect, understand why you're trying to protect it, get that in scope, and then apply the appropriate controls and progress from there. And what's the reaction to that? Do most organizations find themselves having sort of those aha moments where you open their eyes to looking at it in perhaps a way they hadn't before? Yeah, for me, the key objective, you know, cybersecurity, information security can be very, very simple. But in order for it to be very, very simple, you need to actually take a broader view. And, you know, again, you know, I'm going to be very, very simple, you need to actually take a broader view.

And, you know, again, you know, I'm going to be talking lots of it during the podcast, the concept of situational awareness. From a bad guy's point of view, it's about people, data and process. So if you're just looking at technology, then the bad guy is going to look at the people element and the process. If you're just looking at the people and not the technology and the process, guess what? The bad guy is going to go either side. So any organization, once they've identified what they're trying to protect and why they're trying to protect it, where does the people, data, and process and technology come into it?

And then look at the risk holistically. Now, in terms of GDPR from a big picture, should organizations, I mean, obviously it's here and they have to deal with it, but is it helpful to look at it as a burden or perhaps an opportunity? I think it's a business case and an opportunity. So if I was a CISO or a CTO or even a CEO, you know, trying to get investment across my board or higher up in the organization, it's an opportunity. It's an opportunity to start doing information security properly. I think it's easy to say, but actually executing that,

I mean, the devil is in those details, right? Which really comes back to, as an organization, if you identify what you're trying to protect and why you're trying to protect it, identify is it a confidentiality risk, an integrity, accountability, and auditability risk, from that point, you can then apply the appropriate control. The biggest mistake I see, be it GDPR or any other regulation, is an organization is trying to

enable that regulation or that mandatory requirement across the whole organization. Start by identifying where the critical assets are, the key hotspots, and then build out from there. In terms of mitigating risk, since we are still in the early days for GDPR, and as we mentioned earlier, I think a lot of folks are sort of looking around and seeing how strict are the enforcement efforts going to be, how big are the fines going to be? What are we really in for here? What's your advice for organizations to navigate that, to take an appropriate level of preparation, but also not go overboard with it? There's a lot of, you know, a lot of talk around, you know, huge fines, you know, the regulators fining organizations. huge fines, you know, the regulators fining organizations. If I'm a regulator, what I'm looking for is to see that the organization has taken due care. So first of all, I don't think the regulators are out there to fine and to make money from this. What they want organizations to

do is to go through a process to ensure that they've identified key sets of data personal identifiable information and are applying the appropriate controls you're never going to prevent a breach from happening but what you can do is vastly reduce the impact of a breach in my term i call this a secure breach so as a regulator they want to see that the as an organization you've gone through a process, you've identified the hotspots, the risk areas in your organization and the types of data that could be high risk. You've assessed the risk, you've applied the appropriate control where appropriate. providing an organisation has gone through a very simple process, it doesn't need to be over-complicated,

and then assessed the risk, validated the risk, and then applied the appropriate remediation where possible, they can actually show there is due care taken. It's over-complicated and it doesn't need to be over-complicated. And I think that's a really important message. If you're doing the basics from an information security point of view, i.e. you have a risk assessment around data, you've identified key data sets, then you're kind of a long way forward and actually meeting the requirements of GDPR. That's Jason Hart, CTO for Enterprise and Cybersecurity at Gemalto.

Thanks to them for underwriting this edition of CyberWireX. Be sure to visit gemalto.com slash cyberwire to learn more about their access management and data protection solutions, and also find out about the Breach Level Index, which tracks the volume and sources of stolen data records. That's gemalto.com slash cyberwire. And thanks to Emily Mossberg from Deloitte, Caleb Barlow from IBM, and Steve Durbin from ISF for their participation. CyberWireX is a production of the CyberWire

and is proudly produced in Maryland at the startup studios of DataTribe, where they're co-building the next generation of cybersecurity startups and technologies. Our coordinating producer is Jennifer Iben. Our CyberWire editor is John Petrick. Technical editor is Chris Russell. Executive editor is Peter Kilpie.

And I'm Dave Bittner. Thanks for listening. CyberWire X.