Security Confidential S1 E9 Tyler Smith

Manoj Tandon: Welcome, everyone. Welcome to Security Confidential. And this week we are going back to our topics of cybersecurity, and I am being joined by my partner, friend, and co-founder of Dark Rhino Security, Mr. Tyler Smith.

Tyler Smith: Hey, everyone.

Manoj Tandon: Thanks for joining us this morning, Tyler. It’s a little early for us, but what the heck? We gotta take—the sun is allegedly up outside.

Tyler Smith: That’s right, somewhere. Coffee isn’t yet, so…

Manoj Tandon: Hey, I got well—I got hot water, not coffee. It is too early.

Tyler Smith: See, it is too early, man. You know that.

Manoj Tandon: Because the downside—I always get hit with the downside of coffee and I don’t like that. It’s the inevitable ebb of energy.

Tyler Smith: Yeah, it’s like this: if I have a great cup of coffee in the morning, I’m bright and awake, and then about three hours later, it’s a steep…

Manoj Tandon: Yes, yes. It’s like I need to find a couch and take a 10-minute power nap.

So, hey, welcome back to the show. It’s been a while since you were last here. And we’ve been doing all kinds of topics on Security Confidential here, and we really want to get our audience… You know, we want to help them individually and professionally and also give them some technical tips that perhaps they can apply in their own practice or give the general audience.

I mean, most of our listeners are not hardcore cybersecurity practitioners. From what we’ve seen, they’re 18 to 30-year-olds and they run the gamut. So we want to, you know—but they do have some interest in cyber and perhaps we can make them safer. So…

Tyler Smith: Okay. Yeah, yeah, yeah. So, yeah, I thought today we could talk—yeah, go ahead. All right, go ahead.

Yeah, I thought today we could talk about EDR. Some of the things that you should try to do inside of an organization that, at least, I’ve found work well. So, I guess just starting off, a lot of people think you can just install an EDR tool.

Manoj Tandon: I’d like to pause just for a second because there’s a whole bunch of people that don’t know what EDR is that may be listening. Good point. Could you…?

Tyler Smith: Yeah, so EDR is just a catch-all phrase for Endpoint Detection and Response tools.

Manoj Tandon: Okay.

Tyler Smith: Essentially, any tool that’s going to protect the endpoint or, at the very least, let you know when something’s gone wrong with it—that being the endpoint that a user would use inside of a company or even a server.

[Music]

You deploy this tool to it, you monitor its outputs within whatever console it has, and then you respond when you see things that are concerning, such as any indicators of compromise.

Manoj Tandon: Now, there’s a whole bunch of companies that do this. I mean, I think CrowdStrike seems to be the darling of the industry right now. Then there’s Carbon Black, and you know, we’ve built our own service around a technology called InfoSight. So, and I think Cylance also has some capability in this area. So there’s a host of things there.

But you’re saying that, in general, when you’re deploying this, there are some things that you have to be cognizant of, it doesn’t matter who you’ve picked as your hammer of choice, right?

Tyler Smith: Yeah, and this will change from company to company, but really where it becomes important are companies that are creating things like new programs or applications, or they have custom scripts that they run.

Manoj Tandon: Okay.

Tyler Smith: The reason is, sometimes elements in those will be detected as malicious. And so if you’re using a tool—and Cylance was the one I had in mind—

[Music]

with Cylance, you can deploy it in a monitor-only mode. A lot of companies get to that point and they stop. And they’re afraid to turn it on because they don’t want to upset any of their users.

And that is a valid concern. You don’t want people outside of your door, you know, figuratively with torches and pitchforks, calling for your head and the removal of the tool that you just deployed.

So, one of the strategies that’s worked for me—and by no means is this my idea; it’s just one that I picked up over time—is using a DevOps kind of approach to deploying the tool. Whether it’s Cylance, CrowdStrike, or Carbon Black, as well as they’ve been developed and designed to not alert on things or block things that are acceptable, it’s still going to happen. It’s still going to block stuff that people are using.

And unless you have a lot of time on your hands, getting to the bottom of that isn’t really going to be possible. So usually what you’re going to do is, as those things come in, you’re going to globally white-list them, or you’ll white-list them or mark them as acceptable.

Manoj Tandon: Excuse me. Well, I imagine if you’re a development shop, in the early stages of the deployment, you’re going to have a lot of those.

Tyler Smith: Yeah, it really depends on what you’re developing. If it’s cut-and-paste, standard development stuff, you should be fine. But nevertheless, it really doesn’t matter what you’re doing. As an end user inside of a company, whenever security gets in the way of doing business, it’s a very unique pain.

Manoj Tandon: Yes.

Tyler Smith: One that we are familiar with firsthand.

Manoj Tandon: Oh yeah. And there’s no way you can be in security and not have this experience where someone is calling you up and saying—just short of being rude, and in some cases not short of being rude—saying, “Who do you think you are blocking my…” insert whatever thing they’re trying to do here. “This is really inconvenient. I don’t think you understand.”

Usually what I’ve found is, especially in an organization that’s never experienced a large security initiative, you’re going to catch the brunt of everything else going wrong in people’s lives.

So, Tyler, when you take this DevOps approach, explain that approach a little bit. Are you initially deploying into an isolated environment? Forgive me, not being a cybersecurity practitioner on a day-to-day basis, I may use the wrong terminology, but it’s okay.

Are you suggesting you first start and create an isolated environment, maybe deploy the tool in that environment, get the feedback, whitelist things that you know are going to naturally come up, and then roll it out to the masses? Or how does the DevOps approach work?

Tyler Smith: Basically, the idea in a nutshell—and this is kind of my understanding, so don’t freak out if you’re like, “That’s not DevOps”—it’s inspired by DevOps.

Manoj Tandon: Glad you said that so that when we get hate mail in our comments, we can respond to it. But I really hope we don’t get hate mail for this.

Tyler Smith: But yeah, it’s inspired by DevOps. I think the whole goal is we’re not expecting it to be a complete success immediately. And that’s the key to it. We know that there are going to be problems, so what we want to do is mitigate the impact of the issues as we’re doing the deployment.

And the way we do that is by planning ahead. You mentioned an isolated system. That’s not really necessary in this instance. There are a few where you’d want to test things. A great example of that would be Okta. You want to lab the deployment of that before you try and apply it to a user environment. Otherwise, you’ll get really angry emails from people.

Manoj Tandon: Yeah, well, you’re shutting down access to people’s systems if you mess that up, right? So they can’t…

Tyler Smith: En masse, yeah. You shouldn’t run into anything that terrible unless you just crank everything up to 100% and deploy your EDR solution.

And so the goal is to identify—first of all, identify the different groups within the company. And you can start at as high a level as you want. Generally, it’s going to be based off of business units.

So break it down into things like Operations, Human Resources… If you have a development team, those folks, and then if you have IT, break them into their own wing. And then within those, if you need to go further—if it makes sense to go further and fragment those out—you can do so. But the key is not trying to take the entire company on as though everyone were doing the same thing with their machines.

And that’s the real key, because people who are in Human Resources don’t use the same applications necessarily as people in Finance, let’s say. And they definitely don’t use the same applications as people in IT.

So setting it up so that you’re not deploying the same agent, the same configuration to people across those different environments because they’re not using the same apps, they’re not going to the same websites. They are more likely to have unique needs as far as accommodating applications that might run afoul of your EDR tool.

Manoj Tandon: Let me ask you this: one of the statistics out there is that an advanced persistent threat (APT) is usually in the environment 200-plus days before it is activated, because these bad actors want to exfiltrate the data first.

So even if you have great backups, which companies have gotten wise about and they can restore their systems, they’re still going to release your data and they’re still going to hit you for ransom.

Tyler Smith: Yeah. Unless you… I would love a way to set them up to just pump them full of fake data and say, “Go right ahead, release it. Please, be my guest.”

Manoj Tandon: Yeah, the honey pot.

Tyler Smith: It’s…

Manoj Tandon: But where I was going with this is that there’s a significant probability that when you’re deploying your initial EDR tool, you might have something present in the environment. And you’re saying that we have to account for exceptions.

How do you actually capture that in your baseline? That activity that might be taking place—how do you find that or baseline appropriately so that an initial rollout, without locking everything down, without shutting it all down and saying, “We need to go process by process to make sure that the environment is clean to begin with”?

Tyler Smith: So the beauty is, if you’re dealing with a decent tool, it should allow you to do that by design. And the way that it works is generally, when you do the deployment, you’re going to be monitoring. You’re not blocking, you’re not taking actions like deleting files or anything drastic like that.

And then, again, they should have some kind of quarantine functionality, so that can be your next step, and you kind of do it in a tiered approach.

So, you start off with just monitoring, and you can go into the console and you can see what alerts are popping up. Then it just takes a little bit of work to really dive into those things that come up as an alert and see what they are. And so that’s where that goes.

Some of the things, as you look at them—it’ll come up as an alert, you’ll open it up, you’ll see what it is, do some research. You can go to—if you Google Hybrid Analysis, there’s a tool called Hybrid Analysis. I can’t remember it right off the top of my head. I’ll try and find it for everybody.

It’s one of those things that you just do as you’re in the process of ripping through stuff, so I apologize for not knowing it ahead of time. But you can take the information that you found there and go and look there. You can go to a website such as VirusTotal for more information. You just hit up these different sites.

And also, if anybody’s got any other good ones, please throw them in the comments. But you just do that kind of checking on things and it should emerge pretty quickly what’s really bad and what’s not bad or just a false positive. Then you can go from there and make adjustments.

But most of these tools nowadays are very, very good at being accurate most of the time. It’s not like deploying a Data Loss Prevention rule where you’re telling it to give you all the credit card numbers it finds. That’s tremendous amounts of false positives.

These EDR tools are very, very accurate in detecting malicious software and processes that are previously unknown. It’s amazing how far they’ve come in the last four years. It really, really is. They went from being pretty alright—acceptable, but they needed a little bit of work on the front end to get them to the right place—to, now, they are much more accurate in their detections.

Manoj Tandon: So, the key is to break up the company so that you can create policies specific to the different parts of the company per business function, right? That’s the easier way to do it.

Tyler Smith: The next step to that is finding User Acceptance Testers (UAT) inside of those groups. You don’t need—the sample should be representative of the size of the whole. So if you have 21 people, maybe that’s one person per group that you identified. If you have 21,000 people, you should maybe have more than that because the likelihood across those groups… and it may even make sense to break into smaller groups than just IT, Finance, etc.

Manoj Tandon: But you need to have a representative sample, right?

Tyler Smith: Exactly. And the idea behind that is statistically valid.

Manoj Tandon: Yeah.

Tyler Smith: And the reason that you want to do that is because rather than having everyone from Finance beating a path to your door because you turned on quarantining, let’s say, in their Cylance deployment, you’re just going to have one person who’s really mad at you.

And they understand it because you had the ability to really communicate to them and say, “Look, this is why we’re doing this, and this is why I need your help.” A lot of people are really, really cool about it. They’re willing to partner with you.

Manoj Tandon: Especially what you said there a couple of minutes ago about letting people know the “why.” I think as a general rule, that is often neglected in our industry. Cybersecurity often gets relegated to a back-office function somewhere—you know, people in a darkened room doing whatever they’re doing—and the general user population doesn’t have a sense of those silent guards, if you will, who are working.

I think if those came out more into the light and people, the user asset base—and I think the largest cybersecurity asset in the company is the people—if they understood the “why,” then they would be much more apt to cooperate and they would be much more open to adopting the policies that the team is suggesting be adopted.

Tyler Smith: Yeah. And I’ve been doing this long enough to see it: the difference between when you’re partnering with the people in the company versus being seen as, “Well, you guys are forcing this on us from…” how did you put it? “…the dark nether regions of the company.”

Manoj Tandon: Right.

Tyler Smith: Often that’s what cybersecurity means. People don’t know—they don’t know who, other than maybe a CISO, is on the team. They don’t know who does what and what they’re doing and how it impacts them on a day-to-day basis unless what you’re speaking of takes place when you deploy a tool like a new EDR platform and it stops them from doing what they are used to doing.

Manoj Tandon: Then they know what you’re doing real fast. Then they know what you’re doing real quick.

Tyler Smith: You become extremely unpopular overnight.

Manoj Tandon: So taking that sample test, what would you suggest you do next in the rollout of the program?

Tyler Smith: The reason that you want that group of users to work with is you want to be able to tailor a policy to those individuals. And depending on how deep you go, that could also include things like application control. With some EDR tools, you have the ability to turn on application control, which stops people from installing non-approved applications.

And, again, that would be something that would be more than likely specific to those groups that you’ve identified. And you’re going to need their help to do that because there’s no… believe me, if there was, I would have found it by now, but there’s no magic wand that you can wave that just imbues you with the knowledge required to configure somebody’s computer correctly.

It doesn’t matter what type; it doesn’t matter if it’s EDR or DLP. People think you can just click your heels and, “Oh yes, now I know exactly how to identify your completely proprietary information that you’re trying to stop from leaving the company.”

Manoj Tandon: Got it.

Tyler Smith: So it takes partnership with these people in the business units that you’ve identified to get these configurations set.

And the other thing is as you build those inroads with people, as you have other initiatives come up, people will remember the positive experience that they had with you and the security team, and you’ll be able to partner on other projects more easily.

That’s really… it’s one of the unfortunate things about security: it is really easy to just be seen as the people that say “no” to everything. Until you make those inroads and those connections, that’s usually where people’s conception of security stays. It’s like, “These are the guys that tell me I can’t do stuff all the time.”

Right. So once you’ve gotten to a point with your User Acceptance Testers that things are working acceptably… well, and you’re going to have to figure out what that means for you. I mean, you’re going to have external pressures like, “When is your deadline to have this thing deployed and turned on everywhere?” That’s going to be one example of an external pressure.

Another example of external pressure would be as you’re doing this, if you find something really, really bad. It is good to have it deployed. I like to—unless it’s a massive, massive, massive environment—I like to deploy the tool everywhere if I can.

Manoj Tandon: Okay.

Tyler Smith: And the only reason I wouldn’t do it in a massive environment is because merely deploying the tool could create issues in and of itself that you’d have to deal with that could sidetrack your ability to work with the UAT groups to develop those policies.

Again, you’re going to have to do that balancing act. There’s really no magic way of doing it other than just figuring it out, that I’m aware of. If somebody does have a great way of doing it, definitely throw that in.

But as far as my experience goes, the next step once you’ve got that done is, now you have a wider UAT. If it’s a really big organization, then you just expand your UAT group by an amount that makes sense for the size of the organization. Again, if you have 21 people, probably just turn it on everywhere.

Manoj Tandon: Right. But if you have 20,000, don’t.

Tyler Smith: Yeah, as you said, if you have 20,000, maybe turn it on for another 1224 and then see how that goes.

And the thing is, you’re trying to avoid that surprise of, “Oh my gosh, we picked the worst people.” They don’t do what 80% of the other people do in the larger group, and now we’ve just deployed it to everybody there and things are burning down all over the place.

Manoj Tandon: Right.

Tyler Smith: So, you know, and that’s another part of it: keep moving the ball forward, but take little pieces instead of trying to carry the whole truckload at once. Take smaller pieces, and what you’ll find is you’ll be able to move faster towards a whole solution, a complete solution.

Manoj Tandon: And this process is never going to end… I’m sorry, please complete your thought.

Tyler Smith: No, you’re right: the process… that’s the other thing about this, is it doesn’t really ever end. You want to maintain that UAT group so that, as updates come, you can deploy the updates to those folks first and make sure that it doesn’t break stuff.

And, again, they really do become your partner within the organization. They’re helping you get—

[Music]

—a good understanding of how the actions you’re going to take are going to affect the group on a larger scale.

And regular communication should be one of those things. Tell them, “Hey, listen, I’m going to reach out to you. Just know that I’m trying to get this thing done, so I know that you have your priorities, but if you could, when I reach out to you—I promise I won’t do it all the time—but if I reach out to you about something, just please try to get back to me within a business day.”

That way, you communicate the expectations fully. And if maybe that doesn’t work for you, maybe you’re like, “Hey, I need you really to get back to me in 30 minutes,” that’s fine. But communicating those expectations of what you’re going to need from the UAT group is really important as well.

Manoj Tandon: Okay. Is there a certain metric that you would consider using to say, “All right, from our UAT groups we have achieved X, so now we are able to go to a much broader company-wide deployment”? Is there a magic metric there?

Tyler Smith: Yeah, it’s one of those things that you’re going to have to sprinkle on a little bit of your own spice to. But the goal is—and what I look for is—how long between alerts am I seeing? Am I seeing an alert every five minutes? Am I seeing an alert every five days?

And really determining, based on the size of the team that you’re working with… you know, if you are an army of one, as it were, maybe you want to get those User Acceptance Testers to a point where you’re not hearing anything for days and days, weeks, maybe a month before you’re going to push it out at large.

But, again, you have that impending external factor of, “When is my deadline? When do I have to have this…?”

Manoj Tandon: Sure. I mean, everybody has deadlines. We all have deadlines, and we have to be diligent about trying to meet them as best as possible.

But then that’s a balancing act with saying, “Well, what’s that…?” That’s something new. I didn’t know that you’re looking for that time period between alerts. And it makes sense.

Tyler Smith: Yeah, right.

Manoj Tandon: And it’s not just the alert in the EDR tool. I would imagine that if you’re running a SIEM, you want to account for it there. As you’re talking, it applies to a lot of things. It really does.

Can you accelerate this process by having your threat hunting team, if you have one, inherently be a part of the deployment to begin with? Because they probably have a very good idea of what the network…

Tyler Smith: Yes, you can to a degree. The problem is, the unknown we’re dealing with here is we don’t know exactly how the EDR tool is going to see anything it might encounter. And that is really what you’re dealing with here.

There’s a legacy application that runs every Thursday and it does this function on this old legacy server. But you have to kick it off from somebody’s desktop or laptop computer. And it may be perfectly benign, but the EDR tool may look at it and go, “Oh my gosh, the way that it just reserved space in your memory mimics what we know to be malicious, so we’re going to kill it.”

There’s no way to really know that kind of stuff. One of the things that having a threat hunting team can help with is if you have an alert that comes up and you’re not really sure about it, or you want a second set of eyes, you can say, “Hey, can you guys spare like a malware researcher or something like that to just dive into this file that we found or this script that we had an alert on?”

Because nobody knows what it is—that’s really truly possible. I’ve run into that a lot where nobody has any idea what the script running is, or nobody has any idea what this application is, but it’s on this shared endpoint that everybody in this little group of people uses.

And those are really the things that you’re not necessarily trying to deal with those in your User Acceptance Testing. I mean, it would be great if everybody who had some weird custom one-off piece of software in a giant company beat a path to your door and was like, “Here, have a look at this. It’s not malicious; we made it ourselves,” or could give you that full backstory.

But having the ability to deal with what’s going to happen just normally—where it’s going to block this, it’s going to block that—

[Music]

—and dealing with that stuff ahead of time. Then as you’re going, you can deal with those one-offs as they come up.

Again, the goal behind having User Acceptance Testers is to capture things and fix things that are likely to break across the environment within that group of users. So you can apply controls that are appropriate for what they do, their level of risk within the organization.

Manoj Tandon: And I think that word there is key. As I’m hearing you describe this entire process, one thing that’s becoming clear to me is that you really can’t account for everything that is not going to happen. And you are really looking at this from a risk reduction perspective.

So just because you have an EDR tool doesn’t mean that somebody who is intent on getting in can’t get in. What it’s saying is that you’ve covered a good chunk of your bases, right? And you’ve taken the risk to a point where it is below what would be typical for your industry.

But that does not equate to, “Oh, now we’re completely safe.” Even if you hire the most brilliant hacking team and cybersecurity engineering team, you’re not going to be 100% safe. It’s impossible.

Tyler Smith: Yeah, no. And that’s why there’s the “R” on the end of EDR: it’s the response piece.

Manoj Tandon: The response piece, right.

Tyler Smith: And that is where your threat hunters would come in: getting them tied into the system so that they can dig through what’s coming up and more quickly assess, “Is this thing I’m seeing really bad, or is it okay?”

That’s where having a—wouldn’t it be great if everybody listening to this had their own threat hunting team?

Manoj Tandon: Yeah, and very few people do because they are freaking expensive.

Tyler Smith: They really, really are. Yeah. It’s truly… being a threat hunter is truly an art form. There’s some science to it, but when you’re talking about looking at things and being able to say, “Okay, where do we dive deeper next?” that’s kind of the… sorry, knock my nose—

Manoj Tandon: No problem—

Tyler Smith: My microphone over. Sorry, that’s okay, we heard that dong.

Manoj Tandon: We’ll edit it out.

Tyler Smith: My bad.

Manoj Tandon: It’s the gong show. Ding!

Okay, so let me ask you this, Tyler. If I have a very minimal budget, right, but I do something that is of interest to people enough that they want to get into my environment, am I better off investing in an EDR tool and a good next-generation antivirus and all these other technologies that we talk about on the prevention-detection-response continuum, or is putting in basic IT hygiene going to yield a better reduction in risk?

Keeping your systems patched all the time, not clicking stupid things on the web—is that going to be more effective than all these technologies? I’m curious as to what your thought on that is.

Tyler Smith: And that’s… I don’t think I won’t call it a loaded question, but that is a loaded question. It’s a completely loaded question now that I think about it.

I think hygiene—having systems patched, having trained users that look at every email with a little bit of suspect, healthy suspicion—I think that is a must-have. You have to have that.

If your systems are not patched, if you really are in a larger corporation, regardless of what size, I’m just calling them out on that.

And I think it’s easy to say that.

Manoj Tandon: It is—what, give me 10 seconds, man?

Tyler Smith: Yeah, totally.

Manoj Tandon: Not even.

Tyler Smith: But it’s really easy to say that, but it belies the true nature of what is being described in that very simple statement. When you look at updating a server, there is truly a lot of intertwined complexity to that.

Manoj Tandon: Sure, and there’s a number—you’ve got a heterogeneous environment where you’ve got different OSs running. There’s a huge amount of complexity. There are clients we have that are still running Windows XP, and they’re going to be running Windows XP way into the future, because a lot of the manufacturing systems that they use are based off of technology that runs on Windows XP, so they can’t update.

Tyler Smith: All right. So, I mean, there’s your proverbial right there: “Do I make product that makes me money, or do I become so secure that I can’t make the product that makes me money?” This is an obvious choice—the one about making product to make money, because that’s why everyone’s in business.

Manoj Tandon: Exactly, exactly.

Tyler Smith: And in instances, I think the next step past the security hygiene stuff, I think the next thing is mitigation. So, that’s all fine and well to say, “Well, we have to use this old OS, so we’re just going to do it.” It’s not so fine and well to just say, “Well, that’s where it ends.”

There are steps you can take to mitigate it. One of the things would be deploying some kind of next-gen AV or EDR tool. The other things are probably already in place, so things like limiting what can reach that device, limiting what machines are used to service those devices, and making sure that those machines are clean.

Truly trying to mitigate all of your avenues of compromise, and doing so in a sense that still takes into account, “Okay, we’ve got this factory out here, it’s got to run.” That may be the case, but just simply going, “Oh well, it’s too complicated, so we’re just going to leave everything wide open and everybody just do whatever they want,” that’s not the way to approach it.

There is a way to put together a plan that takes care of the network, takes care of the physical, takes care of the interfaces between machines and the need for maintenance.

It’s not going to be simple. However, your alternative is being completely at the mercy of chance. And let’s be real: it’s not really chance. There are people trying to take over systems; that’s literally what they do for a job.

And if you’re not taking well-thought-out steps to protect your systems, it really… and a lot of people have this idea: “Well, we don’t make anything, we don’t have any money, we’re not that… why would anyone come after us? We’re good people here, we’re a hospital.”

Manoj Tandon: Yeah, well, you know what? You might be a subcontractor to somebody that does make money.

Tyler Smith: Exactly. And if I can use your network to get into them, then yeah, you’re right, you’re good people, you really don’t do anything—but your client, on the other hand, is a wonderful target and you have opened the doorway to them. So, thank you.

And the other thing is, when you’re talking about the people that are doing this, they run the gamut of human experience. The people we’re trying to stop from taking over systems… I know people love to use the shadowy figure in a hoodie, right?

Manoj Tandon: Like the character, yeah.

Tyler Smith: I don’t like it because it ignores a lot of things about why—why do people get into hacking? Money. And that is where it all comes down to.

We were at the Recorded Future conference back when we actually used to have conferences—

Manoj Tandon: That was like five years ago, right?

Tyler Smith: No, that was like two years back, in Washington, D.C. They actually had a bunch of hackers that they, I should say, interviewed via text chat and got them to talk a little bit about their motivations and what the groups do. By and large, they want money. That’s what it all comes down to. There are lots of reasons why, sure. They’re not becoming a business person or a doctor or an attorney, right.

But it does all come back to that, and it is money. And that’s the thing: if I go to any of these companies and I go, “Do you have money?” there’s your answer.

“Well, we’re a good company, no one would hurt us, we’re good people.”

“Like, yeah, okay.”

You got money, so you’re now a target. And if I can get at your money, then I’m going to take it. That’s kind of the mentality of these guys, which in some ways is a good thing because you know the devil you’re dealing with.

To a large degree, this excludes state actors, because they are motivated by different things. And if you’re an organization that has to deal with them, then you likely have some pretty qualified people on your team that are watching out for stuff like that.

Manoj Tandon: Right. But the everyday company, they got money.

And that brings to another point: one of the things that I would imagine that before you, or during, or at some point in the cycle of an EDR tool, you want to take great stock of your assets. And be very honest with yourself.

When I say an asset, it’s not a computer system. When I talk about an asset, it is what of yours can I take that would actually be of some material value to you?

So if you’re a chemical company and you’ve not disclosed all the spills that may have happened or events that have happened, but somehow they have been logged in some system somewhere, somehow—well, I would venture a guess that that might be worth money for you to not let that get out.

Tyler Smith: Right.

Manoj Tandon: If you’re a hospital system and the surgical notes could result in massive settlement lawsuits on medical malpractice… you know, maybe some of those reports you want to make sure are properly guarded. And I don’t mean to imply that companies are doing malicious things, but these are embarrassing.

I’m just going to say—for a reason—these are embarrassing problems, Tyler. These are things that can lead to embarrassment, and companies by and large don’t do this kind of stuff.

But it’s an example and it’s a reason why you might want to pay out a ransom.

Tyler Smith: Right. Yeah. And then that’s a whole another discussion, right? “Or I will release your entire patient list.”

Manoj Tandon: Right. And your patient list might be politicians and other people that are of high value, and now their medical records are out in cyberspace. So it might be worth it to you to pay ransom.

So, anyhow, I think take stock of your assets. That’s one thing I—we don’t see often enough where people… they take stock of physical assets, they take stock of inventory, but you have to look at your information as an asset and be honest with yourself where that information is and how accessible that information is.

And I guess on that one, I will stop talking because I think we’ve run way past and the editing gods are going to have to do something here.

But, yeah, no, good talk, man.

Tyler Smith: Thank you for having me. Really appreciate you having me on the show.

Manoj Tandon: Hey, thank you for being here, Tyler. And we’ll see everybody next time on Security Confidential. Bye-bye.