Kamran Salour - Welcome to part three of our three-part ransomware series. If you are still with me, I thank you. I imagine that you have a lot of CLE hours to compile at the last minute or you have a keen interest in ransomware or some other reason, I guess, but whatever the reason is, I'm happy that you are still listening to this presentation. Now you may recall in part one, we discussed ransomware in general, what it is, the types of ransomware that are out there. And then we talked about generally the response process for a ransomware attack, the various stages to respond to the attack. And those stages focus primarily on getting the organization that's been attacked back up and operational and minimizing the impact of the ransomware attack on the organization. And when we talk about minimizing impact, we focused in part on minimizing damage to customer relationships, minimizing damage to employee relationships, and of course, we talked a little bit about legal considerations to make sure that the attacked organization complies with any pending legal obligations, obviously to minimize legal liability stemming from the attack. And in part two of the series, we talked a lot about messaging. And messaging in the context of informing important people impacted by the attack, whether those people were employees, customers, third parties, vendors that you do business with. And we talked about when to notify those individuals or inform them of the attack, what to say, what not to say, and really whether to notify those individuals or interested third parties at all. We also talked about reporting an attack to the FBI.

We talked about the legal notification process at a very high level. And really we talked about how involved that process is because one of the areas where there's a misconception often in a ransomware response is we have to notify on day one. And I think we talked in some detail about why that is generally not a feasible approach. And then finally, we concluded part two with a discussion about the threat actor negotiations, some strategy, some common objections to reaching out to threat actors and ways to overcome those objections, because we talked in detail about why it is important to reach out to the threat actor because of the many benefits that the organization can obtain from doing so. And so really parts one and two had a stronger focus on the attack itself and responding to the attack itself. And now part three is gonna focus more so on the aftermath and how an organization can get to a position where they were pre-attack status, but ultimately in a position where they're better off if there is another attack.

And so we're gonna talk really about four things today. One, we're gonna talk about restoring network connections with customers. Two we are going to talk about third party contract management, Three, we're gonna talk about internal data management. And four, we're gonna talk about just protecting your company in general, going forward in response to a ransomware attack. And so one of the things that, it's very important of course is there is no fool-proof way to protect a company from a ransom event or a ransomware attack from occurring. But there are methods that a company can employ that will help reduce A, the likelihood of being attacked, but B, the impact of the attack. And we'll talk more about some of those procedures, but when we talk about those procedures, we're not gonna talk very much on a technical side. We're gonna focus more on a conceptual side of things that can be done, and frankly should be done no matter what organization you're in, because these are very important measures that really any organization can take and should take. So we'll talk about that as well.

But let's first talk about restoring network connection with customers. Now, what do I mean by that? Well, many situations arise when I'm dealing with clients where the client that has been impacted with the ransomware event or attack also stores data belonging to other entities. Now, sometimes those third parties have a network connection with the impacted organization. And through that network connection, they share information, in an automated process or some other means where that third party is connected to the impacted organization's network. Now, typically in those situations, the two parties, in this case the organization that has been impacted by the ransomware attack and that third party have some contractual relationship that governs the exchange of information between the two companies, governs the protection of that information, as well as governs notification if there is a data security event, however, that is defined under the contract. So when we're talking about restoring connection with customers, we are gonna make a couple of assumptions here.

One obviously of course, that the impacted organization does in fact, either store data belonging to third parties, or has some other connection with third parties where the impacted organization relies on those third parties for some type of information that third party provides through a network connection. The second assumption we're going to make is that the third party is aware of the incident or the ransomware attack. And whether they're aware of that by a contractual requirement or just a business goodwill environment type of reasoning is really immaterial, the fact is what's important is that third party is aware. And so once that third party becomes aware that there is a ransomware attack generally that third party is going to disconnect from the impacted organization's network. And they're gonna disconnect until they have answers about the forensic investigation.

So you may recall in part one, when we're talking about the forensic investigation, and we were talking about some of the optics, some of the optic value in the forensic investigation. And one of those things that we discussed was reporting the attack to law enforcement, also engaging outside council to guide the entity through the response process. And finally, we talked about the optic value of letting the third party know that you have outside third party forensic firm involved in the response process, and so, once you've messaged that third party that there's an incident, they're gonna want answers to those questions, and this is another area where we talked about where we have to be careful of the timing of our notification to third party, because one of the first questions that third party is going to ask is, okay, well, what about my data? And remember at the early stage of a forensic investigation, generally speaking, you're not gonna know answers to those main questions such as how did the threat actor get in, when did the threat actor get in, what information did the threat actor access? What information did the threat actor take? What have you done to stop this from spreading or what are you doing to prevent this from happening again? And so one of the things that's very important that comes up is having a set type of criteria where you can reconnect to that third party's network.

So what do I mean by this? I've had several clients where they were impacted by ransomware attack, as part of that attack, we had to notify some third parties that had network connections with ours. Those third parties immediately disconnected and they wanted to wait until a forensic investigation was complete before they would even consider reconnecting. And so one of the problems that you run into in this connection restoration process is a lot of the contracts that you'll have with your third parties talk about notifying the third party when an incident occurs. But what they often fail to talk about is what steps does the impacted organization need to take to regain access to that third party's network, or for the at third party to reconnect with the impacted organization's network? And without something tangible and previously agreed upon, this can create lots of delays in the response process. And with those delays, it's going to potentially impact business because you're going to need this information or this connection with that third party, generally for business purposes. And without that, you're gonna fall behind, or you're going to not be able to deliver on certain commitments because you're without this connection, and they're in turn without this information.

And so it's very important not only to establish with that third party that you have taken the appropriate steps and those steps could be hiring outside council, engaging a third party forensic firm, contacting the FBI, having a forensic investigation, all of those things are very important to instill confidence in the third party, of course confirming or demonstrating to third party that you have in fact contain the incident, and the spread of the incident is not likely to occur. But beyond that and what is often overlooked is having some criteria on how you can in fact re-engage with that third party's network. And without having your contracts really talk about these things, you can easily find yourself in a situation where you have an unsophisticated third party, and that unsophisticated third party may ask to impose some unrealistic requirements on you before you can reconnect, so for example, I've been in situations where we represented an entity, had a ransomware attack. We notified the third party that our organization has a ransomware attack. We've notified at the FBI. We obviously have outside counsel, we have a third party forensic firm conducting an investigation.

While that investigation is ongoing, we can demonstrate to you that the impacted environment is now clean the threat has been contained, and there are no issues with the third party reconnecting with the network. And many times that is met with objection, where the third party will demand to know those frequently asked questions in relation to a forensic investigation, right. How did the event occur, when did the event occur, how did the threat actor get in, what did the threat actor take, all of that. And while those are important questions to be able to answer, those questions are not relevant to reconnecting. And so the timing of a forensic investigation can vary, but it can be weeks and weeks before you have a completed forensic investigation and a business generally doesn't have weeks and weeks to wait before it can reestablish connection with a third party. And so it's very important to be able to educate the unsophisticated third party about what value of forensic investigation provides, but not having the forensic investigation be the holdup to reconnecting.

Another thing that can happen is if you have an unsophisticated third party, or even if you don't have any sort of contractual understanding in place is the third party may now seek to impose a slew of additional burdens on your organization before you can reconnect. And if those burdens are objectives, let's say, for instance, initially you did not have multifactor authentication as an organization, and the third party says, well, before we'll reconnect, we want you to have multifactor authentication. Okay, that's reasonable, but what's not reasonable is if the third party then says before you can reconnect, we must, we being that third party, must be confident in your security procedures. So provide us with a list of your security procedures. And we, as a third party will look at it and decide if we're confident.

Well, confidence is not an objective method of. As the impacted organization, you can't rely on a third party's confidence that that's going to allow you to reconnect because obviously confidence is gonna be subjective, and and that third party can then say, well, you've done all these things, but we're still not confident. So now what are you supposed to do as the impacted organization? And I've seen situations like this where it requires a lot of arguing and demonstrating that the sort of moving target approach is one that really ultimately bad for the third party's business. And so that's usually what will move the conversation so that third party moves off of that approach. But really the overarching point of this process is if you have better contracts in place with those third parties that speak to the criteria to restoring connection, you can avoid a lot of this back and forth. And when I'm talking about this back and forth, it can take weeks because you'll have to provide the proof that the environment is clean or evidence of new security measures to the third party, then that third party takes time to vet those procedures, evaluate those procedures. And then in invariably there's some back and forth with that process, and so if you have a contract in place, and as part of that contract, there is criteria that says, or excuse me, a provision that says we can, impacted third party, the third party agrees to reconnect with impacted organization upon the showing of X, Y, and Z and X, Y, and Z are objective.

So for instance, no evidence of alerts from an endpoint detection and response tool, confirmation that all passwords to all accounts have been changed, things like that are objective, that are quantifiable. That's gonna go a long way in helping expedite the cleanup process. And so let's segue now into just contract management in general with third parties. It's important, regardless of whether you're sharing data with those third parties directly through a network connection. But anytime you have data that, either a third party has yours or you have of that third party, it's very important to have contracts in place that are going to have some set definition about certain things. So one definitely is going to be the definition of an incident. Sometimes those contracts will just use the statutes language, sometimes they will ask for, they will define incident to include something such as a suspected incident or a failed attempt at unauthorized access. And so it's very important to have a set definition of what an incident is. And then It's very important to know, okay, well, if an incident is detected, when do I have to tell somebody, and what do I have to tell them? And so if you have these procedures in place beforehand, it makes that process much more simple and much easier.

Now, remember when you're going through an incident, you have lots of things you need to consider, and you're gonna have lots of competing interest between different people within the organization obviously have different interests and people, some people want to get up and running right away, security people may wanna wait and be more conscientious and cautious in the approach. And depending on what your role is in the organization, you may be being pushed and pulled in multiple ways. And so it's very easy to not know who you have to notify, when you have to notify them, what you have to say. And so if you are unaware of what your contracts say, obviously you're gonna be potentially in a situation where you have missed certain deadlines in terms of notifying customers or third parties, you can easily find yourself depending on if those contracts have damages provisions, you could find yourself increasing your risk for liability or damages. And you can also damage just your general business good will, right? Because if you have to consider that if you were in the third party shoes, and there's a chance that your data could have been jeopardized or compromised by a ransomware attack, that's something that you would want to know, and you would want to know that right away.

And so you have to balance all of those interests as you're doing this process, but what's important here in this cleanup process is that you want to make sure that A, you have contracts that have language that says, okay, what constitutes an incident? What requirements do I have once an incident is detected? Who do I have to notify, when do I have to notify, what do I have to say in the notification? You also want to have procedures in place where you have some objective criteria before you are going to restore the connection. And you also want to have a backup plan in place here where while that connection discussion is ongoing, you have another means of exchanging information.

So the company isn't at a complete standstill. And maybe the most important part of that discussion is making sure that all of those requirements that you have with your third party vendors is uniform. And what do I mean by that? Well, you wanna avoid a situation where you have, let's just say a dozen contracts with third parties. And in those dozen contracts, you have 10 different definitions for what constitutes an incident. You have multiple different procedures for notifying the impacted or potentially impacted third party. You have different requirements for when notification must occur, different requirements for the content of the notification. You have different requirements for restoring connection, because that lack of uniformity is only gonna create confusion. And it's going to increase your chance of making a mistake, because if you have to do something 10 different ways, the likelihood of you making a mistake and skipping a step with one entity that you didn't have to do with the other entity obviously is increased. So one of the important things that you should always do before an incident is to make sure that you have good contract management. And when we're talking about good contract management, we wanna focus really on three things for good contract management. Number one is to have uniform provisions in between your contracts, when we're talking about security, data breach notifications, we want those to be uniform. Number two, we want to have objective criteria in terms of restoring network connections.

And number three, we want to know where our contracts are. And what do I mean by that? Well, I've helped organizations respond to ransomware events and one of the questions I often ask is okay, well, do we have any third party contracts, contracts with third parties that require notification? And you would be amazed at the number of times the answer to that is yes, and then I say, okay, well, let's send me a copy of your contract, so I can take a look at it and determine what we to do of anything, and they will say, well, we don't know where our contracts are. And so knowing where your contracts are, especially in the heat of a ransomware event is critical because obviously without having access to your contracts, you cannot comply with the contractual provisions. And so an often-forgotten aspect of third party contract management, but knowing where your contracts are is essential to this process.

And another thing to consider as well is having multiple copies of these contracts, because if you are in a ransomware event and you have the contracts, let's say on a server, and that server is encrypted, and you may or may not have backups, but you may not be able to access backups right away. You may not be able to access backups at all. You don't have those contracts, you don't have access to those contracts. And so you need to have a secondary or even a tertiary copy of those contracts somewhere so you can in fact comply with those contractual requirements. So we've really focused so far on in the cleanup process, part one has really been third party contract management. And that's great for dealing with your third parties, but you also want to have a contractual management or data management internally as well, because that's going to help the process for you.

 And so let me give you a couple of examples. One - Now, let's say you've been hit with a ransomware event. You have a third party that has some of its data stored on your network. You notify that third party. The third party says, okay, well, what data of mine has been impacted? And if you don't have good internal data management in place, you won't be able to answer that question. Now also remember in a forensic investigation, it is not always clear what data was accessed to a very granular level. Sometimes you will know what specific files and folders were accessed, but sometimes you may just know that documents from this server were taken, but we don't know which documents and so the more you know about what data you have and where, the better off you're gonna be. And so this isn't limited to just with third parties now, even internally.

Let's say you have a ransomware attack and that server X was encrypted. You have no reason to believe any other servers were encrypted. You're gonna notify your employees and all of your, the employees are gonna want to know, okay, well, what about our human resources information that has all of our social security numbers, our dependent social security numbers, has that been impacted by this incident? If you don't know what you're storing on that server, you're not gonna be able to answer that question with any sort of confidence or certainty. And so if you don't have data management systems in place, it's gonna put you at a huge disadvantage. So it's critical to know what data you have and where that data is stored. Now, ideally you will have one server dedicated to, let's say accounting information, one server dedicated to HR information, you may even house, you may even rely on a third party for your HR or for your payroll, and those are stored in the cloud out by a third party. And that's obviously good for this type of situation, but it's very important to know what you have and where it is. And that's important, critically important for your response process.

 Now, some of you may be thinking and rightfully so that some organizations are so large, there's so many employees, that's a a near impossible task to know exactly where everything is and what's stored there. And and you're absolutely right. Now, a couple of important things to remember. If you have as an organization, certain policies and procedures, so for instance, let's just say that as a policy, all financial information must be stored on server X because server X stores all of the information in an encrypted manner, server Y does not, therefore no financial information should be on server Y. Now let's say that you have a ransomware attack, the attack occurs on server Y only, and you determine that there's data that's been exfiltrated from server Y. If, as a company, your policy and procedure is that no financial data is stored on server Y and you have reasonable policies and procedures in place to account for that, to memorialize that, there are, depending on all of the facts, let's just assume for this scenario, that financial information is the only information that would constitute personal information.

You could then avoid having to look at all of the data on server Y because you can take a reasonable position that as a company, we do not store financial data on server Y. The only personal information that we have is financial information, none of that information is on server Y, based on our policies, therefore this is a non-reportable event. Now, obviously that's simplified that situation quite a bit, but the point that I wanna make here is let's just say you take that approach, and it does turn out that there's a handful of financial documents on server Y and that comes to light somehow. That's okay, because it's important to remember that as you're going through this response process, your requirement is really to be reasonable. It's certainly not to be perfect. And there's always gonna be a chance where even if you looked at every document in server Y there's a chance that there's human error, somebody could have missed a financial document. And so you have to balance as an organization.

Okay, does it make sense for me to spend X thousands of dollars, and sometimes when we're talking about data management and looking at documents, we could be talking about hundreds of thousands of dollars to look for, to see if I can find one or two documents that have financial information versus me knowing what our policies and procedures are, having some reasonable confidence that those policies and procedures are followed and knowing, okay, well, based on what I know, this type of personal information is not on this server that was impacted, and you can make your conclusions based from there. So while internal data management can be seemingly an impossible task to a certain level of granularity of knowing where something is at all times, it's important to remember that it does not have to be perfect, it just has to be reasonable.

But that example that I just provided really sort of underscores why it's very important to have some data management in place because using that scenario, if you had to report to the employees, you could easily say rest assured, all the financial information is on server X. That server was not impacted. You could do the same type of thing with a third party, letting them know, hey, rest assured we've had an incident, all of the data, all of your data mean that third party that we store is on server X, server X was not impacted. So you can see by knowing where data you have, where it is, that can go a very long way in your response process. And that's why it's part of the cleanup process, 'cause what you want to do after you've gone through an attack, now, of course, ideally you will have had this done before you were ever attacked, and of course, ideally you would never experience an attack, but for purposes of this presentation, let's assume you've had the attack and now you are trying to clean up after the attack.

So if another attack does occur, you're in a better place. And so you want to have that internal data management and you also want to have the contractual data management because those are gonna be key in terms of, not only help with your messaging, they're going to be key in terms of your communications with your employees and third parties, but it's really gonna reduce a lot of your costs in terms of responding, because it could eliminate a whole swath of steps in the response process in terms of determining the type of information that was accessed or acquired and the contents of that information. Because you can say, well, none of that type of information is on these servers, therefore I don't even need to go through that. So let's talk now about prevention. And I say prevention with quotations because there really isn't any fool-proof way of preventing a ransomware attack. I know you might hear certain security companies say that they can prevent an attack and that's just simply not true, right, there's many ways that an attack can occur. And while you can have many great policies, procedures in place, many great security safeguards in place, there's always an opportunity for a threat actor to penetrate your system and deploy ransomware.

So the key in this process is just putting yourself in the best position. Not only to minimize the chances of being attacked, but minimizing the impact of the attack. And so here's an example I sometimes use when I'm communicating with clients, if you take from the threat actor's point of view, the threat actor is sort of looking for the easiest target. And so if you have a house that has bars on the windows, it has security cameras, it has an alarm, it has locked doors, closed windows, and a gate entering into the home, and you have another home next door that the windows are open, there are no bars. The looks like the front door is a little bit open. There's no cars inside, doesn't look like anybody's home. And if you're going to be the threat actor, which house are you gonna choose? You're obviously gonna choose that second house because it just looks like an easier target, right? That's not to say that somebody can't make a mistake at the first house, right, and for whatever reason, you let somebody see the security code so somebody can get in. But the point is that the harder you make it for the threat actor, the better you are. But what we're gonna focus on is let's just assume no matter what we've done, the threat actor is gonna get in. And so what we want to do is really just talk about what we can do as an organization, and I'm not gonna talk on a security technical side, but just what we can do as an organization internally, practically, that's gonna really help us in our response process.

And so first thing we've talked a little bit about this already today is data management. And when we're talking about data management, we've talked so far about having a, knowing where your data is stored. And we've talked about why that's important, but the data management is even broader than that. We wanna know how our data is protected when it's stored or if it's protected, so do we have, is our data encrypted at rest? If your data is encrypted, when it's stored, you have these, the state statutes for data breach and consumer notification have safe harbors where if the data that's been exfiltrated is encrypted and there's no access to the decrypter or the key, really to unlock that data, that provides you a safe harbor. Because if the data is taken but nobody can look at the data, then you really haven't triggered the notification obligation.

So it's very important to the extent you can to have, especially sensitive data stored in an encrypted state, but you also want to have a deletion policy. Many clients that I have, if we've had a ransomware event and there's exfiltration, and we're looking through to see the scope of notification, we have hr records going back 20 years for employees. There's really absolutely no need to have that information. Sometimes we'll have patient records going back 20 years as well. And so it's important to have a deletion policy because that's going to reduce your notification cost. Now, remember when we're talking about notification, there's a process where you have to look at the data that was exfiltrated or accessed determine the contents of that data and identify the individual associated with that data, and then notify that individual. So if we're able to eliminate or reduce that population just by getting rid, not storing data that we don't need, you're saving your organization lots of money and time in that process.

Another thing that you always want to do is setting up a system for transferring sensitive information. You don't want to have, for instance exposed passwords or social security numbers in a spreadsheet and send that spreadsheet an Excel spreadsheet around through your email, because if that email is accessed, then all that information is compromised. And so it's very important to have some procedures in place as an organization where if you use a share file system to transfer sensitive information, that's another way to reduce the potential notification population that you may have. if that data is not writing around in your email and it's encrypted through the file transfer system. And then we talked already about vendors and having those agreements with vendors, that's key to your management process. And then one thing to also consider is, okay, well what if your vendor has been hit with a ransomware attack and your vendor is no longer operational, what do you do there, do you have a backup plan in place? And so we're talking so far about data management, and I want to talk about some high level areas of security that if I do 10 ransomware matters, nine of the organizations that have been attacked with a ransomware have one of these situations as a result of one of these situations.

And so a lot of this came up when people were starting to work remotely because of the pandemic, but as you access your company's network, sometimes organizations would just allow you to do that through a remote desktop protocol or RDP. And if you have an open RDP, then threat actors can search for that, identify those open ports and use that to get access into your system,. So one thing you definitely want to do is eliminate open RDP, and you should employ a VPN that's password protected to prevent threat actors from getting into your network through an open RDP connection. The next thing that often comes up is, well, do you have multifactor authentication? And multifactor authentication can come in many forms. If you go to a gas station you're probably familiar when you swipe your card, then they'll ask you for a zip code, or if even at the ATM, if you put in your debit card, then they'll also ask you for your pin number.

So those are examples of multifactor authentication. More and more, you probably see it if you have to reset your password, they'll send a link and a code that they'll text your phone. It's just basically a second way of authenticating that you in fact are the rightful account holder. And so if you have a second means of identification required, before someone can enter into the network, that's just gonna be an extra layer of security that's going to reduce the likelihood of a threat actor getting into your environment. Now, of course, there's ways to get around multifactor authentication that we're not gonna talk about for purposes of this presentation, but almost always when we have a threat actor get in through email, through like a phishing link, it's almost always the case where the organization is sort of in the process of implementing multifactor authentication, but not fully done. So that's a very simple and effective way of helping improve your security posture.

And then the final thing we'll talk about is patching your software vulnerabilities. It's important to have a system in place internally where you are able to identify when a patch is available and to implement the patch. You may have heard of a Microsoft Exchange vulnerability that happened, I believe in March of 2021. And that led to lot of ransomware attacks, because if you did not patch your Microsoft Exchange server in a timely manner, then threat actors were able to use that vulnerability to get into your environment. And so invariably on those calls, when we had somebody that had a ransomware attack because of the Microsoft Exchange vulnerability, it turned out that for whatever reason, the organization did not patch that vulnerability. And so making sure you have a patching protocol in place, and that's one that you are able to monitor and employ on a regular basis, that's gonna go a long way as well of helping you. Always like to go back to that example of the the house with all the bars and the security versus the house with the open door. Again, the threat actor is gonna go for the house with the open door before he is gonna go through the house with all these extra levels and hurdles of security procedures in place.

Now there's some other areas where not only do you want to have security in place, but you also want to reduce the ability for anybody in an organization to access data. You want to keep that data on a need-to-access basis. And so sometimes you will come across an organization where everybody has administrative privileges. And that's not good because if a threat actor is able to compromise a user's credentials, and everybody has administrative privileges, now that threat actor has administrative privileges. Whereas if you limited administrative privileges to a select group of users, then the threat actor has to go to that additional level of once they're in, trying to obtain administrative access. And so you want to minimize your access to data as much as possible too. Now we've talked a lot about data deletion also, and not sending emails, not sending sensitive information through emails. But another thing to consider as well is outsourcing a lot of your sensitive information. More and more organizations that I represent are outsourcing payroll, outsourcing HR. And that, well, from a ransomware standpoint, reduces the population of sensitive data in your environment, and therefore helps reduce the impact of a ransomware event.

Now, finally, you always want to educate your users again, as many procedures and security policies and safeguards you have in place, there's always the element of human error. And phishing attacks are increasingly sophisticated and still people fall for them on a regular base. And so it's always important to have education in place. And education can only go so far, right? No matter what there's always a chance that even if you score perfectly on the phishing exam, you will fall victim to a phishing scheme. That's understandable but is important, if for no other reason than from an optics standpoint, to have some sort of phishing procedure or education in place, because again, when you're doing those notifications, one of the things that individuals will always wanna know is, well what are you doing to prevent this from happening again, even though that's an impossible question to answer in to say because nothing can prevent these from ever happening, but to say, hey, we are increasing our security posture, and we are implementing new educational methods to remind people not to fall victim to phishing attacks, something along those lines can go a long way from an optic standpoint in your response process.

Now, another thing that's important is to assess your backup policy. Do you have backups in place, are your backups off-network? So in other words if, a ransomware attack happens and it impacts a server, and you have backups for that server on the same network, well, the chances are that ransomware's gonna spread to your backups too, and so your backups become encrypted as well. And therefore they're not useful. So it's important to have offsite backups or on a segmented network so if the ransomware does impact your server, the backups are not going to be impacted as well. It's also important to have a procedure in place to check that your backups are actually backing up. Many times, I've talked with clients and they said, oh, we had a backup in place, we never checked it. So when we had the ransomware attack, we thought we were okay because we assumed we had backups, what we went and we checked and our system was never backing up. And so it's very important to make sure that not only do you have offsite backups, but they are in fact backing up.

Now, another thing that you want to do is as you're sort of cleaning up and preparing yourself for another attack, and I don't wanna say that in a sinister fashion, that you're always going to be attacked, but in the event of a subsequent attack, to the extent you don't have cyber insurance, you want to get cyber insurance. And we talked a little bit in part one about the importance of cyber insurance, so not only is important for freeing or deferring, I should say, some of the costs of the outside vendors, potentially the ransom amount and potentially your business loss. Obviously that all depend on what type of coverage you have. But one of the most important things about having cyber insurance is the insurance carrier will put you in contact with the experts in the legal side, experts on the forensic side, experts on the threat actor negotiation side to help guide you through this process. Now, it's obviously one thing to have cyber insurance, but make sure that your coverage is adequate. I've come across many clients where their coverage is very small, maybe $5,000 or $10,000. And so if you're facing a ransomware event, chances are that the ransom is going to be much larger than five or $10,000. And chances are your forensic fees and legal fees are gonna be larger than five to $10,000. And so it's really not doing you a lot of good from a dollars and cent standpoint if your coverage is only five or $10,000. So it's important to make sure your coverage is adequate.

Now, another thing that I recommend that organizations do is have an incident response plan. And that incident response plan should identify the important decision-makers, if an incident happens, who needs to be notified internally of an incident, who do you need internally to make decisions on whether to pay a ransom or whether to engage who has authority from your organization to sign engagement agreements, or vendor agreements. And so it's very important that you have a plan in place, and it's maybe even more important that you go through that plan on a periodic basis to make sure that the plan is workable. And so a lot of times I'll deal clients that they had an incident response plan or an IRP, they never really went through it. And so one of the things they forgot to do was have a copy of their cyber policy handy because that policy was on a server and that server was encrypted, and so they didn't know who to call or when to call, they couldn't find that information out. So if you actually go through your incident response plan, you'll be able to identify instances where, oh, you know what, we need to add this, we need to add that. So obviously it's important to have an incident response plan. In that incident response plan, you definitely want to have a copy of the contact information for your cyber carrier. And you also want to make sure that you have access to your incident response plan off the network, or at a hard copy of it's somewhere. So if your systems or your network is encrypted, you do have access to this so you can in fact, call your cyber carrier and report a claim. You also want to have out-of-band communications. It's, great to have those ready, because when you have a ransomware event, sometimes you're just not even gonna have access, you're not gonna have access to your network, 'cause you will have unplugged that access. But just having out-of-band communications ready, helps expedite the process as well.

Now again, the goal here, and the goal that remains throughout this entire ransomware event process is you want to minimize the impact on business operations. You want to minimize the impact on customer relationships. And that's gonna be the same throughout. And what we focus on here in part three is minimizing business impact and customer relationship impact really in two ways, one from the business side is having data management internally, as well as having some basic security procedures in place. Those basic security procedures are going to, on the one hand, increase the barriers to entry into your network to making it harder for the threat actor to get in. Having the data management is going to make it easier from a business standpoint to then know what data is where, and hopefully if you've honored some deletion tactics, minimize just the universe of data that could be exfiltrated. And if you're encrypting sensitive data or only exchanging sensitive data through share files and not through general email, you've once again reduced the notification pool. From a customer relations standpoint, we talked about third party contracts and how those contracts should have provisions for notification, but those provisions should be uniform. So you, as an organization are not forced to have to contend with multiple different definitions of incident, multiple different means of notifying. As well as having objective criteria in place to restoring the connection. One of the most time consuming aspects of a response process is dealing with third parties, dealing with third party security, giving them the assurances that they are looking for, that the network is now clean and ready for the connection to be restored.

So just to summarize here, what we've talked about, as the goal is always the same is we want to minimize the impact, and so almost taking this from a reverse chronology standpoint. Part three, we talked about having those procedures in place obviously if implemented are going to help with part one and part two. And so if you do have good contract management, if you do have good internal data management, if you do have good security posture in place, if you are, one, the like you getting attacked is less, but two, if you are attacked, then the impact on the organization is going to be less because you know where your data is, who you have to notify and when, and you should have a smaller universe of data. And having that smaller universe of data and knowing where your data is and where it is not is obviously gonna be critical when you're talking about messaging. It's gonna be critical when you're telling your employees that their payroll information and HR information is safe. It's gonna be critical telling this to third parties about their data. It's gonna be very helpful in your negotiations with the threat actor. If you know that the threat actor does not have, has not accessed certain servers, and those servers have information on them about financial information and those have not been accessed, then you can determine better the, whether to pay a ransom and the amount that you're willing to pay based on you have much better knowledge about what information is potentially impacted.

And so I hope you were able to gain from this three-part series, a couple of things, one that it's always important to be prepared for a ransomware attack, And the best way to be prepared for that is to have knowledge of what your data, what data you have, where you have it, to have knowledge about what your contracts with third parties require, and to have cyber insurance, to help if you are attacked. Those are gonna be really critical in the process. And then once you have an attack, it's very important to rely on the experts, that those experts guide you through the process, and they can guide from start to finish and get you to a place where, a better place than you were before the incident happened, because ultimately you're going to respond to the attack and you're going to even put better security procedures, better policies in place, contractually, data management-wise, to help reduce the likelihood of something like this happening again.

So I wanna thank all of you for tolerating me for three hours. I know there was a lot of information in here but I hope I was able to convey to you really sort of the key components of a ransomware attack, some of the key considerations from a strategic standpoint, as well as from a legal standpoint, in terms of responding to an attack. I believe the slides here have my contact information. If anybody has questions that they'd like to discuss with me, I'm more than happy to speak with you about that. I wanna thank you for your time, thank you for listening. And I hope you gained some valuable information about ransomware, how to respond to a ransomware and ways you can help an organization reduce the likelihood of ransomware attack from happening. Thank you.