Creating a Robust Data Breach Management Policy

 

Transcription: 

Robert Bateman:

Hello, welcome back to PrivSec Focus Enterprise Risk. We’re back earlier than I suggested we would be so apologies for the scheduling confusion there. Big thanks to you all for attending today, and please continue to ask questions and interact with the panel via the left-hand menu. Thanks again to our sponsors, One Trust and ServiceNow. Coming up next then is a panel on Creating a Robust Data Breach Management Policy. A particularly impressive lineup for this panel, the chair is Jose Belo, Head of Data Privacy at Valuer.ai. Jose, over to you.

Jose Belo:

Hello Robert. And to be honest it was not a mistake you were just following GDPR guidelines without undue delay. It can mean 30 minutes, it can mean five, it’s just without a due delay. That’s why we are now here. I’m very excited about this panel, it’s something that I’m very, very interested in. It’s a panel about not only one of the most important parts of a company, how to respond to a security incident or a data breach, personal data breach, but also the steps needed to make both the securities and response and the personal data breach response as effective as possible. And with me, I have Carol Robson.

Caro Robson:

Hi.

Jose Belo:

Hello, Caro. Would love for you to introduce yourself if possible?

Caro Robson:

Hi, thank you. I’m Caro Robson, I lead the Data Protection and Digital Practice for Milieu Consulting here in Brussels, and I’ve worked in the field for 13 years, including as a lawyer and a compliance officer for governments and multinationals. Thanks for having me.

Jose Belo:

Thank you, Caro. Next up we have Sandy Silk. Hi, Sandy.

Sandy Silk:

Good morning.

Jose Belo:

How are you?

Sandy Silk:

I’m great, thanks. Hi, I’m Sandy Silk, I’m former Director of Information Security Consulting and Education from Harvard University. Although now for the past year, I’ve been with Info-Tech Research Group where I lead week long workshops with members on various security topics, one of them being security incident management.

Jose Belo:

Thank you, and welcome to the panel. And last but not least, we have Scott Warren. Hello, Scott.

Scott Warren:

Hi Jose. Thanks to everyone for making it through the day, the gauntlet of sessions. I’ve listened to a number of them, they’ve been great. I’m a lawyer with the firm Squire Patton Boggs. I think we’re probably the best kept secret in data privacy in that perhaps because we changed our name so many times. We used to be Squire Sanders, and now it’s Patton Boggs, and people don’t necessarily know the full name. But we’re one of the largest, in terms of locations around the globe, law firms in the top 10 and that helps us a lot on the data privacy side. I’m a partner in the Tokyo office as well as Shanghai working across the APAC region and stitching that together with my colleagues in the United States, in Europe and the rest of the globe, dealing with data privacy, cyber issues.

Jose Belo:

Thank you so much, Scott. As you can all see, we have an impressive panel with some very impressive credentials and experience to answer this very difficult question, which is how to make a robust… We’re not even asking to make a security response policy, we asking to make a robust one. And to start things off, I would like to throw to whomever would like to answer because it’s a general question that I think you all have experience with, is regarding preparation versus implementation. One thing is preparation, one thing is implementation, but there’s this gray area where they both fuse together. Which one would you think would be the most relevant, or are they both as relevant? Should we give more time to one and to the other, should we prepare more? Should we try to implement more? What are your thoughts?

Scott Warren:

Well, I might just start with a concept that I could say it depends, the great lawyer answer. But the reality is if you don’t prepare, there’s really no implementation. Unless you know what your data is and done data mapping, you have no ability to create a structure around how to protect it. We were just talking before in the back room about in sports, you never go and oppose somebody on another team without actually having done research on how they play and what do they do, what are their favorite moves and how you’re going to defend it? You make a plan, but you study first how they played other matches. If you don’t understand where your data is and understand where your strengths are and what you want to protect, then you don’t have a way of creating a good incident response plan that’s going to help you really handle the challenges. I think you do that first, then you have a chance to do great implementation.

Jose Belo:

What would you think does great preparation mean instead of great implementation? What would you consider would be good steps towards a very good implementation, preparation of a CSIRT plan and policy?

Sandy Silk:

I’m actually going to jump in with an-

Scott Warren:

Please.

Jose Belo:

Oh, good.

Sandy Silk:

… analogy here.

Jose Belo:

Go ahead.

Sandy Silk:

Anyone else who’s learned CPR, you don’t just say somebody call… Here in the United States, Ryan, call 911. You need to actually point to an individual and say, you, you call 911, because if you have a bunch of people standing around trying to get something done, that’s not as effective as you need to have assigned roles and responsibilities. I would say one of the very first things with preparation is knowing who does what and when, so that you’re making sure everything gets accomplished and you don’t have people spending resources, time, effort, duplicating something, and forgetting to do something else, and that you have the right people doing the right things.

Scott Warren:

And Sandy, a tie on to that is interestingly in Japan, it’s not 911, it’s actually 119 for emergencies in Japan. If you’re not thinking about this issue, cross-culturally when you have data that might be from a number of locations you’re not actually communicating about what it is that you want done. And so a good plan has really thought about what do I have that I’m trying to protect? And I really encourage that.

We don’t just think about that as personal information alone, which is what is generally notifiable in most of the countries, and we have different rules to determine and all those rest of the things. I think we oftentimes do this topic a disservice by focusing it solely on personal information. I’m not saying that isn’t important and essential and things we should absolutely pay attention to, but I think we would get a lot more attention from executives within our clients or our corporations that we work with if we talk to them that I think the latest IBM Ponemon study I saw, said that 44% of all data breaches involved personal information. Gee whiz, that’s 56%, unless my math is wrong. I went into law, not mathematics, but 56% of them aren’t involving personal information. What are they? They’re advanced persistent threats trickling out your trade secrets and all the things that you value as your company so that they can probably be given to other countries, competing industries who are trying to catch up, or sold by hackers that want that data and can sell it to somebody.

If we realize that that’s a good portion of what’s being done, then our analysis on data mapping is, okay, where do I have personal information, who from, what countries apply, what do I have to do in terms of a breach and creating a great plan around that? But also thinking, what are the things that are really important to us as a company, how do we protect that, and how do we know whether that’s been touched? And if we do those two things, that data mapping sets everything else up, and our rest of our conversations are much easier because we actually have a platform to start from.

Sandy Silk:

And I just want to expand on that too, that same Ponemon or IBM, now Ponemon together, would say, if you can detect and contain something within 100 days, you will save a million dollars, and this is US based dollars in the long tail response, the losses.

Jose Belo:

Interesting.

Sandy Silk:

I don’t remember the percentage offhand, but not a high percentage are able to detect and contain within the 100 days.

Scott Warren:

The other great part of that study is it says that companies that have, so your average data breach on a global basis and this doesn’t just take into the US, which it’s 9 million is generally an average or something, it’s 4.6 million globally. And this includes companies from all over APAC and Europe and South America. If it’s $4.6 million as an average breach, if you include the cost of getting rid of the breach, notifications, damage to rep and that sort of thing.

But they found that companies that have a cyber incident response plan, and test it end up saving 50%. It’s 2.3 or $4 million that can be saved on your average breach if you simply have a good incident response plan that knows, that says, how am I going to respond? And then you actually put people into a room and test them. Well, we don’t do them in the room anymore with COVID, but you test whether or not they can handle, in an increasing set of difficult cyber situations that you walk them through, whether they’re ready for it. And if you do those things, you can save significantly on behalf of your company.

Jose Belo:

I’m all up for KPIs and metrics on that one. The numbers you’ve thrown are very, very interesting. I always also think that it’s very valuable to add the success stories, the breaches that did not happen, that were prevented, the securities that we had up. Be it training an awareness to employees, be it through our third party controls that we had put in place. Those are as valuable as the numbers where the failures of those controls and that training and awareness came from.

Which brings me to you, Caro. What do you think is the most important, or do you think is there a difference between self detection and third party detection? Do you think that there’s an important side of training and awareness of your employee? Are your defenses as strong as an employee with an Excel file ready to open it, or are the controls in place able to fix it all?

Caro Robson:

I think you’re only as strong as your employee’s awareness and understanding and practices. There’s training employees and making them aware that simple things, don’t use BCC, or if you use BCC, be very careful about where you’re emailing information. A lot of breaches happen because people just copy the wrong people into emails. And also detecting internally isn’t going to happen if a lot of staff don’t understand what is a data breach or that something might be an issue and have the confidence to raise it. I think there’s definitely a role in third parties with the core cyber security assessment of your networks and that pen testing to make sure the network is robust. But an awful lot of breaches happen through human error, or they’re detected by people simply noticing something wrong or odd. And I think it’s really important that you have both, but crucially employees understanding that this could be an issue and what they have to do is really important I think.

Jose Belo:

What would you, and this is for the whole panel, how important do you think… Because employees usually think that they lost their device, they lost the computer. There’s an issue there, they are afraid that they’re going to get fired or have some disciplinary actions. How can companies try and improve? We have the Whistleblower Directive, but that’s nothing to do with this. How can we improve the self detection inside the companies? Because as we all know, human error is probably one of the biggest causes of the failure of robust, as robust as you can, cyber security incident response plan.

Sandy Silk:

I would throw out there, and I’ve been a lead or overseeing the rollout of many security awareness plans, whether it was at Harvard or at Fidelity Investments before then. One of the biggest soft skills trait you need to have with your security team is nonjudgmental people. We all have bad days. Any of us can fail a phishing test or a real phishing attempt, sometimes it’s just because we’re rushed. And we just don’t think, and we’re wishing the five second rule applied to undo. We’ve all been there. We all have bad days, and I think you just have to help that person who’s reporting something to thank them for bringing it to your attention so that you can look and see, is this anything to worry about? And thank you for telling us so we can contain this and minimize the damage, but absolutely just promote neighborhood community watch kind of thing that, we’re not going to blame somebody. Security’s not going to blame somebody. We just want to get the problem under control and do what we need to do, and just don’t worry alone.

Scott Warren:

And I think on that side, some of the companies I know, and even I know within our own firm, they’ll send you email that is designed to see if you’ll click it. And then if you do, they’ll actually say, “Hey, you just got spammed, and here’s the things that you can look for to help you understand that.” And that is a very effective way of just helping to train folks about what to avoid, giving them an easy place to send suspicious email to, to get it cleared before. It comes in, it looks a little funny, all your employees should have the email line that they would send it to and the person that they would ask. And that way that helps reduce it.

But I actually think, in some ways, as Sandy said, everybody has a bad day. If you have these security automation technologies, these ways of looking into your system that are automated, and they say, “Wow, somebody just clicked this executable code.” It’s easy in the ransomware attack. Well, used to be easy because it would automatically encrypt everything. Now they’re working on getting top level domain and stealing stuff out, and then they’re going to do the payload for the ransomware.

But, when you have these technologies that look across your system for anomalous situations, things that don’t make sense, then it becomes less about an employee reporting, because they may or may not know what has happened. And hopefully they do feel encouraged to go ahead and say, “Hey, this happened, I want to see.” But that automation technology can oftentimes very quickly say, this isn’t normal, this shouldn’t be happening, and they’ll find out that data is trickling out at 3:00 AM when this person’s not logged in of their computer and start saying, okay, well, there’s something strange going on. That can very quickly turn to what you were saying earlier, Jose, those success stories that help you identify a problem before that’s actually become a problem. You may have some issues related to it, but you’ve completely crushed it down into a small box that’s a lot easier to recover from.

Jose Belo:

That’s absolutely true, and thank you so much for all the input. I’ll move this along towards what we’ve been talking about, because one thing is the security incident, another thing is the personal data breach. Those two do become intertwined because personal data is data and the CSIRT plan and policy does handle all kinds of data. As you said, very well, Scott, data mapping is so important in this case, but it becomes a hassle for a company, especially with the GDPR, to find out, during the process of a security incident, when to trigger the data breach management team and how both can combine with one another. I would love to hear your experiences on that, because that’s one of the things that GDPR requires the most, but it’s also quite difficult to understand, when does the DBM team start working? When do the 72 hours start, do they start when the security incident is detected, or the personal data is detected? Anyone up for the question? Caro?

Caro Robson:

Well, as a matter of law, depending on which jurisdiction you’re in, which goes to Scott’s point about understanding what laws apply to your data. It usually applies when the organization is aware that personal data may have been compromised or accessed. It’s a pretty harsh rule, particularly here in Europe. And that’s why you need to make sure that you have, as Sandy was saying, teams working together. And I’ll give an example of a success story. I won’t give any examples if I’ve been involved in things that have been less successful.

But the best response times and management I’ve been involved in certainly is where your enterprise architects or your IT architects, plus your security team, plus your legal team and your compliance team, all know each other, work together and work hand in hand on a daily basis to put things in place by design so that things, Scott says, don’t happen as far as can be avoided, but also that you understand the roles, the responsibilities, you trust each other, you can share information. That’s when I think it works incredibly well, when you have those teams working hand in hand. There’s no way around security teams having to understand personal data, and what is personal data, to get those teams involved. But I think if they’ve got a close working relationship, so each side understands the other’s issues and perspectives, that’s definitely the most successful you can be at managing data breaches, I think.

Scott Warren:

I think one of the challenges, as you were saying, Jose, is knowing there’s so many different definitions of what a data breach is. Even what personal information or personal data is, is different in so many countries. And then is it a breach if it’s acquired, like in a lot of US states versus simple access? And then you’ve got, it’s 72 hours in Europe, in the Philippines and now Singapore requires notification in 72 hours. It’s 24 hours in South Korea for most settings, and most people don’t realize they’ve got 24 hours there. And then China basically says, not only if it happens, but if you think it could happen. You could argue that you have to notify the Chinese government of a zero day virus you just found in your software before you’ve patched it. Which again, that’s just the way the law’s written.

I don’t know how long that’s been enforced, or if it’s been enforced, it hasn’t been at least in my watch. But, still, that’s the challenge. And when you’re creating a good cyber incidence response plan that knows where your data is, you start having maybe appendices that says, here’s the definition of a breach, a notifiable incident. And is it to the data privacy authority, is it to the individual, is it “immediately,” which in the US means 30 to 60 days, or a specified 72 hours under GDPR? How do we start thinking about even notification letters that can be put in? That’s a robust incident response plan that you can actually be quite actionable, that team gets together and they have to very quickly determine, okay, frankly, all of us have been into data breach room knows that in 72 hours after the breach you know a lot less than you started with, because there’s just so many things going on.

And so yes, exactly. How do you figure out when do you notify? In Japan, they actually have these two levels. One of them is, you should notify immediately, but it’s a very sparse notice and you can be small, but within 30 days they want a really robust, here’s what’s happened. And so there’s just so many different ways to look at it, but you need to understand that nuance. It’s not just a GDPR issue and we can’t just use GDPR rules to define how to proceed because so many countries are now passing something that’s GDPR like, but different, and we need to know what those differences are.

Sandy Silk:

And I want to raise a concern I have, this is personal, not representative of the companies that I currently work for or have in the past, but I’ve seen a trend to make the CISO, Chief Information Security Officer now become the Chief Information Security and Privacy Officer, so the CISPO. And when you get yourself into a incident response that may have data breach, you’ve got a person now who is responsible to two different things that may be conflicting at times. And it’s just an untenuous situation to put someone in. I think it’s fair to say, okay, they can help strategize and help design and oversee how architecture will be rolled out with both things in mind, but when you’re in a response, you cannot put both of those hats on one person’s head.

Caro Robson:

I think just to follow up on that, I think that’s a really good point more generally, actually. Going back to what you were saying around making sure one person rings an ambulance in an emergency, making sure you’ve understood, and everyone understands, who the decision makers are, but also that those decision makers, as you said, don’t have a conflict. I’ve seen examples where lawyers have been asked to be the decision makers on whether a breach notifications are made and when and how. And it becomes very complicated very quickly because people who have advisory roles, in my view at least, my personal view, shouldn’t really be making those decisions for the actual overall management of the breach. I think that becomes really important. And I have a lot of sympathy, just so you know, with any CISO who’s also being asked to handle data protection, because that’s a lot. That’s a lot for one person.

Sandy Silk:

And Caro, that you say that, because I think someone in security would be looking to legal to make those decisions, and you’re saying, no, legal’s not [inaudible 00:25:51] if they weren’t told ahead of time. It seems to be the hot potato that everyone just turns left and says, “Well, you do it.” And then whoever’s at the end of the line gets to do it unless you’ve thought about this proactively and have really appointed someone who’s going to be accountable for it and have all the information they need to make a good judgment. Otherwise, we tend to be just like draw straws, who has to do this?

Jose Belo:

Well, that actually brings me to the next question [inaudible 00:26:23].

Scott Warren:

Actually Jose, just before we leave that, because your original question, I think we didn’t answer. It is, when a breach occurs, how do we figure out what to do? And I think the good incident response plans I’ve seen create a triage or a four level analysis. And one of them is if they attempted to get into our system and they didn’t get in, or it was just a penetration attempt of the firewall, but nothing really happened that could be dealt with by IT. They maybe keep a record of it or do something like that.

And then you’ve got the next level where they were able to get in and get some information, but it doesn’t look like it was important. That gets escalated to a little broader group that can understand, okay, were there legal implications or were there other things?

Then there’s that, okay, now it’s gone much beyond that, there’s some really important information and that’s going to be a much broader, and it could be global.

And then the final is the oh shucks level, I call it, when the press is starting to knock on the door and say, “We’ve found out about a breach,” your employees are all up in arms. You’ve got probably people threatening shareholder derivatives,” and maybe well before that you’ve gotten the CEO infrastructure involved, but those are the ones you want to make sure it’s the all hands on deck, or if you see it going towards that.

And if you can at least separate it that way, I think you’ve got a reasonable way to approach that. Not everything’s going to assemble your core team to figure out what to do.

Jose Belo:

Look, what you just said, Scott, is exactly the way that I think is one of the most effective ways of preparing for a data breach. For example, you cannot expect, imagine a data breach, hear the incident or whatever you want to call it, happens at 3:00 AM in the morning and the CEO is called. He’s not briefed totally on what is happening. He gets a call from a reporter, “You’re a Fortune 500 company, you’re on Euronext,” how do you answer? You probably should have that answer ready beforehand. You probably should have a PR agency ready to respond to that. You probably should already have a contract with a forensic evidence company to go immediately inside your business and try and independently as possible to show good faith towards the regulators to be able to collect all the evidence.

This preparation phase, and also external counsel, a lawyer that can come in and help us out with all the things. Because I never see a [inaudible 00:29:06] team or a CSIRT team as just that small number of people that have rules and responsibilities inside the company answering inside a war room and then answering that. I see this as a multifaceted approach, where stockholders, as you mentioned, they come in the door immediately. I know companies that when the data reach happens, 100 people come in the door as a DPO.

Scott Warren:

Right.

Jose Belo:

And we all know those horror stories.

Scott Warren:

I think the important part of that plan is, is you were just saying exactly is to think about the communications part of it. And this is a training area where you can really help employees, because oftentimes somebody will hear something and they’ll start writing an email and they’ll announce there’s been a data breach. God forbid, you don’t want to use those words frankly, especially from a US context. Security incident, until you know exactly what happened, is a much safer term.

Jose Belo:

[inaudible 00:30:09].

Scott Warren:

And if you have any indication that this could involve US data, then you need to really think about how you’re going to communicate about this to try to protect the attorney-client privilege.

Jose Belo:

Exactly.

Scott Warren:

And that means having an attorney, usually, generally a US attorney that can claim that privilege, but using the right terms in your subject lines, and having them involved to task out your technology folks and the com folks so that at least you can argue this. And it seems ridiculous, and I have to apologize as an American attorney for the US litigation system, because it becomes a huge burden to make this communication. But if you don’t, that email that X, Y, Z employee sends to somebody to talk about this incident and saying, “Here’s the 15 things that went wrong and we were informed about this earlier,” that’s discoverable.

And it’s coming up in the context of a lot of different class action or shareholder derivative, or other litigation that doesn’t necessarily have to happen if we do good training. We should be able to figure out what happened, we should be able to help the client do good communication across all the vendors and not be a burden to that. But you need to think about that very seriously, because it’s just a huge… In the US, we’re doing data notifications in a number of cases, and the next day we’ve got two or three class actions filed. It’s just that way in the US so you have to plan for it because it’s the reality.

Sandy Silk:

And I’ll build on that, Scott, in a number of the incident response plans that I’m helping members build out now. One of the elements we incorporate is if you need to notify your own internal employees that something’s going on, who’s doing that and how are you doing that? And fortunately, now that video conferencing is so prevalent, you can have an all hands or a town hall meeting, whatever you call it, so that it’s not going through email and being discoverable afterward. Because anything you send to all employees, you can expect that’s making it outside somehow pretty immediately, by human error even. And there’s that being able to talk about it, to have someone from the top saying, “This is going on, this is important to us, we’re looking into this, we’re containing it, but you cannot say anything, just direct everything to corporate communications,” whatever the team is called. But making sure you’re treating it like a community, that everybody’s a part of it.

Jose Belo:

And I do think, I don’t know if Caro wants to add anything, but I just wanted to add that I would still consider this as a preparation phase, even though it does seem like the implementation phase, but I do think that all this preparation also helps the cybersecurity premium go down because you are really preparing yourself and you’re telling the insurance company, look, we’re preparing ourselves for the worst case scenarios. And we’ll speak about scenarios in a few minutes, but Caro, do you have anything to add to this?

Caro Robson:

No, I think that’s right actually. And increasingly, cyber insurance are asking for lots of documentation for policies to demonstrate that you have all these procedures in place. And of course, all of your policies then, as you say, become discoverable. And certainly regulators here in Europe and around the world will want to look at those when they examine the breach. They’ll also look at internal communications to try to work out, did you notify in time? When were you aware? What did you know, how did you know? That kind of thing, I’ve seen a lot of cases where that has gone through an exact detail with folders and folders and folders of disclosure on the internal procedure when a breach happened. I think that’s a really big risk.

And I would just add, it’s also really important when you have partners or other organizations, particularly if you process data on their behalf, which here in Europe and a lot of countries makes you their processor. And that can be quite tricky because organizations might be a controller for some things and a processor for others. And the reason that’s important is first the obligations around a data breach in terms of notification are on the controller. But also if you are just a processor, your contract with the company you’re processing data for almost certainly includes a requirement to notify them and not do anything without consulting them. But also, data protection law in many places, certainly here in Europe, requires you to notify the controller, but then assist them to handle it. And partners will not be happy if they’re starting to get drips and drips of information out that isn’t particularly helpful to them. Or if you start approaching either the media or, goodness forbid, a regulator in circumstances where they wouldn’t without consulting them. The comms piece is very, very, very important, I think. Very important.

Jose Belo:

I do think that we do all agree that the preparation phase is the phase that where we prepare ourselves towards the worst case scenarios. The issue then will become, can we prepare for everything? It’s almost impossible for us to prepare for everything. We can run 10, 20, 30 scenarios, and someone’s going to come up with something we never even thought about. How would you handle these cases? How to prepare for what is unpreparable?

Scott Warren:

From my perspective, it’s not really important that you prepare for everything. The reality is, and I think I’ve been working on cyber breach incidents since early two thousands and Slammer virus and things like that. And a lot of the stuff is cyclical and works around different attacks come around again, but do it slightly differently. And then there’s totally new, different attacks. The reality is we can’t get a rid of crime, we’re always going to have somebody trying to break into your house. We could be more sophisticated about how they do that, and we can put bars here, they might be able to get a ladder. But the bottom line is, I’ve found, and I think the IBM Ponemon study suggests the same thing, if you simply have the plan and bring this group of people together to work on an increasingly difficult, let’s say, three scenarios on a Friday afternoon which is when these usually hit.

And, again, sitting in the room is great because that’s the real pressure cooker, but we can’t do that as much. Well, maybe we can more now. Let’s hope. In certain places we can’t. But going through that, you don’t oftentimes have this disperate team, not desperate, but a disparate team together sitting in a room. You’ve got IT and HR, you’ve got executive sponsorship, you’ve got legal, there’s a CISO, you’ve got compliance. These people don’t sit and have lunch together that often. And just training them how to work through an issue and then the realizations of where these gaps are that you never expected is really the trick.

And so sitting through doing that once or twice, well then if something happens, that’s totally different, you’re still agile and able to more quickly handle and respond to the issues. And if nothing else, you could show that you really were surprised, this was completely off. You’ve already done the training. I think most of the regulators are just happy if you have the good plan, you’ve done the training. They’ll give you a lot of latitude knowing that the hackers are going to probably figure out a way in, especially depending on the sophistication of the hackers. But if you’ve done that, then that really helps and I think you can actually reduce it.

Sandy Silk:

And I think always having the checklist of what are your options, because you may hit thresholds where you have to say, at this point we are just disconnecting this system from outbound connectivity. I don’t know how they’re in here. I don’t know how they’re doing this. We can’t risk more getting lost, so at this point, because we don’t know compensating controls to put in place beyond disconnecting it, then you have to have those…

Jose Belo:

[inaudible 00:38:52].

Sandy Silk:

You’ve got to be able to go to the right people quickly and say, there’s the risk of not disconnecting it, there’s the risk that we do disconnect it, which one would you rather? This is a business decision.

Scott Warren:

That just recently happened within the last month with Toyota, where they had to shut down their entire 14 manufacturing plants in Japan for a day because of a third party threat from one of their vendors that was a ransomware related attack, but they just weren’t sure how far. That was something like 13,000 vehicles they weren’t able to make that day, plus all the salaries and everything else, but that’s the price that they were willing to pay. We had Colonial Pipeline in the US, where at some point you have to make that decision, as Sandy says, do I need to shut this down now to make sure that I have control of everything?

Jose Belo:

I read the article on the RSA hacker, 10 years ago, which was just… And I remember that they were in the war room looking at what was happening, they saying, “They got in.” And you know that no matter how robust your data breach policy is, when you see your CISO starting to unplug internet cables, you know the plan is out. But that’s worst case scenarios. The scenarios that we all live through and we all know are scenarios that are the most that we can… It’s impossible for a company to protect itself to the fullest. And it’s also impossible for us to understand the whole scenario that surrounds us. We are only human, and we can only predict what we know. The lessons learned during the postmortem, when we look at it in that way, how important are they towards building a more robust policy than we started with?

Caro Robson:

Well, I think it’s extremely important. Obviously if you are dealing with a lot of minor incidents, which is probably a sign your system works extremely well, rather than the opposite, because if you’re picking these things up, it means it’s working. But I think for certainly larger incidents, depending on how an organization defines that, I think it’s really, really important because there’s often issues with the process or things that could have been done better or could have been improved or learnings from decisions made or thresholds and what the outcome was. I think it’s very, very important that in certainly the larger incidents that you sit down and then discuss, take lessons from it and amend the policies if necessary. Obviously you don’t want to do that too often because then that just becomes a burden. But I think where improvements can be made, I think that’s always worth doing.

Sandy Silk:

And…

Scott Warren:

I can give an example… Go ahead, Sandy.

Sandy Silk:

I’d say from lessons learned that I’ve been involved in, and they’re after significant events, typically, most of the items that come out of it are not going to be the technical, it’s going to be the process and largely the communication. Did we have enough communicated early enough, and did we keep that communication open and were decisions made in a timely manner? And it’s hard to make a decision when you want more information and it’s just not there.

Scott Warren:

I think a lot of the postmortem it suggests itself of what to do. And I can give an example, when I was working in Microsoft, there was an MSN hack of an Asian country where it really wasn’t any weakness in the code of the website itself, it was that we rented out advertising space and advertising boxes and the people that created that advertising message was subject to attack. Somebody dragged their cursor across it, they got redirected and this was affecting 50,000 different websites in this country. And we had a really robust plan. This is early two thousands. We had a really good data privacy program. We assembled a team within about four hours to talk about what was going on, not data privacy, cyber security in this case.

And I was leading the discussion points. And first IT spoke up and said, “Hey, it’s great, we’re up and running again. Took us about three and a half hours, but everything’s up and everything’s functional.” I said, “Great, please give me the server so that we can analyze what happened.” They said, “Oh, well, we just wiped the servers and reloaded them,” which was a great response from the IT guys, because that got the things up very quickly, but it was a horrible response from an evidentiary standpoint. And you don’t know that until you do these. Until you go through that, or that’s the purpose of doing the tabletop exercises or cyber preparedness drills, is that you get a chance to have those aha moments where, I thought you were going to do that. And you can get that out of the way in the front so you don’t have to have lost all that. And that I think the postmortem is great for.

Jose Belo:

Caro, anything to add? Because, to be honest, the postmortem and the lessons learned, to me, are what really makes a robust plan even more robust, because those are real cases and scenarios. We can dream up all the cases, all the scenarios that we want, the ones that actually pass through and make the team work and make the team not only investigate, contain, recover, see what went wrong, where were the entry points, the vectors, et cetera. And that’s where we find out the vulnerabilities of the companies that we were not aware of. And that’s where we can then go back and do almost a PDCA check, if you want, and say, look, this went wrong here. Or even in the plan, there are things in the plan that can be done better.

Which leads me to the last question to all of you. We’ve been talking about data breach response plans, and we’ll talk about robustness. What would you consider would be the most important, if you want to leave a key takeaway for our listeners? What would be the key takeaway to develop a robust plan that answers the cyber attacks and all these issues that we face on a daily basis?

Sandy Silk:

I would say, make sure you are maintaining it. It can’t be a one and done published, there it’s done, we’re all good. I think you have to constantly update it with new things you discover, new areas in which you operate. I will say I’ve found some just recently posted online, they’re public, that are dated 2017. There is no way that’s the policy you’re following at this point. That was even pre COVID, so much has changed with mobility since then. And it’s embarrassing to see these things out there that are dated so old, so I would say just make sure it’s a living document that you keep updating it and keep track of when you’re updating it.

Caro Robson:

And I think I’d add to that, make sure people know it exists, because I’ve dealt with some incidents in the past where afterwards everyone says, “Oh, did you mean this, whilst you dealt with that?” And it’s covered in dust and it’s been on a shelf and people really need to understand where it is, that it applies to them, how it applies to them, and also that there is a team, there are people in place, that there is a procedure in these circumstances. I think that helps calm people in these scenarios when everything’s blowing up, people know that this has been thought through. But also frankly, how are you going to apply it if people don’t know it exists and it’s in there? I’d definitely say make sure that it’s up to date, but also that people know where it is and that it applies.

Scott Warren:

And then from my side, I think, just make sure it’s global if you have global data. And if not, and you have more regional data, make sure it’s really regional and covers all the different types of data that you have and may deal with because it’s wrong to assume one item is going to work, or one rule is going to work across all of the different jurisdictions. I think the other observation that I don’t think we’ve talked about, but I think is really important, and I see this mistake happening sometimes with smaller companies or smaller, medium sized enterprises, is they get attacked by ransomware attacks, they were contacted by the ransomware folks, they either paid something or in most cases they paid and were told, “Oh, you’re fine,” but they don’t continue on to do a really detailed analysis about what happened.

In the old style of ransomware attacks, it was simply executable code that encrypted all the data, and then if you paid the ransomware, they would push a button and it would decrypt everything. But really the attacks now oftentimes are getting top level domain access into your system, building in back doors, trickling out data. And you don’t know where your exposure is, nor can you properly know that you’ve gotten them out of your system if you don’t take the step of getting somebody really good on the technical side to figure out where they were, what happened, and then you can actually have some comfort that they’re out of your system.

Jose Belo:

This one’s on me. I was actually searching for the questions from the audience on the private chat and they just didn’t go through. I don’t know why. I’m going to choose very quickly two questions, if you can very quickly answer them, because I know we’re very tight on time. Any thoughts with respect to the push to incorporate DevSecOps as a more collaborative IT component in organizations? 30 seconds.

Sandy Silk:

Yes. Do it. Use the native cloud security provider tools to help monitor configurations?

Scott Warren:

That was 23 seconds, way to go Sandy.

Jose Belo:

Would you encourage organizations to conduct simulacrums periodically to test data breach response plans? You’ve talked about it. Yes.

Caro Robson:

Yep. Definitely.

Jose Belo:

And last question with regard to data governance and the degree of data literacy enterprise wide, would you provide insight on the impact on data breach management policy? And this is the last one.

Caro Robson:

Yes. It’s huge and it’s very, very important. People need to know what data you have, you need to map it. People need to know what personal data is, and people need to be aware what to do if that gets lost or accessed.

Sandy Silk:

Make sure users know where to put it, where the right place is to store it and where are the places that you’re not permitted to store it.

Jose Belo:

And my apologies to the question, because the chat did move up and I didn’t see them. But they are there, the questions were answered. I do think that looking at the questions we did cover a lot of them. I want to thank you all for being in the panel. It was a very instructive panel for me, and I’m pretty sure for the audience. And I do hope to see you all again in another panel at BritSec and hopefully onsite instead…