[Webinar] What to Do After a Breach

Learn How to Strategize Best Practices That Will Jump-Start Your Response Efforts Keep You in Control Post-Breach

• The Difference Between a “Security Incident” and a “Breach”
• What NOT to Do Post-Breach
• How to Strategize an “Incident Response Plan”
• Roles of Your “Incident Response Team”
• Your First Point of Contact
• Advice on Internal and External Communication
• Legal Considerations
• Rapid Recovery

Panelists:

• Brandon Harter | Russell, Krafft & Gruber, LLP
• Shawn Melito | BreachQuest
• Meredith Bennett | USLI
• Ben Tercha | Omega Systems

Transcript

Bob Guilbert (00:00:04): Good morning, everyone and welcome to our second webinar today. This webinar is entitled What to Do After a Breach, and my name is Bob Guilbert. I’m a strategic advisor and the former COO of Eze Castle Integration, and I am the moderator for today’s discussion. We all know cybercrime is increasing at a mind-numbing rate every day. We are not only hearing about the reports but also feeling the personal effects of cybercrime. It’s unfortunate but not shocking to hear reports from 2021 stating an organization suffered ransomware attacks every 11 seconds, but what is shocking is also believed that 80% of cybercrimes are not even reported due to embarrassment or fear of reputational harm, and so forth. There is good news, however, and there are a lot of real-world examples and scenarios we can use to prepare. With that, today are a number of experts are going to help us understand the repercussions of cybercrime on a daily basis and they’ll explain how maintaining trust after a breach is achievable.

Organizations today should operate more on an IF scenario and not a win scenario mind frame, and they’ll find this approach is probably the best context for this webinar. With that being said, we’re going to talk about incident handling and how to jumpstart your response efforts immediately. With that being said, I’d like to kick off this with a couple of introductions from the organization who are participating in the panel today. Shawn, if you may go ahead and introduce yourself.

Shawn Melito (00:01:40): Thanks. I’m Shawn Alito, Chief Revenue Officer for Breach Quest. We’re a data forensics and incident response firm. I’ve been at this for about 15 years now. Got my start in Canada. Actually, a competitor of ours hired me to open their Toronto office many years ago, so I apologize if I dropped the occasional “aboot,” but I have been living in Pennsylvania for the last seven years and I have been working very hard at trying to get rid of that.

Guilbert (00:02:10): Excellent. Brandon.

Brandon Harter (00:02:13): Hi everybody. My name is Brandon Harter. I’m an attorney and partner with Russell Craft and Gruber. It’s a Lancaster, Pennsylvania-based law firm. I have an area of specialty in technology law including data breaches and privacy and the laws that implicate those.

Guilbert (00:02:30): Welcome. Thank you for your participation. Meredith.

Meredith Bennett (00:02:34): Thanks Bob. And thanks to Omega Systems for inviting me to be a panelist today. Meredith Bennett, I’m Vice President Tech Cyber and privacy practice leader at USLI. USLI is an insurance company located in Wayne, Pennsylvania. We’re a part of the Berkshire Hathaway family of companies and we specialize in low-premium, low hazard business specializing in tech and cyber.

Guilbert (00:03:00): Cyber. Excellent. Welcome Meredith and Ben, if you would please.

Ben Tercha (00:03:04): Yep, good morning everyone. My name is Ben Tercha, Vice President of Operations with Omega Systems. Omega Systems is a leading managed services provider, managed security services provider headquartered in Reading, Pennsylvania. In my role with Omega, I have the benefit of working with many of our customers and internal staff to develop and implement product and service offerings for our customers, which allows our customers to focus on their core business while allowing Omega systems to handle their information technology and cybersecurity needs. Thanks everyone for joining. I hope you enjoy our discussion today.

Guilbert (00:03:37): Thanks a lot, panelists. I appreciate you participating today. And with that, I’m going to start off with Ben. So, Ben, and I think this question is applicable to everybody. Generally speaking, preparation always alleviates some pressure when responding to unexpected incidents, but what are some of the things that can happen when those preparations aren’t in place? And I’ll let you kick it off.

Tercha (00:03:57): So, from our perspective, it’s going to be the inability to identify the threat of ‘respond’ and ‘recover.’ So, identify knowing that there’s an attacker in your environment actively either in reconnaissance mode or actively carrying out an attack. The ability to respond, meaning stop the threat, get the attacker out, and then recover such as recovering from backups, decrypting data if it has to be done, and things like that. So, that’s from the technology side. If you have a communication side to be concerned about how you’re communicating this potential incident to your employees, to your customers, maybe mislabeling it as a breach instead of a security incident. So, that’s kind of our perspective. I think Brandon also had a few other thoughts as well too.

Harter (00:04:49): Yeah, and some of those, not just how it’s responded to by your customers and your employees, but there’s going to be governmental agencies, there may be regulators at the federal or state level who are involved, and making sure that you put your best foot forward in those circumstances is also important. Plus, at the end of the day, the more aggravated you get those end users, whether they’re regulatory or consumers, the more likely you’re going to get involved in litigation, the more likely you’re going to have other sort of incidents that stem from that. So, not just the damage control, but really the practical ramifications can be altered by the timeline.

Guilbert (00:05:25): That makes sense. Meredith, how about from an insurance perspective? What can you do if they’re not in place? What preparations can you make?

Bennett (00:05:33): Buy an insurance policy? A great way to be prepared is to make sure that you have an insurance policy. Be familiar with how your insurance policy will trigger. So, I think we’ll probably get into that a little bit more as we talk about our plan, our incident response plan. But it’s really important to communicate with your insurance agent as to how that policy is going to respond and trigger and what is covered and what is not covered.

Guilbert (00:06:08): That makes perfect sense. And Shawn, do you have a perspective on that same topic as well?

Melito (00:06:14): Yeah, for sure. The number one thing that we see mistakes that clients make if they’re not prepared or knowledgeable about how to handle a data breach is they either wipe or start rebuilding systems until they’ve spoken to a forensic expert. Apologies, it’s a little self-serving that I actually we’re a forensic team, but until you talk to somebody who really knows what they’re doing on the forensic end of things, you really should not start. You should definitely not wipe, and you should not start rebuilding systems until you’ve got the signoff for a forensic expert, because we’re going to need to image machines, we’re going to need to do analysis to figure out how the breach occurred, who was affected. And unfortunately, if you start wiping or rebuilding, we may not be able to do that. And depending on what industry you’re in, Brandon will go into more detail on this, especially healthcare, if you can’t prove that you’re innocent, you’re guilty and you’re going to have massive charges on notifications, and they’ll have to talk to AGs and all sorts of things. If you can’t prove I didn’t actually have a breach, I just had an incident, it’s all contained.

Harter (00:07:26): Yeah, it always reminds me of back in the day when you had to get tickets on the turnpike, if you lose it, they just assume that you paid for the whole state. That’s fair.

Guilbert (00:07:34): Exactly.

Harter (00:07:35): Same concept. If you can’t identify who was affected, they’re just going to assume it was everybody and away we go.

Guilbert (00:07:41): Well, it’s a great lead to the next topic for everybody and that is I’m sure all of you have a perspective on actual scenarios that you’ve all come across within the various organization firms that’s never had a plan in place. So, why don’t we start with Meredith this time, why don’t we go from you?

Bennett (00:08:00): So, actual examples of when a plan was not in place.

Well, we’ve had situations based on our policy language, we need the insured to communicate with us right away. The insured is not to have any expenses without checking with us first. So, if you are not aware of that and that’s not part of your plan and you go ahead and hire forensics or hire a loft team and then nine months later after everything’s done and finished, come to us and say, oh yeah, I forgot to tell you nine months ago we had a breach and these are the checks that we wrote and can you reimburse us? That’s not how our policy works. There are policies out there that they do have reimbursement wording, but you are required to use people that are on their panel. So, again, if you used X, Y, Z, and you did not use Breach Quest for your forensics, that may not be reimbursed anyway. So, that’s an example of when there was no plan in place.

Sometimes the plan that is in place may be really simple and that could be contacting your insurance carrier. That’s what I know I need to do. And an example of that was really small nonprofits. We’re talking really small nonprofits. They are their own tech company and they say as they say, cook and bottle washer, they just know that they need to contact our claims department and that may be the simplest of breach response plans and we’ll get into more complex ones obviously, but their breach response plan was to contact the carrier and we were able to put a law firm in place and get forensics in there right away to help that small nonprofit. So, even if that’s all you know is to contact your insurance company, that’s a great place to start.

Guilbert (00:10:14): A good example for sure. Shawn, do you have a perspective as well on the actual scenarios you’ve come across?

Melito (00:10:21): Yeah, well we occasionally it’s pretty rare because most of the work we do is for cyber insurers, but we will occasionally get firms reaching out to us directly. They’ve had a ransomware incident or a business email compromise and when they don’t have insurance, they don’t have a business plan. I’m not making this up, there’s about a 50% chance that this is a business-ending event for them. They’re probably going to go at a business because they don’t have the financial backing from an insurer to potentially pay the ransom or cover all their costs for recovery if they don’t have a plan in place. They’ve probably done things wrong from the start, and I don’t want to be a fear monger, but for about half of the firms that we talked to that come to us completely unprepared, it usually means they end up closing their doors either immediately or within a few months.

Harter (00:11:12): And building off of that, Shawn, one of the things that’s common, not just as Meredith mentioned, sort of rushing out and hiring professionals before going through the right process is this analysis paralysis of not knowing what to do first. So, you sort of call your legal counsel that you use for your day-to-day work, and they don’t really understand and they say, okay, let me think about it for a week. Don’t touch your server in the meanwhile because we have to figure it out all the while the attack is going on. Or even if you’ve unplugged stuff, your systems are down, your IT folks haven’t started rebuilding yet, you’re waiting for the forensics team, and all of a sudden, you’re knot down for a week or two just figuring out what your first step is going to be, figuring out who’s supposed to be on this team. And that can be a death nail for a company as well, not just responding to the breach, but you basically have said we can’t work for several weeks. A lot of companies can’t withstand that. So, some of it is just knowing what’s step one, what’s step two, what’s step three, so we don’t have to sit here and overthink it each step of the way.

Guilbert (00:12:08): Makes sense. Not only do insurance policies have coverage for the breach itself, but a lot of them have the business interruption portion coverage as well, so you’re going to be reimbursed for lost sales or revenue or however it’s calculated at your organization. So, I’m going to just twist it over to Ben for a second. Ben, as a managed service provider, you’re providing a lot of IT support and infrastructure services for your client, but yet I’m sure you’ve seen actual scenarios out of control. The MSP that employees or individuals at a firm might’ve done to basically re the happen in the organization. Any commentary there?

Tercha (00:12:48): Plenty of instances. Yeah. It’s unfortunate that usually we’re called after the fact, right after the ransomware attack, after the $250,000 was wired to someone’s account and it’s what do we do? And from a prevention perspective, the attack has already happened, so there’s not much we can do there, right? The ransomware attack, usually when we’re pulled into those types of after-the-incident scenarios is we will look to do an initial assessment, make sure there’s no active threatening environment, and at the same time tell our customer to call your general counsel, call your insurance policy holder of your policy, get them on the phone, start working with them because they will have generally an incident response plan and steps to take. And as Meredith said earlier is sometimes our services may not be reimbursed if we spend 40, 50 hundreds of hours, you’re going down this path. Sometimes that’s not covered by the insurance policy.

There’s a lot of times though where we can do the forensic investigation, we can write a report and say, yes, this is, here’s exactly what happened, and sometimes these are 30-page reports, 50-page reports. Sometimes they’re even just smaller than that. But we’ve had several customers who decided to remediate on their own, just started, well, yeah, we had this attack mount, this backup and I’ll copy all the files back, and then they never actually got rid of the threat, so it happened again the next day and the next day and then they’ve compounded the incident sometimes. When the initial first call, getting us engaged, we could probably clean it up and stop the threat in a much shorter amount of time with less interruption to the business.

Guilbert (00:14:29): That’s super helpful. Makes sense. Thank you. Brandon, I’m going to redirect it towards you to try and get a legal perspective here and that is when is it appropriate to call a breach, call it a breach as opposed to a privacy incident? How are these handled differently in the terms of the law?

Harter (00:14:45): Sure. So, people often throw around the term ‘data breach,’ meaning any time that they’ve got some kind of virus or malware or attack on their system, but data breach is actually a specific legal term of art and it involves unauthorized access to information that creates usually a substantial or a likely risk to personal information. And if you have all three of those elements, then you have a data breach. If you’re missing one or more of them in many jurisdictions, you’re not going to have one. And it’s sort of the difference between saying, I murdered somebody or somebody died while I was there. It makes a difference whether you’re self-proclaiming that you’ve had an incident and you want to be careful, particularly with regulators and customers saying one when you really mean another. The tricky part of course is I made it sound really easy that, oh, we just apply this three-step process to do a breach.

The problem is that all 50 states, the federal government, several different regulations in the agency world all have different definitions for what a breach is, what personal information means, how much of a risk there has to be, how much you have to know about it, all sorts of different things. So, it can be a little bit complicated to figure that out on your own. It’s one of the reasons why there’s counsel who specializes in looking at these sorts of scenarios, and a lot of times the answer is going to be, I don’t know until the forensics finishes their work because I have to see specifically what went out the door before I can make a determination as to whether this is a breach or a security incident. So, a security incident is any time you’ve got something that you suspect that you need to investigate that you need to respond to, it becomes a breach when it meets that legal hurdle.

Guilbert (00:16:21): Makes sense. Meredith, from an insurance perspective, there must be also some, I’ll say difference of view if you will, relative to what is a suspected security incident. Do you have a perspective from the insurance side?

Bennett (00:16:37): Yeah, so our policy wording is going to respond if it’s a privacy breach security event or suspected privacy breach. So, it pretty much triggers as soon as you say, I think something’s wrong. That nonprofit example that I gave you earlier, we did have someone that took over the accounting and clicked on the link that said, hey, you need to update your software, and as soon as they hit the update your software, they had that feeling like, oh my god, I think I just downloaded a virus. I mean we’ve all been there, I’m sure I’m not alone here. You get that feeling in your gut, you contact IT. In this case, this nonprofit contacted us, and we sent forensics in there and it turned out that it was a legit update and everything was fine, but we had still paid for that forensics investigator to make sure that that was a legitimate software update and everything was fine and that was covered by the policy. So, there is definitely a difference with that wording. So, if you’re having a fun Friday night reading your insurance policy, make sure that it has that broad language.

Guilbert (00:17:55): Friday night only, huh? Okay. Ben, Shawn, and Brandon, a deeper question here. Can you guys explain the difference between the rules of your internal tech folks, whether you leverage an MSP or an MSSP, your forensic experts, attorneys when Breach Recovery is involved? So, maybe Ben you could start.

Tercha (00:18:17): Yeah, so Omega Systems, we have our own internal teams for our customers, so we have our own internal incident response plan, risk management, how to deal with a breach, who to communicate with. Thankfully Omega has never suffered any of these types of breaches ourselves, but we’ve worked with several of our new customers and existing customers who had suffered some type of incident and we’ve coordinated with their insurance carriers, their attorneys to be their expert witnesses, boots on the grounds, compiling reports, data restoration if needed, ransomware payment and recovery services. So, a very broad spectrum from our side.

Guilbert (00:19:00): Excellent. Shawn?

Melito (00:19:02): Very similar to what Ben just said, except we’re the ones that get called if you don’t have a Ben, so if you’ve got a cyber insurance policy and you haven’t got a Ben, then we’ll get the call and have all the same sort of services that Ben just mentioned.

Guilbert (00:19:19): Right, makes sense. And Brandon.

Harter (00:19:22): So, we sort of take over, we’re there once you’ve figured out what’s gone wrong, what’s gotten out the door or not, we’re making that determination with our clients about is there a breach and if there’s a breach, what does that mean? Who has to get a notice? How do we have to send the notice? When do we need to send it? Do we need to tell regulatory agencies? Do we need to tell our vendors? Maybe we need to look at our agreements with our providers. Do we need to tell them something about the fact that there was an incident here? So, we sort of take that factual information once it’s gathered by the Shawns and Bens of the world and apply the legal framework to it to advise them what they need to do with that information.

Guilbert (00:19:59): So, do you have a view of what type of exact information should be gathered to validate? Is it a breach or not?

Harter (00:20:05): Sure. There’s a lot of information, but the most important ones are what went out the door. So, is it personal information or not? Was this just a list of names? Were there social security numbers in there? Were there bank account numbers? What kind of information was there? And number two is how much of it went out the door? Did this affect some segments of your customer base? Is it the entire customer base? Is it only people in a particular state? How early was the incident caught that you can say only these files went out the door, these lists went out the door. That’s also important in determining not just whether it’s a breach, but also who has to be notified if it was a breach. And again, this is, you lost your ticket in the turnpike example, if you can’t tell me what went out the door or how much of it went out the door, then we’re going to start by saying, okay, I’m assuming that everything in your system went out the door. Let’s tell all those people, which is usually a great way to make people’s jaws hit the floor when you try to explain who we’re going to get that notice out to.

Guilbert (00:21:05): That’d be a scary scenario. Shawn, how about from the forensic side, and what information should be gathered to validate a breach?

Melito (00:21:14): The most important thing we gather is something called logs, and those are small little files that reside on every single computer and server, and in that data will be who logged on when, what data did they access, what did they look at, what did they potentially download? And we gather, we actually have us and all of our competitors, of course, we have automated programs that actually go in, go across the system, grab those log data from every single computer and server, bring it all back to a common program, which we can then delineate through and very, very quickly figure out which system was patient zero, where did the attacker come in, where did they migrate to, what did they look at, et cetera.

So, that’s one of the, if anybody takes anything away from this call. And one of the top things is log data can be set for how long you keep it, and it should be kept as long as potentially necessary for an investigation. So, we like to say 90 days minimum. If you can do longer than that, that’s even better because if you’ve got your log set at only storing for 30 days and you find out the breach at day 31, it’s going to be very difficult to do a proper investigation. And of course, if it’s a ransomware attack and they happen to have encrypted the logs, then of course there’s all the fun with that too. Hopefully, there are backups, or we may potentially pay at that point. We’re not sure, but it certainly makes things interesting.

Harter (00:22:46): Yeah, and I’ll also add building off that, Shawn, we were talking about the information that you need for purposes of deciding if there’s a breach and responding to it. Some of that information about how the attack occurred is also important to prevent it from occurring. Again, a lot of people who are the victims of these kinds of ransomware or other sorts of security incident attacks end up being attacked multiple times. They basically keep testing the back door to see if you’re leaving it unlocked. And so not knowing how it got in doesn’t give you as much information about what should we be locking, what security should we be taking to block this from happening again, which is the last thing that you need after you survive one of these attacks to get hit a second time.

Guilbert (00:23:26): Makes perfect sense. I’m going to keep rolling through some of the areas I’d like to get covered here through this webinar and that is I want to change gears and I’d like to discuss something called the IRT or the incident response team. Is this the team you put together before or after the breach? Why do you do it? Who should be on the team? I’d like you guys to run us through why an organization should have that in place and maybe we can start with Shawn to answer some of those questions and provide his perspective.

Melito (00:23:57): Great, thank you. So, yeah, who’s on the incident response team is one of the key components of your IRP or incident response plan, which is something that every organization should have. I’m sure you all behind the HR manager’s desk, you’ve got a binder for fire, and you’ve got a binder for flood and there should be one for a brief response as well.

Who’s on that team is going to depend on your organization, but you definitely want somebody from the C-suite. Usually, I find usually it’s the CFO or an equivalent, you’re going to definitely want somebody from IT and your MSP if you’re using those services, so like CISO or a VP of it, you’re going to want somebody, if you’ve got a chief privacy officer, you’re going to want to have them involved as well. Potentially somebody from risk management if you’ve got cyber insurance and then if you’ve got marketing, you potentially have them as well. I mean basically you want a representative of each part of the business that’s going to be impacted by a data breach and the decision-makers that you’re going to need. Is there a legal perspective, Brandon as well on this?

Harter (00:25:07): Yeah, I think Shawn uncovered the bulk of it, which is you’re going to want to have enough players internally or from your vendors to be prepared. Your forensics company and your data breach council will eventually be added as part of that, but your incident response team is going to the people on the ground who first react to this once you’ve notified your insurance carrier, and a lot of times the insurance carrier is going to drive who your data breach council is and if they’re bringing forensics in, so I wouldn’t worry too much about necessarily leave those chairs open at the table, but you don’t necessarily have to have them filled the second that it starts, but the last thing that you want to do is get this team together and then figure out, oh, we don’t have anybody from it here. We don’t have anybody to relay this instruction, or we don’t have anybody who has enough authority to make decisions about whether we’ll pay for X or Y. And so now we’re all sort of hamstrung because we’re trying to keep this process moving and somebody’s got to wait for somebody to write a memo to get permission to do it. So, just make sure that there are enough players to be making decisions.

Guilbert (00:26:05): Can you articulate maybe you or Ben articulate a little bit more about what are the roles exactly of these people that are on the team during an incident? What do they have to do?

Harter (00:26:16): Ben, you want to take a shot at this one?

Tercha (00:26:18): Yeah, so the people on the team are going to be really based upon their job role. I think Shawn and Brandon really covered it well. You need people from many different disciplines inside the organization. So, your team members, right? So, we’ll use Omega Systems as an example. We have our security team, we have our data center team, and I really akin an incident response plan to a DR plan. That’s probably something that everyone can relate to is if you have a building disaster, you know how you’re going to recover servers, and where they’re going to be, and how your users are going to run. Our DR plan pages are almost 50 pages long and it’s facilities, it’s operations, it’s data center staff, it’s everyone. Each one plays a critical role in recovering the business in the event of a disaster. The incident response team is very similar is that you have marketing from a communications perspective, it’s controlling that narrative to the outside world. What happened? We don’t know if it’s a breach yet. We just know it’s an incident and that’s what you then involve legal counsels to guide the team on that course. So, the team are the people who first discover it and kind of amass everyone and say, all right, we have an incident, we don’t know what happened yet. You call legal, you call insurance, you preserve logs and that’s the role of the team from our perspective is to stop, assess, and then work through the different guidance and professional expert opinions.

Melito (00:27:46): I think the important thing when it comes to the team to remember is at least in 99% of the cases that we handle is it’s the breach coach or it’s the Brandon of the team is who’s in charge, who’s driving. We say they’re driving the bus. We actually work for, we work for the client, but we also work for the breach coach. All of our agreements are three parties, so we are maintaining privilege. I’m sure Brandon is going to talk about this later on in the presentation, but we are working for the breach coach along with the client. They’re telling us what to do, they’re providing us direction and they’re really in charge.

Guilbert (00:28:26): Yeah. I’m going to ask Meredith, from your perspective as an insurer, do you care who’s on the incident response team?

Bennett (00:28:36): We do not get into that. We just ask that they have one.

Guilbert (00:28:43): Got it. As long as the team is in place, that’s what’s key. Okay. To follow on to having the IRT in place, it’s always very good practice to deploy something called a tabletop exercise. So, maybe we could ask the panelists here to describe what a tabletop exercise is, what are the most important things that should be done, frequency of things along those lines. So, Shawn or Brandon, if you guys want to interject here, it’d be great. Brandon, your take?

Harter (00:29:13): So, your tabletop exercise is sort of like the fire drill for fire plans. It’s the ‘Let’s practice so that we don’t run around like chickens with our heads cut off when we get to the actual thing’. A lot of times it’s sitting around a table with all those members of the incident response team and a scenario comes in where, okay, we’ve had this kind of attack, let’s walk through who’s going to do this, who’s going to be contacting that person? Who’s going to be contacting this? And it’s a great way to find holes in your incident response plan. Oh, nobody wrote down the number that we’re supposed to call with the insurance carrier. When we have a breach and it’s after business hours, nobody wrote down or updated who the new person at the MSP is that we’re supposed to be in touch with. Let’s tighten that up. Nobody bothered to figure out whether it had a seat at the table, all that sort of things. You can find a lot of those holes with a tabor clap exercise and they can be as small as let’s just get the people in the incident response team together and sort of practice, just go through the motions and see what happens. Or you can actually do them in a significantly more complex level. Shawn, I think you have more experience with those outside vendors more than I do for tabletop exercises.

Melito (00:30:20): Yeah, larger organizations and one’s a bit more of a budget for a tabletop will bring in their actual breach coach that they’re going to use should they have an incident, they’ll bring in their forensic provider. The forensic provider can provide some real nightmare scenarios. And I actually like, I don’t know, make me sound like a bit of a nerd, but if you remember Dungeons and Dragons, it’s very similar to that. So, you sit down, there’s the Dungeon master, usually it’s the breach coach who leads it and you walk through an entire event and play it out beginning to end on how it’s all going to go. And you should have people coming in and giving you PR curve balls. You should be saying, okay, now suddenly you get a call from the FBI or suddenly you get a call from Brian Krebs. How are you going to handle that situation? You don’t know. Brian Krebs is, he’s the boogeyman of breach. You don’t want a call from him.

Guilbert (00:31:17): You do not. And I’m sure there’s lots of interesting scenarios that could be created and tested with this team. Meredith, have you seen any interesting ones from your perspective?

Bennett (00:31:29): I had the opportunity of being a part of one of those third-party vendors that came in and it was really eye-opening, very scary and it really makes you as a participant, think on your feet, think fast on your feet and it really does open your eyes to things in the holes that you may have, such as if the news calls you or the employees, if the employees are asking all kinds of questions and you didn’t communicate to the employees, now they’re creating more chaos for you when you want to focus on the breach, when it would’ve just been really simple if you had a plan in place to communicate with all the employees to let them know what was going on and not to say anything.

Guilbert (00:32:16): Right. Maybe templated would’ve been a good approach to have with the employees. At least let them know what is going on. Yeah. Shawn, do you have a view on what is the exact purpose of the IRP?

Melito (00:32:27): Just preparation in one word. The more prepared you are, the better you’re going to be able to handle it. The more encompassing your IP is, the more topics it covers, the better you’re going to have a handle when a situation occurs. And just to reiterate, make sure you’re keeping it updated and you’re doing tabletop exercises based on it regularly.

Guilbert (00:32:55): So, let’s dig into the IRP for all panelists here. I’m going to start with a question that was submitted prior to the webinar by an attendee and they asked the question, will unplugging the server from the internet protect or prevent anything further from happening until remediation can occur? And I guess we can start with Ben, and we’ll get Shawn’s perspective as well.

Tercha (00:33:20): Yeah, so from my side, I would say we need to define the word unplug. What are we unplugging exactly? So, if we are unplugging power from the server during an attack, that’s a no-no. A couple of different reasons why, when you unplug the power, there’s data, there’s information contained in the memory of that server that is lost as soon as it loses power. So, if you don’t have a SIEM platform, if logs were potentially wiped or couldn’t be accessed, there’s still data…

Melito/Guilbert/Harter (00:33:58): Did I just lose Ben, or did we all lose Ben? I think we all did. He was demonstrating for us what happens if you unplug the server…

Tercha (00:34:15): I’m back, sorry. So, yes to internet, no to power.

Guilbert (00:34:21): Yeah. Makes sense.

Melito (00:34:24): Yeah, no, I completely agree with Ben. I’m not sure what you said when we lost you there, but you also want experts doing this. You don’t want the president of the company going in there and she’s pulling out wires. Most people know what the front of a server rack looks like. If you look at the back of a server rack, I mean there are literally thousands of wires and if you start unplugging to know where they’re supposed to be plugged back in again can be an absolute nightmare and literally add weeks to your recovery time. So, you can definitely power off servers properly if you want to try to save the day doing it that way. But yeah, definitely no unplugging power wires, and only unplug what if you know what you’re doing.

Guilbert (00:35:07): Most likely never. Connectivity is a start. Brandon, do you have a perspective relative to the IRP and validation documentation privilege contained therein?

Harter (00:35:20): Yeah, so obviously one of the purposes of documenting the plan in writing is so that it can operate smoothly and it can go through, but there’s also a validation element of as well, basically if you’re being accused later, hey, did you act reasonably in connection with this event to try to protect people’s information to try to respond appropriately. Having your documented plan saying yes, this was what we prepared for, we did what we were prepared for, and so you’ve got that all buttoned up and consistent with legal standards is a really great way to do it. A lot of times people think about reasonably protecting information being just a, well, did we have antivirus? Did we have firewalls? Did we have security features on the front end? And that’s good, that’s part of the puzzle, but as we alluded to at the outset, just the way that cybersecurity is working these days, it’s more of a question of when you’re going to get hit, not if you’re going to get hit. And so as a result, having the response on the backend and validating that’s consistent with your legal obligations is important depending on what organization you have. Shawn indicated earlier if you’re protecting personal health information and HIPAA is involved, you have different validation, different documentation requirements. Then if you’re just storing a list of your client’s email addresses.

Guilbert (00:36:36): I have a follow-up question to you before I ask Meredith or insurer perspective, and that is who is responsible for writing this? Is it outsourced? Is it in-house that writes it outside? Counsel who typically takes the first pass at writing this plan?

Harter (00:36:51): It can come from a couple of different places because it requires a collaboration between your legal counsel and some internal folks who actually know who’s going to be part of the organization, who’s going to be part of the team. I would say in most instances when I do it, I end up starting the draft and then we have people fill in information where they need to do it or get some additional information, but it happens the other way around as well where you start internally and then ask for legal counsel to approve, but you’re going to need both boots on the ground and legal counsel to go through the process.

Guilbert (00:37:21): Thank you for clarifying that. Excellent. Meredith, from an insurer involvement perspective on the IRP?

Bennett (00:37:26): Sure. Well, we do want our insureds to have an incident response plan in place If they don’t have one, we typically say, well that’s okay. Can you do a solid and within the next year put one in place because we understand a lot of businesses don’t have one and they don’t even know how to get started. So, there may be people that are listening that are like, this is great, I know I need one, but how do I get started? We provide tools that will help direct them. So, when they buy a policy with us, if they don’t have an incident response plan in place, we say that’s fine. Put one in place. You have a whole year until your renewal is up to put one in place. And we direct them to the tools that are provided to them as part of their policy as to how they can implement one. There’s free templates, there’s resources that can assist them with putting one in place. There’s multiple levels that are available to them, so that’s how we get involved.

Guilbert (00:38:32): That makes sense. Thank you. Brandon, you touched upon it earlier regarding communications and the point of the sword here. In terms of doing that, can you comment on who handles communications typically and also comment if your clients are regulated or you might have investors as well?

Harter (00:38:51): Yeah, so I’ll break this down into two kinds of communications. One, you’re going to have the mandated types of communication things like we’ve had a data breach and I have to tell the end user, we’ve had a data breach and I need to tell the state attorney general’s office or I need to report this to the feds. So, that’s one level of communication where there’s going to be specifics about when that has to come out, what it has to say, what level of detail has to be in there, but you’re also going to want to coordinate communications for the softer stuff that we’ve talked about. How do you minimize damage to your reputation by reporting it to the community? How do you respond to the newspaper if they catch wind of this? How do you tell your employees what’s going on when your clients are screaming, ‘Hey, where’s my thing? I wanted you to get me this thing yesterday. Why haven’t you given it to me?’ Well, you can’t usually just say, ‘oh sorry, our whole network’s down, we had a data breach.’ I mean, that’s going to create some disruption in the community, so there’s a soft part of the communications as well.

Guilbert (00:39:46): Got it. Meredith, back to you. From insured perspective, how is the case typically triaged?

Bennett (00:39:55): So, as soon as there’s an incident or a suspected breach, the insured should contact the insurance company and we would assign a Brandon or a breach coach to kind of run as quarterback, and Brandon’s going to work with Shawn or Ben to get forensics involved. And as he said, then based on that we’ll determine if notification is necessary. I do want to point out, Brandon talked a lot about what’s legally required. You have to notify the people whose information was affected. You have to notify the State Attorney general and any other regulatory agencies. There’s also something called voluntary notification. So, what if based on the information that was taken legally required to notify Pennsylvania residents, but that’s not part of New Jersey’s law, I’m just kind of throwing out a scenario you would want to let New Jersey residents know anyway. So, there is something called voluntary communication or maybe the information legally you don’t need to tell the people because it doesn’t fall under the data breach law of that state, but you want to tell them anyway like, hey, your name and address and email address is out there so it doesn’t fall under personally identifiable information under the state, but you want to let them know anyway.

So, that’s a conversation also that Brandon would have based on what forensics involved. And then from there, it’s all the notification costs. Is there a ransom that needs to be paid? Was your business, do we need to pay business interruption? Does your data need to be restored? These are all things that happen after the initial notification to the insurance carrier.

Guilbert (00:41:46): Got it. I want to keep moving along. We want to leave also questions and time for questions at the end by the audience participants. Brandon, I’ll go back to you real quick. So, when and why is it appropriate to leverage legal counsel in these scenarios?

Harter (00:42:00): Yeah, so legal counsel is important for some of the reasons we already talked about, making sure you know what your deadlines are, making sure you’re complying with it. But there’s an additional level for privilege purposes, and Shawn mentioned this earlier when we were talking about breach coaches. The attorney-client privilege protects communications between a client and a lawyer so that way you can get legal advice if you are having internal discussions about what data breach requirements are or what the notifications requirements are, and there’s no attorney for you in the room. Those communications are not necessarily protected by privilege, meaning they would be discoverable in a lawsuit, meaning somebody could ask for those communications later on, which creates a whole other level of headache where you now have to be careful about what you say or what you ask because this stuff could come out later. Having the lawyer involved putting the umbrella of privilege, that’s why there’s a three-party contract where the lawyer is signing with the forensic expert in addition to the customer, helps shield those communications so that way you’ve got a safe space where you can talk, ask questions, do what you need to do without the fear that information’s going to be coming out in a court of law down the road and it just provides some grease to the whole process that makes it go better.

Guilbert (00:43:12): Sounds like a sound practice out of the gate. Absolutely. To involve legal, I guess to both of you, Brandon, and to Shawn, can you guys cover the types of questions that you guys are going to run through immediately in terms of what you want to look for out of the gate?

Harter (00:43:31): Sure. So, we’re going to ask.

Guilbert (00:43:33): Maybe Shawn, you could lead.

Harter (00:43:34): Yeah. Go ahead, Shawn. No, go ahead.

Melito (00:43:37): Well, no, actually let’s do it chronologically. Brandon, why don’t you, because you take the first call? Usually, there’s a call with the client before I get on the line.

Harter (00:43:48): Yeah, the first thing we’re going to ask is what happened? What machines do we know are affected? And what kind of information was on those machines? Did you have health information? Did you have credit card numbers? Is it just pictures of people? What kind of information is in there? And then last, but most importantly, have you notified your insurance carrier? And if you didn’t, hang up the phone with me and call the insurance carrier and then we’ll come back to answer the rest of these.

Guilbert (00:44:23): And then I get on the line after that and my questions will be a lot more technical. Where is this equipment located? What type of equipment is it? What type of software is it running? And then we build from there and we come with a plan of attack of we’re going to need to send two people on site. We need to send one to New Jersey. We need to send one to New York. We need to gather these pieces of equipment. We need to run this software. We can do this remotely. We can’t. So, it’s going to depend case by case. But Brendan starts with a 30,000 foot view, then we come down to about 10,000 feet and then we hit ground level either remotely or with an onsite team to get the data we need. Let’s go to that five foot level when you’re there. So, take us through the proceedings of the actual breach investigation and I’ll leave part-time for you, Brandon, as well to cover. So, Shawn, why don’t you go ahead? Actually, I’m going to let Ben take that one because he’s a lot more technical than I am.

Tercha (00:45:16): So, that’s where we start the log investigation. We’re pooling Windows event logs. We’re leveraging a SIEM platform if the customer has one. Sometimes if we get into an environment and we find there are no logs, then we’re recovering servers into a sandbox off the network and reviewing log events there. But it’s that initial investigation so we can identify how the attackers got in. Are they still in the network? Do we need to lock them out? Are they on a pc? Are they on a server? Is it some guy sitting in the parking lot on the wireless ap? We’ve seen a lot of different weird scenarios that we’ve been called into, but our goal is to identify and then sometimes we’re that first call from the customer. So, we’ll start that. We’ll start the investigation and we’ll direct our clients to call your attorney, call your insurance carrier.

Tercha (00:46:07): Now get them involved. We aren’t the experts. We aren’t going to be able to label this as a breach versus security incident. We don’t know who you have to notify. That’s where we’re going to leverage counsel and steer that. So, usually we’re involved right away. We will stop the attack, we’ll identify the systems that are compromised, and then we’re just kind of waiting for guidance sometimes from legal or whoever else, the insurance carrier, sometimes they have their own team who comes in and wants to do their investigation. We’ll work side by side with them, give them virtual tour, show them what we’ve collected, share it with them. We’ve worked with the three letter agencies before from an information sharing perspective to share the data that we gathered during an attack so they can carry out charges against the people. So, our involvement is usually first early on and then usually after the fact from a recovery perspective.

Tercha (00:47:02): So, we’ve captured all the information, we identified how they get in, we stopped it, now we need to recover. Businesses recover, what is that right? Are they paying the ransom? We generally don’t facilitate the ransomware payment, the insurance carrier, whoever else would do that, but we can help from the recovery process then. And then after it’s recovered, then there’s usually a betterment. How do we stop this from happening again? Your firewall policies weren’t configured properly that needs to go, and you don’t have a firewall that has UTM. You don’t have a, your backup system is still tape. We should probably look at maybe upgrading those things. Don’t laugh, Brandon.

Harter (00:47:38): No, no tapes. Please. No more tapes. No more tapes.

Tercha (00:47:42): Let’s increase your defenses so that if there is another attack, we can respond quicker and we can recover quicker.

Guilbert (00:47:51): Ben or Shawn, do you guys have a perspective on how long the investigation takes or what the costs are associated with it? Yeah, so super easy case, like a single user business email compromise, we can turn results. We have all the programming to automate that. We can turn results as quick as 24 hours and it’s as cheap as $5,000. A full-blown ransomware attack. The worst I’ve been a part of was in excess of a hundred million. The ransom itself was 30. A lot of systems they decided to rebuild, restore. We assisted with that and between legal fees, fines, well in excess of a hundred million. I know this is making merit’s skin crawl, but that’s what we see on a daily basis, especially with larger organizations.

Harter (00:48:47): And the time can grow exponentially if you’re not responding to it correctly or you’re making a mess of it. For anybody who remembers the city of Baltimore got hit with a ransomware attack and their system for recording deeds was down for weeks and weeks and weeks. You couldn’t sell houses, you couldn’t engage in transactions because they didn’t really know what they were doing and they sort of flailed around about whether they were going to pay the ransom or not, and they weren’t. And they were. And then they stopped. And I mean that was months until they were back to normal again and even then had to catch up on everything that was down.

Guilbert (00:49:16): Domino effect for sure. No doubt about it. Meredith, what’s the view? Does the past breach get factored into lack of coverage or higher premiums for the end user? What happens?

Bennett (00:49:31): I would say in general, yes. It all depends on the situation. It depends on the carrier, it depends on what they have filed, if they’re an admitted carrier or not, what they have filed with the state. Typically, if you’ve had a past incident, the carrier’s going to want to know what you’ve done to make sure that you don’t have another incident of that kind if you’ve taken precautions just like in any type of insurance. But I will say, I think it was mentioned earlier that those businesses that are hit with ransomware tend to have repetitive events because the people try and target them again and again, especially if they pay. So, that’s kind of known and is taken into consideration, but the size of the claim is definitely going to be a determination how new it was. If I have someone that comes to me that has never had coverage before and had a breach five days ago, we’re not going to be able to provide you with coverage. So, there’s a lot of different factors at play.

Guilbert (00:50:40): Makes sense. Hey Ben, from a technical perspective, obviously having 2020 hindsight is great, but any common cybersecurity elements that customers can take to move forward to help them basically prevent this?

Tercha (00:50:57): So, I think a lot of people take that what they have is good enough. They take it for granted, my firewall is good enough, I have the in-house. Guys can take care of it if something happens. And that’s just generally not the case that we’ve seen. The line in the sand from a security perspective is always changing. It’s always getting pushed further. When I started my career 20 plus years ago, there weren’t firewalls and then a firewall was good enough and then you just needed a firewall and semantic antivirus was good enough. And now that’s not the case, right? There’s managed detection and response. There’s EDR platforms. There’s firewalls aren’t really firewalls anymore. There are many PCs and servers that have to be maintained with their own application updates and the baselines from a lot of manufacturers are constantly changing. You used to do it this way six months ago, now you need to do it this way because of whatever reason.

Tercha (00:51:53): Performance, scalability, security reasons. So, I think a lot of what we’ve seen is people take what they have put in place three, five years ago for granted. That’s good enough and it’s just not the case. So, we do a lot of security assessments for customers. We have our baselines of what we feel all of our customers should have, and we can do an assessment and say, you’re missing these five things if you don’t have these five things, here’s what it means and here’s the cost to remediate it if needed. If you want to go down that path, that could be a one-time fee or it could be a monthly recurring fee depending on what level of engagement they’d like from Omega.

Guilbert (00:52:27): That’s great perspective, Ben. Thank you. We’re reaching the closure point for the webinar, but I want to give the panelists an opportunity to kind make closing comments and think about it in terms of what are the lessons learned here? Can we control the narrative of what’s happening, the reputation associated from if a breach does occur, what piece of encouragement you may have to lead with the views of the webinar? And lastly, what the last piece of advice you’d like to share to give basically confidence and view in the event there is a breach. So, why don’t we just go down the line and Shawn, why don’t you kick it off? So, just to say it again, preparation, the more prepared you are, the better you’re going to be able to handle the breach. From my perspective, any decent firm that handles breach response, like a breach quest, I know a lot of the breach coaches do this, reach out to us ahead of time. We don’t bite, and almost all of us will do an hour or two of consultation upfront for no charge. Look at your systems and what you’re doing and help you potentially with starting an incident response plan or fine tuning it. We want to get our foot in the door with organizations just as much as everybody else. So, reach out to your breach coaches, your forensic firms, everyone ahead of time and build relationships with ’em. That’s great, great counsel.

Harter (00:54:04): Yeah, I think the reassuring thing, if there is such a thing is that while these attacks have gotten more and more complicated, the tools and the resources that are available to fight them are also much more. So, you go back a decade and you were having a data breach event and it really was a question, well, who are we supposed to call? Or is somebody going to be available? Now, whether it’s through your MSP, whether it’s through your insurance company or a combination of the two, there really are clear steps for, look, you have a breach. It’s 1230 at night, you call this number and we’ll get everybody get on the horse, and off we go. So, if you take the time to know what those things are in advance, you can be prepared for these events without being a fiscal or a technological expert yourself. There’s a lot of help out there from presenters like this, and for those who are taking their time to attend something like this, you’re definitely on the first step.

Guilbert (00:55:01): Excellent. Thank you, Meredith. Your perspective, please, Brandon.

Tercha (00:55:04): That was very well said. Just take the time to get to know your resources like your insurance agent, like your insurance carrier. Does your insurance carrier offer any value added services that are going to help you with this? A lot of the carriers, do we offer cyber risk management that is complimentary with your policy? Find out what that is and use it because that’s why it’s there.

Guilbert (00:55:33): Ben.

Tercha (00:55:35): Yeah, I think all my other panels cover it really well. It it’s preparation. Have your internal plan. Know who you’re going to reach out to. Establish relationship with those people prior, having prior to needing them, have them go through their own kind of checklist and process, right? Don’t take things for granted. Don’t think if you think of my IT security is good enough, check, right? There’s plenty Omega. We will do a site assessment, generally free of charge, give you, here’s our recommendations. If we want to dig deeper and do a full scale InfoSec assessment, we can do that as well too. But preparation, don’t take things for granted and leverage the resources you have if there is an incident.

Guilbert (00:56:22): Thanks, Ben. I’m just looking at a couple of questions submitted. I’m going to put them out there and I think Brandon, you might be best suited to answer this first one. The question came in was asked while working through the forensics, do you find attackers or Insider Threat Act is often having significant amount of time to do due to organizations not being equipped to identify security threats in early stages.

Harter (00:56:49): Yeah, so I do think that’s a significant part of it, that sometimes when these events start to occur, there is no outward sign. It’s not always, the virus hit my system last night, and so now I get the black screen of death or blue screen or green or whatever Windows 11 is up to the next morning when I log in. And if you’ve got intrusion detection software, you can start to see when information’s starting to bleed from your system when there’s unusual activity and you can shut those gates early. So, it’s really important to, it’s sort of like diagnosing cancer. The earlier you can catch it, the better your odds are of being able to recover from it, and so that kind of early detection is really important.

Guilbert (00:57:34): We have two more minutes here, so I’ll just go through a couple of more questions and it’s really probably for Brandon and Meredith. Are there certain circumstances where you recommend paying a ransom after a ransomware event That’s really a business decision that there’s just going to be a hundred factors to that. What systems are locked up? What systems can we rebuild? Do we want to rebuild them? They’re Windows 2020, it’s we’re going to feed Brandon a whole bunch of data on what we think, but it’s really going to be Brandon and the client’s decision on whether they pay or not. Yeah, there’s a hundred factors that go into that. Paying a ransom is always the last worst-case scenario. I mean, it’s the absolute last thing you want to do, but if a $50,000 ransom is going to save you $5 million worth of business interruption, then it’s the smart. Unfortunately, it’s the smart move. Either Ben or Shawn answered part of the question earlier, but there was a recommendation for log retention earlier. Is 90 days the minimum, but what is the preference? What do you guys recommend?

Tercha (00:58:43): We usually, for our customers who are on our SIEM platforms, we do a year, it kind of ties into the first question that was posed to Brandon about the time the attackers are in the environment. We covered it in our webinar. Usually, when you see the attack happen, it’s too late. It’s very rare where they’re on day one, they launch the attack. Usually, they’re in for days, weeks ahead of time doing reconnaissance, discovering systems, planning their attack, and it’s not just how they’re going to launch the ransomware. How do I stop you from recovering? I’m going to figure out what type of backup systems you have. I’m going to figure out who your administrators are, and they kind of build out this automation script, and then when they launch it, they’re launching it, clearing their logs, clearing the backups, and sometimes even just getting out of your environment and then waiting for you to pay or establish communications with them to negotiate. So, yeah, we usually like to see a year because sometimes 90 days would be the minimum. We hold data for a year. We’ve had instances where it’s been a couple of months where there’s something that happened, or if you’re tracking back to who made a change that potentially let the attackers in. That change could have happened months before the attack happened or the attackers are in the environment.

Guilbert (01:00:00): Makes sense. Last question before we wrap up here. Does the use of cloud platforms like Infrastructure as a Service or Platform as a Service make this process more difficult when there’s a breach?

Harter (01:00:14): Short answer is yes because you’re adding another player that you have to communicate with the cloud platform. You can’t just say, hey, Shawn, send your guys down here. I’ll open the closet for you and you can get in. It’s doable. But yeah, it’ll add an extra layer of complexity.

Guilbert (01:00:28): That makes sense. Well, panelists, I want to thank you all for participating in the webinar today. What’s to Do after Breach? It’s been great to hear your thoughts, perspectives, and great insights. With that being said, we’re going to conclude the webinar now and we look forward to the next webinar that will be hosted by Omega going forward. Thank you very much for your time. Have a great day. Thanks, everyone.