Kamran Salour - Hello and welcome to part two of our three part series on ransomware.

 

In part two we're gonna focus on four topics. We're gonna talk about messaging, reporting to the FBI, notification and threat actor communications. Now I hope all of you that are listening now sat through part one because in part one of this series, we talked about a ransomware event, the types of ransomware events and provided an overview of responding to a ransomware attack. And part of that discussion, we touched upon really all of these topics. We touched upon messaging and its importance throughout the process of... Throughout the response process. We talked about reporting to the FBI. We talked about notification and we also talked about some threat actor communications. But we just touched the surface in part one and so in part two we're gonna dive a little bit deeper in these four areas.

 

So just as a quick recap, in part one we talked really about the six main stages of a ransomware response and we talked about engaging vendors, containment, restoration, data collection, forensic investigation and assessing legal obligations. And really what we're gonna focus on now in part two is I'm gonna call it stage nine for purposes of this presentation. But it's really dealing with third parties.

 

And what do I mean by dealing with third parties? Well it really comes down to messaging, reporting to law enforcement, notification and talking with the threat actor. Those are really the four areas that we're gonna focus on today. So when we're talking about messaging and I'm gonna group this into really third party communications and when we talk about third party communications, it's very important to know what to say. It's also very important to know what not to say and it's also important to know when to say certain things. Now often when I have a client that I'm helping respond to a ransomware event, they've already gone ahead and they've told their employees we've had a ransomware attack. And sometimes that creates panic. Sometimes that causes the employees to start talking to friends and then word gets out and now you have potentially PR issues to contend with as well because you have to respond to media requests about "Oh, we understand that your organization has suffered a ransomware attack. Tell us everything you know about it."

 

Conversely, I've been in situations where it was very clear that the client had suffered a ransomware attack and it was very clear because all of the systems for the company were encrypted and there were ransomware notes on pretty much all of the workstations. Yet the organization leads wanted to tell the employees that we had just suffered a network interruption. And so what's the point of me telling you these stories? The point is this. It's always important when doing the messaging to third parties to really be mindful of your audience and that means that there is not a one size fits all message that's going to work in every situation. It's very important to consider the community that you're in, the type of company that you have, your relationship with your employees, the level of sophistication of your employees. If you're dealing with a tech savvy company and you try to tell the employees that this is a network interruption, that may not go over very well because the employees will understand that you are lying to them. So you have to consider, you have to always consider your audience.

 

And so whenever I'm talking about messaging in a ransomware event, I always wanna think about four main things.

 

One is who we're going to message. Sometimes that means we're going to talk to the employees right away. Sometimes that means we're gonna talk to important customers of the attacked organization. Sometimes that means we're gonna talk to vendors of the attacked organization. Sometimes that means we're not gonna say anything. It's really going to depend on the audience. And all of this is the under arching theme of all of this is we wanna do what's best for the organization, what we think is going to minimize the impact of the event on the organization, both from a business side as well as from a legal side. And so we're always gonna consider who we have to message.

 

 We're also gonna consider when are we gonna send this message. And I know there's often an instinct from clients that you wanna let people know right away and it's better to let them know that you have the situation covered, that you're aware of it and you're on top of it. And while I certainly understand that instinct and in many situations, that is the appropriate approach. Again, that's not always the case because sometimes it, again, this goes back to pending on who your audience is. Sometimes you will go and message a ransomware attack to a third party and that third party may not be sophisticated and experienced in data security events or ransomware events and they will expect that all of the answers that are natural, that are gonna come up, will have already been answered immediately. And what are those questions? Well as a third party, you're gonna wanna know how did the attack happen. What can be done to prevent the attack from happening again? What data of mine, mine being the third party here, that the organization that was not attacked, what data of mine has been impacted and what are you gonna do about it? And really you don't have answers to those types of questions immediately in response to a ransomware event. And so the timing of the message to third parties is important.

 

 If you know that the third party or suspect that that third party is not sophisticated and they're going to expect and demand these types of answers, that may caution you to delay speaking or messaging the event to them. Conversely, if you know that this third party has been in a similar situation, maybe they were attacked or maybe that your relationship with them is such that you know that they're going to be very understanding and very appreciative of the information and they will know that hey, these answers to these questions about how the attack occurred, how the attack could be prevented, what data has been impacted, those are questions, the answers to which will take time. And if they're understanding of that, then it makes sense to message that third party sooner rather than later. And so you have to balance the pros and cons of messaging and you should always assume that if you message one customer or one employee or one subset, everybody else is going to know so you have to make that assumption and so you have to balance all of the people that are potential recipients of this information, whether intended or not, whenever you're doing the messaging.

 

Now in addition to considering who to message and when to message, it's very important to know what to say in the message. I know a lot of times people wanna be very apologetic in their messaging. People wanna promise that they will provide updates every 12 hours, every 24 hours on some sort of daily basis and those instincts, it's a pretty natural instinct in that situation. You as an organization that's been impacted or are sorry that this has happened, you are sorry that the attack has caused an inconvenience to these third parties, but promising things that you can't deliver is not helpful. And so again, when you're responding to the attack and you're trying to find out those questions, how this happened, what data has been impacted, you don't know how long it's gonna take you to find answers to that. And so often I find with clients that they wanna sort of provide information on a 24 hour basis or daily basis. I tend to advise against that because what happens is you're really saying I don't have any more information at this time, our investigation is ongoing. And if you continue to say that, it creates two problems.

 

One, it becomes sort of notification or message overload where now people are not going to, when they see the message, if you're sending a daily message or daily update, they're going to react very negatively to that because they're going to know that the information is, there's no valuable information in there. And so they have maybe a tendency to then miss when something is valuable because it's sort of information overload. And that can tend to frustrate people as well because again, people are waiting for answers and if you keep telling people, "Hey, I know you're waiting for answers. I don't have the answers, I don't have the answers," people sometimes just want you just tell me when you have the answers. Don't tell me that you're looking for the answers or you're investigating to find the answers. They know that. They just wanna hear the answers.

 

The other potential area where this causes problems is you're not gonna have, you're not gonna have anything to say and so that can create frustration for these third parties because they're gonna say, "Well what's taking so long? Why does it take you so many days to figure this out?" And so it's very important to know what to say in the message so I always counsel clients to not promise anything because when you are responding to a ransomware event, lots of things can change and they can change very quickly. And there's no point in promising something to them that you may not be able to deliver. It's also important to not use certain words like hack or breach because breach has a legal definition and generally speaking, at the outset of a ransomware attack, you don't know if a breach, as defined by the relevant laws, has occurred. And so if you use that language, then that's when people start using... The recipients of this information start to use that language and start characterizing a data security event which is what has transpired where you have suspected unauthorized access or acquisition of information. You don't know if that's actually occurred yet because you don't know the scope of access. You don't know the scope of exfiltration and you don't know what type of data has been taken if that data would... If the unauthorized access or acquisition of that data would constitute a breach under the relevant laws. You just don't know that answer yet and so it's very important to not use the term breach or hack. And so it's just as important as knowing what to say, it's also important to know what not to say and certainly saying words like breach and hack is definitely discouraged, but it's also important to not overly downplay the event.

 

So we talked a little bit about sometimes people wanna call it a network intrusion or technical difficulties. That's why our systems are down. You know, maybe a few years ago, organizations could get away with that type of messaging, but I think in this day and age where ransomware is recognized as a common event, I think it's harder to get away with making a statement like that because again, people are more and more sophisticated and customers know that hey, if your systems are completely down for days and days and days, that's not a network interruption. That's probably gonna be something a little more sinister and it's always good to get the bad information out sooner rather than later and not to provide some sort of misleading information. So I tend to discourage clients from saying network interruption when we are doing the messaging. I like to be upfront with what we know, upfront with what we don't know, but I don't like to promise certain timelines about when we will have this information. So there's an art to this messaging because you have to take into account who your audience is as well as the timing and the content of the messaging. Now what I've talked about here is mostly going to apply to incident messaging which is sort of messaging that happens right after the incident occurs or as your investigation, as your forensic investigation of the incident is ongoing. But there's really more than one type of message so let's talk about the different types of messaging that come into play when we're talking about a ransomware response. So we have statutory messaging which is going to be the message that you will get at the end of the investigation if in fact the ransomware attack constitutes a breach.

 

Now you may have heard of breaches with like T-Mobile, Barnes & Noble, Marriott. You may have received in the mail a consumer notification letter alerting you that there was a breach and as part of that breach, some aspect of your personal information, maybe it was social security number, maybe it was a bank account, driver's license number, was accessed or acquired without authorization. You may have even received an offer of complimentary credit monitoring as part of that breach. That is the statutorily required messaging of the incident. And that's going to be very different from the other type of messaging. That statutory required messaging, the content is largely gonna be dictated by state statute. The timing of that is also gonna be largely dictated by state statute. So that's one type of messaging.

 

There's other type of messaging called contractual messaging which sometimes organizations will have contracts with vendors or third parties that require those organizations to report a data security incident within a number of hours after suspecting it. Now this is contractually required messaging and depending on the contract, it may require the timing of the messaging. It may dictate the content of the messaging, but that is a different type of messaging from the statutorily required messaging.

 

Now the other type of messaging and largely what we've talked about so far is as I like to phrase it is sort of optic messaging and that's really because part of this ransomware response is to minimize the impact on the organization. And so when we're talking about optic messaging, this is completely voluntary and you may not do it in a certain situation. You may do a lot of it in a certain situation. You may do some at the beginning, you may do nothing at the end. You may do nothing at the beginning, you may do a lot at the end. A lot of it is going to really just depend on the situation and what's best for the client or the impacted organization, but those sort of edicts of when to say, what to say, what not to say, to whom to say it, those are gonna come into play much more when we're talking about optic messaging. When we're talking about contractual messaging, the content, the recipient and the timing is largely gonna be dictated by contract and same with statutory messaging. So while we do have some wiggle room in terms of how we're going to message the incident, both from a contractual standpoint and a statutory standpoint, really we want to use optic messaging in a way to minimize the impact on the business. And that's a really... Messaging is really a great avenue that you can use and really as outside council can offer, a lot of insight in messaging to really help reduce the impact of the incident on the organization and to preserve the relationships with the customers as well as with employees.

 

So we're gonna focus now really on sort of that third category of messaging, that optic messaging. And we're gonna talk about who are we gonna message and again, it's largely gonna vary on the type of incident, the type of organization, the potential recipients of the information, the type of information the organization collects. Sometimes it may be of great value if as an organization, you know that certain information belonging to an important customer was not at all impacted and it may make great sense to let that customer know we had an incident, we are investigating. Here's what we do know as of now that none of your information has been impacted. That's a positive statement to make to that third party. So that's a perfect example of when you may wanna get out messaging right away. Conversely, you might have a situation where you have a very important third party whose data you house and you don't know if their data was impacted. So it may make sense for you to wait a little bit longer to message them while you have had a chance to figure out if that company's data has been impacted.

 

Now internally, you wanna keep the messaging limited. And what do I mean by that? You don't wanna tell everybody necessarily. Again, a lot of that is gonna depend on the circumstances, but certainly when you're talking about negotiations of a ransomware and we'll talk more about that briefly, you wanna keep that scope of people smaller because you wanna keep that information in close contact. You don't want it circulating because as information spreads, the message itself often gets distorted and so you wanna keep that close circle as much as possible. And again, here's some examples of when if the employees can't come into work or employees have seen a ransom note or customers can't access your network, those are sometimes instances where you kinda have to say something because not saying something is probably gonna be more problematic than saying something.

 

So we're gonna talk about when to message. A lot of that, again, is gonna depend on the circumstances. To the extent you can, delay without harming the company. I always recommend delaying and the reason for that is whenever you're going to send out a message, people are gonna ask questions and the more information you have which you'll be able to gather through time, the more likely you are to be able to answer their question or at least have an idea of when you can be able to answer their question. And so you don't wanna create a situation where you are letting somebody know here is the incident and then they're gonna come back and ask questions and you don't have any answers. That can lead to frustration. But again, it's a very difficult balance that really is going to depend on the situation in terms of when to say something and how to say it.

 

It's always important no matter what is to have outside counsel review the messaging because counsel not only is experienced because they've done this messaging on a somewhat consistent basis, but they will be able to avoid... Often I'll almost always see if someone prepares messaging, we have been hacked or we've suffered a breach and it's always important to not include that language in the messaging. And so the messaging itself, we want to say as little as possible, but at the same time we do not wanna appear that we are withholding information. We don't want to appear that we are minimizing the situation, but we want to say information that we know. We wanna say positive information. We don't wanna overpromise. That goes with statements like we will provide you updates every 24 hours. We also don't wanna say we have... None of your information has been impacted obviously if we don't know that. But we can say different messages like based on our investigation to date, we have no evidence to suggest that your information has been impacted.

 

That's a message that I often recommend sending because again, it always depends on who your audience is, but if we're talking about third parties, their main concern is what about our information. Obviously they have concerns about the company, but their company is not the one that's been attacked so their company is not the one that's not operational. Their main concern is data. Now employees of the company that's been attacked, they wanna know if they're gonna get paid. Are they gonna be able to come into work? And if not, can they get paid regardless? Are they gonna miss, is payments... Are payments gonna be delayed for payroll? So if you know that as an organization, payroll's not gonna be impacted, that's an important message to relay to the employees so that eases one level of concern. And so we've talked also about sort of what not to do. And here's a summary here on this slide of certain things that you do not want to say. And again, it goes back to saying hacked or breached. Make a promise that their personal information has not been impacted, again, unless you know otherwise, but again, you can get around that by saying based on our investigation to date and you don't wanna promise any timelines or for when the investigation will be complete or that you'll provide updates on somewhat of a consistent basis. Now we've been speaking of course about responding to a ransomware event and it's always important to have a plan in place before the attack occurs so your not having to identify message recipients as the investigation is or after the attack has occurred and as your response process is developing. You also wanna identify before any attack occurs, do you have contracts with third parties that require some sort of contractual notification of an incident.

 

Now those contracts may describe or define incident differently than the relevant laws. They may include an incident to be a suspected or a failed attempt even at unauthorized access whereas the law would not consider a failed attempt at unauthorized access to constitute a breach. So it's important to know who you have to message, who are the potential people that should receive a message and you also want to really have one or two people delivering that message because you want that message to be consistent. You want that message to be as uniform as possible. And when you're going to always expect, people are going to ask questions once they've received the message. And so you wanna keep that group of people involved in messaging very small to help ensure consistency, both in the message going out as well as the answers to the questions to the messaging itself.

 

So it's very important to... Before an incident occurs, before ransom attack occurs to know who are the people that are probably gonna need to know about this event. Who on my team is gonna be in charge of telling them about this? And ideally you'll have some sort of language in place that you can use as a starting point so you're not in a ransomware attack trying to respond and trying to now figure out how I'm gonna message this. That's the last thing that you wanna be forced to do. Now as much as we wanna control the message and we wanna control the people, relaying the message, making the message and the people, responding to questions after the messaging goes out, that's not always possible, just depending on the way your company is organized and so when you're talking about messaging to third parties, you want to always have some talking points in place and those talking points are gonna be very high level, very limited.

 

It's gonna be something to the effect of we discovered we suffered a ransomware attack. We hired a third party to conduct a forensic investigation. That investigation is ongoing. We will provide more information as it becomes available. You don't want anybody on your team to be forced to speculate or be forced to answer questions sort of on the fly because that just tends to create disuniformity in the messaging. But it also increases the likelihood that someone will make a mistake or overpromise something and they're not overpromising something with any nefarious intent, but it's just a normal reaction when you're trying to ease the concerns of a third party. You may try to overpromise just to tell them everything will be okay or none of your data has been impacted. And so having talking points in place helps keep the message uniform, but it also helps prevent or reduce liability to the organization for making any misstatements about the response process. And sometimes, depending on the size and scope of the event, depending on the customers, employees, their sophistication, the type of data involved, it's not uncommon where we will engage a outside public relations firm that can handle lot of the messaging. They can also monitor various social media sites to see if there's talk about the incident or the response process. And it's often an important thing to consider that I think is sometimes overlooked at when you're going through this process, you do have lots of resources available to you, especially on the public relations side to help with that messaging because as you can see, that messaging is complicated or complex, both in terms of what to say, what not to say, but also sort of when or if to say it at all. And so having an extra decision-maker and an expert in there to help with that is always valuable. So now we've talked really about messaging of the incident and that first part is really messaging to third parties, whether it's employees, whether it's customers, whether it's anybody that has data stored within your organization.

 

Now we're gonna talk about another type of messaging and that is messaging to the FBI. Now when I have an incident, usually one of the first questions a client will ask is do I have to report this to the FBI. And that's sometimes a hard question for me to answer because sometimes people very much wanna report to the FBI. Sometimes people don't wanna report to the FBI at all. And so part of I have to do is try to assess which side of that fence they are on. Are they very much in favor of reporting to the FBI or very much not in favor?

 

Here's what you should do when it comes to the FBI reporting. And first, there's no requirement to report an event to the FBI, a ransomware event to the FBI once a ransomware event occurs. I think the instinct that a lot of people have is that we wanna report to the FBI right away is because they are under the impression that the FBI can somehow be of immediate assistance and they can somehow stop the attack from occurring or identify the threat actors responsible for the attack and bring those threat actors to justice. And that's really not the case. Most of these threat actors are operating from foreign countries and their identities are not immediately known and to identify them in the short-term and then bring them to justice is just, it's just not feasible. With the FBI, contacting the FBI sort of immediately can be helpful in very rare instances where the FBI does in fact have a decryptor key and so if you have suffered a ransomware event, your systems are encrypted, you don't have viable backups, in rare instances, the FBI will have a key and they will provide that key for you.

 

Generally speaking, if you are dealing with a forensic vendor and a third party negotiator, they will know once they've identified the variant if there's a publicly available key and so really the value of contacting the FBI immediately is minimal at best. But not to say that there's no value in contacting the FBI because I believe that there is. When you're talking about notification and messaging and when I say notification, we're talking really about statutory notification and maybe to a lesser extent, contractual notification and then messaging as we talked about earlier, just messaging to third parties, letting those third parties know that you have in fact contacted the FBI, the FBI's involved. That does provide some level of comfort to some individuals that yes, in fact this is a very serious attack. The organization that has been attacked is in fact a victim and not somehow responsible for the attack by having lack security measures in place and there's a belief that the FBI will bring the bad guys to justice. And so there's absolutely an optic value to notifying the FBI.

 

But there's other times where it's very important to notify the FBI. So if you have a insurance policy and you're going to pay a ransom under that insurance policy, whether it's for a decryptor key or to pay the threat actor to delete exfiltrated data, some insurance companies will require as a condition of coverage that you in fact report the event to the FBI. So in that situation you definitely should report to the FBI. Now in addition, when you are making a ransomware payment, through OFAC, you cannot make a payment to a known threat act, excuse me, to a known terrorist organization. And so even though before you pay the ransom, you'll run an OFAC check which will essentially take the threat actor group's name as well as the Bitcoin wallet that the threat actor group is using to receive the payment and will run a OFAC check and invariably, that check will be, that OFAC check will usually be clear and you can go ahead and make that ransomware payment.

 

 There is guidance out there from OFAC that if in fact you have made a payment in violation of OFAC, by virtue of reporting the incident to the FBI you will reduce or that's a sort of a mitigating factor, reporting to the FBI is a mitigating factor in the provision of OFAC sanctions. So a lot of people are very adamant about reporting to the FBI for that reason. And generally speaking, whenever I have a client that's going to make a ransomware payment, I report the event to the FBI before making that payment just out of abundance of caution if nothing else for the OFAC sanction. But the other value in reporting to the FBI is this is the FBI will use the information that you provide them and they will often follow up and ask for additional information such as copy of the ransomware note, a copy of the Bitcoin wallet address, the name of the threat actor group, any indicators of compromise which are sort of telltale signs of how the threat actor got in. And they will gather that information across a number of organizations that have been impacted by the same threat actor group and they can in fact bring these threat actor groups down. It does take time, but it certainly has happened. And so there is definitely value in reporting to the FBI.

 

It's just important to manage your expectations. Reporting to the FBI is not going to solve the problem. It's not going to help you immediately unless there's a rare instance where the FBI has your decryptor key, but it certainly will help you from an insurance coverage standpoint to the extent that it's a requirement and it will help you from an OFAC standpoint. And it'll also be helpful to other people down the road in terms of potentially with your assistance. By reporting this to the FBI, those entities down the road will not be impacted by the same threat actor group. But again, I know that last process does not offer a lot of solace to the organization that's been impacted. So we've talked really now about two types of messaging or one is to the optic messaging to third parties. We've talked about messaging and notifying the FBI. We're gonna talk about two more types of messaging and the next one is notification. And that's really the legal aspect of notification.

 

So when an incident occurs, one of the first questions I get is do we have to notify and when do we have to notify. And usually the answer to both of those questions is I don't know and the reason for that is when a ransomware attack has just occurred, it is very difficult to know with certainty what data, if any, was taken by the threat actor and that process takes time to play out. And we'll talk a little bit about it, but assuming... So the answer to that is generally I don't know and you have to wait and see. There's always a concern among clients with respect to letting their employees know that their information is out there or when they suspect that their employees' information is out there.

 

So sometimes you'll have to do some balancing with notification and provide sort of a preemptive notice which goes to the employees that says hey, as you know, we've had a ransomware event. At this time, we don't know what information of yours, if any, has been impacted. Nonetheless, to ease your concerns, we're gonna provide you with credit monitoring to help ease your concerns essentially. So a lot of times we will reckon that approach where because clients don't like the I don't know answer, they don't the waiting game of whether they need to notify or not so we'll do that sort of preemptive or soft notification to help balance the client's concerns, help manage expectations when it comes to employees while we can still conduct our legal analysis. And so when we're talking about legal analysis we're talking now out the consumer notification. That's the letter you may have received in the mail, may have offered you credit monitori

 

ng. You may have gotten so many of these that you just throw them away. You may have never seen one. But to get to that point is a fairly complicated process. And so sometimes you'll get one of those letters and it'll say the attack happened in let's say February and you're not getting the letter until July. And sort of one of the knee-jerk reactions is what took so long. Why didn't you tell me? This happened five months ago. Why didn't you tell me? And so here's sort of an explanation why. So you have a ransomware attack. After that attack, one of the things, we talked about containment and remediation and restoration and forensic investigation. And part of that process there is determining where the threat actor went and when we talk about where the threat actor went, we're really talking about what areas of the environment did the threat actor access without authorization. And we're also talking about or trying to determine what information did the threat actor exfiltrate. And when we're talking about exfiltration, we're talking really about what information did the threat actor obtain without or acquire without authorization. And so access and acquisition are two potential trigger points that require notification. So essentially the notification is required if there is unauthorized acquisition of personal information. That's sort of generally the rule on notification.

 

Now there's of course variables for that. So one variable is some states require notification if there's unauthorized access. So just access only, not acquisition and then so that's one variable.

 

The other variable is well what is personal information. States define personal information differently. Now typically personal information is gonna be social security number, account information with a means to access that account and a driver's license number. Now some states go beyond that definition. Some states will include date of birth in that definition of personal information. Some states will include medical information in that definition of personal information. Some states will include a passport number or military identification or student records. So what you have to do is not only determine if data was accessed, you have to determine if data was acquired and then you have to know the contents of that data. And you have to know the state of residency of the information about the individual. So what do I mean by that is let's say you have a, let's say you determine from the investigation that you have a spreadsheet that was taken by the threat actor. That spreadsheet has the name, address and date of birth of an individual and that address points to the individual living in California. Now in California, notification is triggered by unauthorized acquisition so here you have unauthorized acquisition, but it's unauthorized acquisition of personal information. And in California, date of birth does not constitute personal information. So under that scenario, you are not going to have a situation that requires notification. So you'll have to know not only if the data that we're talking about was accessed or acquired or both, you'll have to know the contents of that data to determine if that data is personal information, but you have know where that individual resides because where that individual resides dictates which state's law applies.

 

So let's say we have the same exact scenario, but in this case, we have the individual's name, address as well as date of birth and this individual lives in North Dakota. Well okay, now this individual is in North Dakota. That means that we have to provide notification because North Dakota considers date of birth to be a personal information. So that's why this process of notification takes such a long time or can take such a long time because not only do you have to determine the scope of data that was taken, meaning the entire volume of data was taken, you have to also know if any data was accessed and then you have to know, you have to go through the contents of the data to see, okay, well what information in those documents. Is it driver's license, social security number, date of birth, what have you? And then you have to know where that individual lives or resides to determine if the state law will trigger notification. Now there's an additional level of, I guess, additional level here where some states have a risk of harm analysis and that risk of harm analysis can come... You can do that analysis and basically say yes, this situation will constitute a breach under the relevant law. Nonetheless, we do not have to notify the individual because we have concluded that there is a minimal risk of harm to this individual for this information to be out there. And when I say out there, accessed or acquired without authorization. Therefore we do not have to notify this individual.

 

So take that same example from South Dakota, or excuse me, North Dakota, about date of birth. If that individual was in Washington state, Washington state also has date of birth as an element of personal information. The definition of personal information includes date of birth, but Washington does have a risk of harm analysis. So one, depending on the facts and circumstances, one may conclude that under the identical situation, the individual in North Dakota requires notification, the individual in Washington state does not. So that's what makes the notification process fairly complicated because you have to go through a number of questions to determine if the situation constitutes a breach. And if notwithstanding that a breach occurred, if notification is required.

 

So how do we go about doing that? First, again, kinda summarize here. First, we wanna identify what information the threat actor accessed. Step two, we wanna identify what information the threat actor acquired because again, some states are going to require notification based on access only. Some are gonna require notification based on acquisition only and so we need to know what was the access and what was acquired. Then we have to know, okay, do we have to notify and to determine that, we have to know the contents of the information and the residency of the individual whose information is either accessed or required.

 

And then from there, you'll make your notification letters. Some states have their own requirements and then some states also require you to notify the attorney general of the state, depending on either if you identified, if you have to give notice to one individual, sometimes it'll be if you have to give notice to 500 individuals. It will just vary. And now one of the main differences between the messaging from a consumer notification standpoint versus the optic messaging is the timing and the content. You really don't have a lot of control over that because typically the timing of that, the states are gonna have different requirements for when that notification must go out. Generally speaking, as you're going through this process, you're not gonna be able to make those assessments until you've completed the totality of the investigation and then conducted your notification analysis. And so once you've done that, that is when you're gonna send those letters out. And then the content of the letters is largely gonna be dictated by state statute. There are gonna be certain information that must be in there so if you see these letters, you can see a lot of them from different organizations. They're gonna have a lot of the same information because it's gonna be a lot of sort of legally required content. So you don't have a lot of ability to modify those letters from a content wise. You do have some and it's important to do that one of, but to work with the client when you do that. One of the issues that often occurs is the client wants to be very forthright and what happened and wants to explain since this attack occurred, we've implemented the following security procedures and it's always a fine balance there because you don't wanna create the impression that the organization didn't have appropriate security measures in place before the attack occurred. So you have to be careful in how you make that messaging if you make messaging at all.

 

So really one of the main things of this old notification process here is the misconception that it's gotta be done sort of day one, that the clock starts to tick from day one. And that's just generally not the case. That said, if you, from an organization standpoint, if you have taken steps before the attack occurs to know what personal information you store and the definition of personal information is gonna vary, but do you have accounting information on premises. If so, how is that stored? How is that stored? Which service is it stored on? Do you have HR related information? What type of financial information do you collect? If you have answers to these types of questions, that really helps the notification process because you can go through based on okay, well we know that all of the accounting information is on server X. We know that server X was not at all touched by the threat actor. Therefore we don't have to worry about any accounting information.

 

And then we're talking about our messaging, we can let people know hey, our investigation is ongoing, but based on our investigation to date, none of your financial information has been impacted. So there's lots of value in knowing what you have, where it's stored because that really can come into play when you're talking about a notification. So we've talked about sort of general messaging, we've talked about messaging to the FBI, and now we've talked about messaging from a legally required standpoint.

 

Now the last thing I wanna talk about in part two is really messaging with the threat actor. And so this is question that comes up quite often which is you reach out to an organization that's had a ransomware attack. The organization has a copy of the ransomware note and a couple of things can happen. Sometimes the organization will say we do not negotiate with terrorists. That is our company policy and therefore we are not going to reach out to the threat actor. And I try to sway clients that take that position off of that position. And I do so for a couple of reasons. Now one, there's a misconception that by communicating with the threat actor, you have somehow committed to making a ransom payment and that's just simply not the case. And so there's a lot of information that can be gained by communicating with the threat actor and a lot of time can be gained by communicating with the threat actor.

 

So if you take the position that you're not gonna communicate with the threat actor and let's assume for this purpose the threat actor has taken data as part of the ransomware attack. After a certain number of days, if you haven't reached out to the threat actor, the threat actor can do a couple of things. The threat actor can start to contact your employees. The threat actor can start contacting third parties and basically telling them that hey, this organization has your data and they're not doing anything about it. The threat actor can go ahead and publish the data so that's something that if you don't reach out to the threat actor, you're going to aggravate the threat actor and that increases the likelihood that the threat actor is going to embark on some of those activities. And none of those are activities that you wanna have happen while you're in the response process. So if nothing else, reaching out to the threat actor can definitely buy you time because you can reach out to the threat actor, say, "Hey, let's start to negotiate." And as the negotiation process goes on, the threat actor doesn't really have an incentive to publish the data because one of the things that you're paying for in a ransom negotiation when there's data that's exfiltrated is for that data to not go beyond the threat actor.

 

So again, remember the threat actor is motivated by money so if the threat actor is publishing your data, then the value of whatever you pay the threat actor is gonna go down because that data is already out there in theory and that's generally what happens. Not always, but generally speaking. Then the other aspect of why it's important to reach out to the threat actor is especially sometimes the ransomware note will say they took data when they actually haven't. Sometimes the ransom note will not say anything about exfiltration of data and so if you communicate with the threat actor, you can usually determine pretty early on if the threat actor has in fact taken information and you can sometimes determine the scope of the information that the threat actor has taken, just depending on the threat actor group and the communication.

 

Now generally speaking, you'll be able to determine that much sooner than if you conduct a forensic investigation or if you wait for the forensic investigation findings. And again, sometimes when you're doing a forensic investigation, the findings will be such that you cannot determine if data was exfiltrated, whether it's because of the threat actor's anti-forensic activity or if the threat actor has or if the logging has not been enabled on on your end. So you can get information from the threat actor, information generally sooner than you would if you were waiting for the results of the forensic investigation and sometimes information that you wouldn't be able to obtain from the forensic investigation.

 

So those are really two important reasons why I always recommend contacting the threat actor even if you don't know if you need a key or even if you don't wanna pay for a decryptor key or you don't wanna pay for the deletion of data. One, you're gonna buy time and sort of diffuse any aggression from the threat actor. And two, you're gonna be able to get information from the threat actor. Now what are some of the sort of the skeptical concerns when you're talking about talking with the threat actor? Again, it goes back to trust and as I've stated a number of times now, this is not an issue of trust. It's an issue of money. And the concern is often oh well, if I pay the threat actor for a decryptor key, I don't have any guarantee that the key will be delivered and I don't have any guarantee that the key will work. And those are of course valid concerns. There is no guarantee here.

 

And let's say we make a payment and the threat actor doesn't provide us with the key. It's not like we can sue the threat actor for delivery of the key. There's no recourse here for the threat actor not following through, but my response to that is usually these threat actor groups that we deal with are very good about delivering the decryptor key. And in many cases, these threat actor groups have, well I'll call it sort of technical support where if the key is not working for some reason, you can reach back out to the threat actor. The threat actor can troubleshoot situations for you. I've had many situations where we've been on communications with the threat actor for a couple of weeks after receiving the key to work through issues. And why does a threat actor do that? Not because a threat actor is a good person, but the threat actor does that because doing so increases the likelihood that the next victim will in fact pay for key because that victim will know that if you pay, you will receive a key and that key will work. And so that's where the threat actor's incentive lies.

 

Now that's not to say that there haven't been times where the threat actor promised to deliver a key and a key was not delivered and then the threat actor goes completely dark and you have no way of communicating with the threat actor. So there is definitely a risk, but usually if you're at that point where you need a decryptor key, that should be really your last resort. And so it is a risk, but you really don't have another viable option. Now that sort of situation is a little bit different we're talking about paying a threat actor to delete data because here again, the threat actor doesn't have an incentive to keep the data because it's just taking up space. The threat actor generally doesn't have an incentive to go through the data piece by piece to figure out okay, well now I'm gonna sell this group of social security numbers, I'm gonna sell this group of driver's license numbers. That's not to say that it can't happen or doesn't happen, but generally speaking, the threat actor just wants to get money and wants to delete the data to move on to something else.

 

So again, can you trust that the threat actor will delete the data? Generally yes. It'll depend in large part on the threat actor group. Now there's some threat actor groups out there that have a bad reputation when it comes to this. But generally speaking, there are threat actor groups that have a good track record of deleting the data. And when I say deleting the data, obviously they're providing proof of deletion, but we are not finding that data out on the dark web after the fact. And that's sort of how you get comfort that that data was in fact deleted. Really what's important is that data is not exposed on the dark web. And generally speaking, that becomes the case, but it's important when you're communicating with a threat actor again, to remember the purpose. The purpose for the threat actor is this is ransomware. This is for money. And so the threat actor has a financial incentive in not... Or the threat actor has a financial incentive in complying or doing what he or she says she will do because that increases the likelihood the threat actor will get money. So here we're just talking about some common objections. We don't need a key. We don't negotiate with threat actors or terrorists. We don't have any trust that we're going to get that information from the threat actor or that the threat actor is not gonna deliver on his or her promise.

 

And here's just sort of a summary, what we talked about in terms of why it does make sense to speak with the threat actor. We can keep the threat actor at bay. We can get some information about how the threat actor got in potentially. We can determine the scope of exfiltrated data potentially and sometimes you get a key actually and sometimes that's what you need to get back to operations. So when you're communicating with a threat actor, it's always important to just have one per person doing the communicating and responding to the threat actor. And this goes back to one of the earlier things we talked about in step one or part one of this series which was one of the things to not do once you realize you're the victim of a ransomware attack and that was to contact the threat actor on your own. It's always best to have the professional negotiators be the ones that are contacting the threat actor. They're familiar with these threat actor groups. They know what techniques work, what don't work. They know what to say, what not to say and they know how to say. A lot of times it's in broken English because you're dealing with foreign attackers and so there's really an art to this process and a lot of times when you're asking a client to give us what you want us to say, the client will create a long list of hey, we're just a small company. We don't have resources and just a long thoughtful paragraph of information which is very compelling, but it's not gonna be effective when you're dealing with the threat actor. The threat actor doesn't care so much about that and if they do, they're not gonna read a very long message. So that's why one of the reasons why it's very important to have your trusted negotiator being the only one doing it.

 

Now also usually the ransomware note itself is not gonna tell you the demand. Sometimes it will, but usually no. And so it's always important to know what that initial demand is because if the initial demand is very small, that may completely change your response process. You may say well this is this a nominal amount of money. Let's go ahead and pay that and try to get decryptor key. Conversely, it may be astronomically high. It's a complete non-starter and you may have to then decide okay, well this is not even gonna be worth it. We can't even come close to that amount. And so you may have to alter your response plan accordingly. And then again, the concerns are always well how do we know the threat actor took data. How do we know the key works? We have ways in the process of getting proof of exfiltration. We have ways in the process of getting proof that the decryptor key works in that process before we actually make a payment to help reduce some of those concerns.

 

And so the goal here in part two is, again, it's the same as what we talked about in part one which is we wanna minimize the impact on business operations and customer relationships. And so how do we do that? Well in part one we focus on this goal or trying to achieve this goal by responding to the attack itself where sometimes I like to phrase it as stopping the bleeding. But in part two we're focused really on more on outside organization efforts where it's messaging to third parties. Now I know some of that messaging was to employees which are not outside the organization, but that aside, what's really the focus here is on messaging, who to message, when to message, what to say, what not to say because we wanna minimize. We wanna minimize the impact on them and maximize the third party's confidence and comfort that the attacked organization has. In fact, we have this under control.

 

We talked also about reporting to the FBI and the advantages of doing that. While there is no explicit requirement to do so, generally it really is a good practice to report to the FBI whenever you're making a ransomware payment. And then we talked about the legal obligation process where again, if you don't comply with the legal notification obligation process, you can expose your organization to legal liability for failure to comply with these statutory requirements and that's an area sometimes where organizations will say I just wanna get back up and running. I don't care about any notification. And so that's sometimes an area where either it's really top of mind where either an organization is hey, we gotta notify, notify, notify or it's I don't care about notification. I just wanna get back up and running. And so it's really important in the response process to manage the expectations about notification. And as we talked about in this presentation, notifying is not as simple as okay, here's our list of people. Here we're gonna notify them. You're gonna have to identify what data was taken, what data was accessed, the content of that data, the individuals whose data was taken or accessed, where those individuals reside and then analyzing the applicable state laws to determine A, if this is a breach, B, if this is a breach that requires reporting or C, if this is a breach that does not require notification and then you have to comply with the notification obligations, again, another reason why it's very important to have outside counsel involved when you're responding to a ransomware event because outside counsel is best positioned to make those legal determinations for you. And then the last thing we talked about here is this sort of threat actor communications and wanting to disabuse the notion that just responding or reaching out to the threat actor means that you have to make a ransomware payment as well as talking about some of the advantages of reaching out to the threat actor, whether it's buying time, whether to getting information.

 

Those are very important things to do because time is gonna help you reduce the likelihood that the threat actor is going to either publish data without your knowledge or contact employees or third parties which obviously is not something that you wanna have happen. And then it's going to help you also with your satisfying of legal obligations because sometimes when you talk to the threat actor, you'll get information about exfiltration, about how the threat actor got in that you may not be able to obtain from the forensic investigation and that obviously is gonna help you not only with satisfying your legal obligations. It's also gonna help you when it comes to messaging the event.

 

So I'm thankful you've joined me for part one and part two or at least you've let the slides play. I don't know if you've listened to everything, but when we go to part three which will be the final part, we're gonna sort of talk about out the aftermath. And that's gonna be the cleaning up process. How do we get back to where we were pre-attack and what can we do to help us in a situation, sort of what can we do beforehand before the attack to help us so when an attack occurs, we are in the best position to respond because again, everything goes back to minimizing the impact on the organization and so part three is really gonna talk about after you've responded to the attack, after you've completed your messaging, after you've completed your notification obligations. What do we next? How do we sort of clean up from the mess? So I hope you will join me for part three.