Litigation response plans have directed a spotlight on the signification of information governance across an enterprise. Jack Grimes and Skip Westfall of Inventus posit that those very same protocols apply when preparing for a data breach as well. Their remarks have been edited for length and style.
MCC: Much of the discussion around data breaches has shifted from prevention to response. How can our readers work with their CIOs or CTOs to best prepare their company for a data breach?
Westfall: First, companies are realizing that they need to take the response and risk mitigation aspect away from the CIO or CTO because their decisions are, and rightfully so, based on, “Does this follow our mission statement for the IT group? Does this come within budget?” The prevention side is shifting to a combination of the GC’s office and the CFO, since no one at a company can write a check as quickly as the CFO, whether it’s in budget or not.
Cybersecurity is about three things: people, processes and technology – the big thing being people. Attacks now are more of a social engineering experiment. The execution of the attack is sophisticated, but the initial entry point is not necessarily sophisticated. Our measures focus on how to better train people to be more aware of what’s going on in their digital surroundings and how to use our current technologies, and any new technologies that might be out there, to assist in prevention and mitigating risk. We even bring in business intelligence through data analytics and can identify what kinds of employees are more likely to potentially impact the company with a breach.
It really becomes a top-down effort from the GC and CFO’s offices, with cooperation from the CIO or CTO’s office, to understand what the risks are, what the attack vectors are, whether people are going to sites that they shouldn’t. How do we best prepare ourselves? Is it training so that they understand what a phishing attack looks like? Is it social engineering training so they understand that, say, a receptionist who answers the phone shouldn’t give out the names of everyone in the organization? It becomes an enterprise-wide solution.
Grimes: I would urge the readers to have their CIOs and CTOs prioritize information governance in parallel with incident response planning. Sadly, breaches are somewhat inevitable. Because of their size, most corporations tend to have data everywhere. The goal is to keep your data in order. With information governance, you set up rules to assess where your data is located, how long to keep it based on data type and regulatory requirements, and when to prune it to keep the smallest footprint possible. If and when an attack occurs, you know where your most important data is.
The same idea applies to e-discovery – you’re trying to minimize your overall footprint at all times so that you don’t have documents that you no longer need. If and when a breach or litigation occurs, you know that you have the smallest footprint possible, which will minimize your overall costs.
MCC: Who should be involved in preparing for and responding to a data breach, and how can those stakeholders best be prepared?
Westfall: One answer is that everyone in the organization needs to be involved at some level. But what we’re trying to get at here is who’s going to be in the incident response plan. It’s obviously the stakeholders who are identified by the C-suite as the internal custodians of data that needs to be protected. This drives forward from what Jack was just saying. What are we trying to protect, and who are the stewards of that data within the company? Or although they may not be the stewards of data, they’re at the table because they understand what data is out there, what the map looks like, and the impact on the company of that data being breached.
Where this overlaps with e-discovery is that a litigation response plan looks very much like an incident response plan, in that it’s an event-based scenario that requires collection, processing and analysis of data. The incident response plan addresses security incidents – not necessarily breaches but incidents. There’s a huge difference between a breach and an incident. Companies have developed litigation response plans by understanding that they have to go in front of a judge and say, “We’ve produced everything that is related to this litigation event,” and they know that they have because they know what the enterprise-wide data set looks like. The same goes for cyber. If you don’t know what you have, you don’t know what can potentially be breached.
Grimes: Skip’s answer is spot-on. Originally, incident response teams got involved early on, and they’d silo what was going on to a very limited number of stakeholders. Their goal was to get in, figure out what happened, remediate and move on. Now, with all of the different types of information that can be exposed during a breach and the regulations about what needs to be disclosed, that approach is too limiting. Although siloing is effective for containing the issue and preventing inadvertent disclosures, it doesn’t bring in all of the key stakeholders who might have a significant role in the decisions that need to be made.
MCC: What are the essential elements or best practices for an incident response plan? What is the importance of properly executing a response plan and its potential impact on future litigation?
Westfall: Jack and I have both harped on this in our previous answers: Know what data you have. If you don’t know what you’re trying to respond to, you don’t know what you’re trying to protect. Also, understand what outside influences apply to that data. Are you in a regulated business where compliance requires that that data be kept a certain way? Are regulators are going to look at data in a certain way? Companies slide a little on only protecting data within their four walls, but there’s data outside of your company that’s just as important. Is that data being protected under the same constraints that you’re using to protect your data in-house? Employee data, data via a third party for credit card processing – whatever the case, you’re still responsible.
Then understand what incidents require what kinds of responses. As I said earlier, an incident and a breach are different. An incident can be that you have a security policy that says don’t go to Facebook, and an employee goes to Facebook. That’s an incident that needs to be addressed. It might just be that the employee needs to be corrected on what the policy is. Another incident might actually be a breach, and that’s going to require a far different reaction. Have that mapped throughout the organization and understand what everyone’s role is in each one of those incidents and how to implement it.
Properly executing an incident response plan only comes after you’ve handled one a few times. I don’t mean that you have to have an incident to learn how to use a plan. Tabletop exercises are very popular. It’s an elongated fire drill, walking clients through the stages. And that applies to people outside of your organization as well. They should already be vetted and ready to go, whether it’s your e-discovery vendor, your security vendor or an outside agency. A big part of successfully executing your plan is having them ready to go before anything happens.
Grimes: Defining roles and responsibilities is an essential element of an incident response plan. When you’re in the heat of an incident or breach, it can be difficult to triage it quickly. Because of the vastness of corporate networks, malware can get anywhere and it can spread rapidly. Based on the severity of the situation, it becomes nearly impossible to foresee all of the considerations that you should have in play. The better you have defined roles and responsibilities, the more likely it is that you will be able to contain the situation more quickly and bring in the necessary support at the right time.
Following an incident response playbook allows you to think ahead and avoid the common pitfalls of being in a reactionary situation. For example, incident response teams commonly lose sight of their preservation obligations. In the heat of the moment, data preservation can become a secondary consideration. But in terms of litigation preparedness, data preservation should be a top priority. You have to blend two competing interests in the most strenuous of circumstances, and preparations made beforehand can be essential to a successful resolution.
MCC: Are there different protocols for the loss of different types of data – customer data, trade secrets, employee data or others?
Westfall: Absolutely. This is where the general counsel’s office is crucial to the whole process. Standard federal notification laws are still being pulled together. You’ll probably see that in the very near future, but presently there are a lot of different laws in different states surrounding what to do when you are breached, and the clock starts ticking as far as when those users need to be told what’s going on. We have to be aware of the regulations as an organization so that we can abide by them. The penalties are going to be severe enough as it is. You don’t want to take on that extra responsibility of replying to regulators because you didn’t correctly notify the individuals who were affected.
MCC: What is the government’s role in data breaches?
Westfall: The regulatory bodies are still trying to put firm guidelines in place. But no matter what your company is, whether it’s a bank, financial institution or hospital, certain things will have to happen, and the government will have its expectation that you as a company are going to execute a certain response, with specific criteria on how to respond and how it wants you to move forward. The government will always have a role in breach response from the regulatory side and the notification laws. It’s just a matter of how that evolves. It’ll be very different tomorrow than it is today.
Grimes: To add to that, one of the challenges is the difference between a domestic breach and a foreign government breach. We have seen a significant uptick in breaches. For example, the Eastern Bloc and parts of Asia have become a hotbed of cybercrime. When a company headquartered in the United States is breached by a foreign entity, it is extremely challenging to hold those parties responsible. I see the government taking on a larger role in protecting the U.S., not only from physical threats but also from attacks via cyberspace.
Westfall: Along those lines, the government has assessed what is mission-critical to the U.S. being able to operate, and that is an ever-changing target. Every day Jack and I see something that has made the government reevaluate what mission-critical is. Two years ago, interstate trucking was not considered mission-critical. Now, it has been added that to the list. On the other side, companies are going to the government and asking, “Am I now a mission-critical piece of the puzzle?” It’s something companies have to evaluate as well.
MCC: Assuming a breach will result in litigation, what should our readers expect? How can they best prepare and mitigate the risks and costs to their company?
Grimes: To reiterate our earlier remarks, your data footprint is very important. If you have a solid information governance policy in place, the hope is that you’re keeping your retained data at a minimal level.
Additionally, it is important to note that breach-related litigations could include nonstandard data types. For example, you’ll find that you’re preserving a large amount of noncustodial data – firewall, IDPS, DLP and SIEM logs. There may also be a large number of custodians who get swept into the litigation simply because they managed the data that was exfiltrated or were part of the team that assisted in the investigation.
Westfall: Companies tend toward under-preserving in an event-based response, and then they cannot go back later and re-create what was there. It’s difficult for companies to understand that a lot of the data that Jack and I deal with on the litigation side results from a breach. The data can go bad; the data can be erased under normal circumstances just as easily as the data that is part of the breach. The logs that Jack talked about, email that might get deleted in 90 days, etc. We constantly remind our clients that you don’t want to be in a position of needing the emails between the CIO and the president prior to the event occurring, only to find out that it was more than 90 days ago so you don’t have them. Without an information governance plan in place, you could be trying to play catch-up in the heat of the moment. You might miss something that later on could come back to really hurt you.
Published June 30, 2016.
