Understanding and mitigating insider risk has taken a front seat in organizational security strategies. What once was a niche concern, we’re seeing significant escalation in insider threats, particularly from nation-state actors, with insiders becoming victims of coercion or identity theft.
In this episode, Mohan Koo, president & co-founder, DTEX Systems, explains why understanding human behavior, continuous data tracking, and proactive collaborations are key components in staying ahead of evolving risks. Joining Mohan in this discussion are Janet Heins, CISO, ChenMed, and Bethany De Lude, CISO emeritus.
Got feedback? Join the conversation on LinkedIn.
Huge thanks to our sponsor, DTEX Systems
Full Transcript
[Voiceover] Connecting security solutions with security leaders. Security You Should Know starts now.
[Rich Stroffolino] Welcome to Security You Should Know, the show that connects security solutions with security leaders. Today, we’re talking about DTEX Systems and what they are doing in Insider risk management. The problem they’re addressing is data loss from insider threats.
So helping us get answers to these questions are Janet Hein, CSO at ChenMed and Bethany De Lude, CISO Emeritus. So Bethany, I’m going to start with you. Why is data loss from insider threats still a problem?
[Bethany De Lude] Well, you know, Rich, I love people, but unfortunately, the data shows us that people—the human element—still is the greatest source of data breaches when you go back to root cause. And we know that oftentimes this is not out of malice; it’s just out of human error. I send something to the wrong person, I misconfigure a setting, something happens—although there is still a fairly significant percentage that is out of malice.
So for these reasons, from a company perspective, whether the data was lost out of a mistake or it was lost because of intention, it’s still lost. And that kicks off a series of regulatory and other obligations that we would all rather avoid.
[Rich Stroffolino] And Janet, I got to turn to you. Is it just the fallen nature of humanity that data loss from insider threats is still a problem?
[Janet Heins] Yeah. I mean, as long as we still employ people, I have to agree with Bethany, right? We’re going to have a problem because, while “insider threat” sounds so negative, it’s not always the case, right? It’s not always, as Bethany said, intentional. But as much as we can train, there are still people going to make decisions on their own.
And when you multiply that by the number of employees you have, that’s how many potential bad decisions can be made.
[Rich Stroffolino] Well, we’re going to be talking to Mohan Koo, president and co-founder from DTEX Systems, about what they’re doing to solve this. But to start out, we’ve got to get three essential questions answered. So Mohan, first up: How do I explain the value of your solution to my CEO? What does your solution do and what does it not do?
And what’s the pricing model? Can you give us the preliminaries?
[Mohan Koo] Absolutely. Thanks for having me, Rich. So look, the main thing is that we’ve got to communicate in the language that the CEO and the CFO can understand, which is business risk. And that’s why we refer to it as insider risk, not insider threat, because not every insider threat eventuates—because the risk was there, right?
So we have to understand the risk in order to prevent the threat down the line.
So what about the pricing model, and what about what the solution does and what it doesn’t do?
We don’t replace the SIEM, and we also don’t replace EDR solutions. We are very focused, as Bethany pointed out, on human behavior and what insiders can do. We heard Bethany mention malice and malicious insiders—that’s one portion. We need to understand the context: When is it that people are doing things that are malicious?
When are they doing things by accident? And even more importantly nowadays, when are people getting outsmarted? Because we know that more and more nation-state actors and criminal outsiders are using insiders to do things that they couldn’t do without an insider’s access. And so we need to understand the context of those things.
But what we don’t do is we don’t replace those tools like your EDR and your SIEM, and we’re also not a compliance checkbox. So for organizations that deploy a solution like ours, they are going to find things. They are going to find sometimes, unfortunately, illegal activities; they are going to find infiltrations from outsiders, and those require escalations.
It’s a subscription license model for an endpoint license—which is a user endpoint—or a server license, which is a server endpoint. And that’s how we license the technology.
[Rich Stroffolino] Excellent. Okay, CISOs, you’ve got a little bit of a taste about what DTEX Systems is all about, but I’m sure you’ve got a lot of questions. So Janet, I’m going to get started with you. What other questions do you have for DTEX Systems?
[Janet Heins] Yeah, so Mohan, I’m curious as to how your product fits in with a suite of other security products that we have. You say that you’re not a replacement to the SIEM or the EDR, but how does it fit in and really coordinate with other products that we already have?
[Mohan Koo] Yeah, great question, Jan. So what we typically are doing is we’re ripping and replacing three different types of legacy solutions. The first one is user behavior analytics solutions, where a lot of organizations look to the UBA vendors to get their data and use machine learning to accelerate what they could do with the SIEM.
But the problem is actually the data set, so we’ve been ripping and replacing those legacy UBA solutions.
We also have been replacing the legacy UAM solutions, which stands for user activity monitoring solutions, which grew out of the defense space. A lot of the big banks of the world had deployed legacy UAM solutions, which are quite intrusive—video capture, keystroke logging type solutions. We focus on being privacy compliant, so being able to comply with GDPR for large international organizations.
And the third technology we’re replacing is the legacy DLP solutions, which were very, very difficult to deploy, difficult to scale. Lots of user problems were caused because you have to tune them frequently, and it breaks things as you’re tuning them. So those are the three types of technologies that we are replacing.
[Rich Stroffolino] All right, Bethany, what questions do you have?
[Bethany De Lude] Sure. I really want to focus on a point that you just made, Mohan, on the data set. Because when I think about insider risk, I generally think that there are two big components. One is data—your lifecycle of your data, your data lineage, where you expect that movement of the data—so understanding that expected behavior.
And then on the user side, there’s understanding what the expected behavior is of different user types. And then when there’s misalignment between those two, that’s when you likely have a risk event.
How do we accelerate getting from, “We’ve just installed your product, we’re getting up to speed,” to when we start getting value in identifying what are true risk events that require our in-depth analysis?
[Mohan Koo] Great questions, Bethany. So the first thing is, in order to do insider risk management effectively, you need to have a continuous audit trail. That means we need to collect all of the data about what’s happening in the environment, whether we think it’s interesting or not, because we never know which data point is going to be useful.
And that’s something that’s very different to what EDR vendors do, because they are mostly trigger based, hunting for very specific types of things that happen. What we’re doing is we’re collecting all that audit trail all the time and doing it in a privacy-compliant way.
Then what we can do is look for risky behaviors, and when we see a risky behavior, we simply assign a risk score to that behavior. And a lot of people think that it’s about anomaly detection, but it’s actually not. Anomaly detection—you know, humans do anomalous things every day. If we’re alerting on anomalies, we’re going to be drowning in false positives.
And that’s what a lot of the legacy UBA vendors did.
So what we’re doing is we’re assigning that risk score to each and every behavior, and then we’re aggregating them around a specific either user, a device, an application, or even a file. So you mentioned the words “file lineage.” That’s a very, very important aspect of what we do. Every time a user touches a file or does something with a file, we’re actually taking a hash of that file at the same time.
So we can track and trace it throughout the lifecycle of that file. We can even go back and see who created that file—are they one of the “brains trust,” are they an engineer or somebody that’s creating high-value IP for the company? And then subsequently, how many people touched that file? Where does it exist?
How many times was it renamed before it leaves the organization? So all of that is important in the risk scoring.
[Rich Stroffolino] It’s a free for all. So Janet, if you’ve got something, just jump in.
[Janet Heins] Yeah, I do. So whenever I think of bringing in a new tool, even if it’s a replacement of something I already have, I like to look at what it’s going to take to actually operationalize it and run it, right, and maintain it through its life at our company. Can you talk about that a little bit?
How your customers onboard this product and what else it has to hook into, and what you would need to hook into to make it work? What are the resources required—the people?
[Mohan Koo] Absolutely. It’s not linear. We have customers that are extremely large. Our largest customer on the planet is one of the largest banks in the world. They have 850,000 licenses of our technology deployed on every single computing device. They have a whole team of people that manage that because we’re detecting things and reporting them and escalating them all of the time, which you would expect.
We also work with much smaller organizations. We work with high-value intellectual property organizations that have a very small user base—like 500 users, Formula One race teams, for example, that have that high-value IP. And they have one person that is not full-time running DTEX—maybe 30% of their time.
But when an incident does happen and it has to be escalated, other people from the organization will dive in on that.
So it’s mostly around when something is detected, how are you escalating that through the organization? Inevitably, you’ll touch many individuals that have to dive in on the problem and be a part of that escalation process. So there’s many different scales in there.
[Bethany De Lude] I’d like to pull the thread on something that Janet said on getting time to value on something like this. Are there any kind of a priori conditions that one should have in place before deploying a product like this? Like should you have data tagging/classification in place, or will the tooling accelerate where there might be a gap?
[Mohan Koo] It’s not essential to have any data classification or any pre-prepared sort of “crown jewels” asset list, if you like—although it is helpful when people do have that, because they’ve already been thinking about the problem, they’ve already been understanding how data is used in the organization.
So that kind of intelligence is helpful in the process and it’s helpful in setting up rules and setting up risk scores, but it’s not essential.
What is essential, though, is that we create a baseline of user behavior before we actually start setting alerts into the system and start looking and hunting for behaviors and scoring those behaviors. So we typically say that you need 14 working days of activity to create a baseline for any user or any behavior.
So we require that 14 days’ worth of data collection at least before we start to actually switch the system fully on.
[Janet Heins] One of the things I asked in the earlier question that we can maybe follow up on is, do you need data from us—does your system need data from us, like our employee base, right? You had talked about titles, an engineer versus a different person. Do you need that information in your system?
And then, do you connect into or feed into a SIEM so it’s not another pane of glass that my team has to look at? It actually comes in the same place everything else comes in?
[Mohan Koo] Great question, Janet. So the first question was, do we need anything from you? The answer is no, we don’t need anything from you. But sometimes additional information is very, very helpful. For example, Active Directory. You might have your users already grouped in Active Directory. Sometimes that’s extremely helpful and sometimes not so helpful, because lots of organizations have AD forests that are not up to date, no matter how hard they try to maintain them.
In which case, we would rather not have that data come in. So there is definitely a process of elimination, and there is some consultative process that happens at the beginning. It’s obviously more of a consultative process the larger and more complex the organization is—much simpler if it’s a smaller user population.
So can we work inside a SIEM? Absolutely, we can. We work with all the major SIEM vendors. We integrate into all of the major SIEM vendors. We work very closely with Microsoft. Google is a shareholder of ours, so we obviously work very well with Chronicle. And Splunk—most of our customers in the larger enterprise space have Splunk.
If you are a very sophisticated customer, you would have an insider threat team or an insider risk management team. They would work in DTEX exclusively. We do everything from detect to respond to case management independently in our end-to-end solution. However, an organization like a large global bank will pull our raw data into Splunk to help them do threat hunting for things that they have struggled to hunt for in their environment from the SOC.
Does that kind of make sense? So sometimes there’s a dual implementation of the technology.
[Rich Stroffolino] All right, well, Mohan, what’s the one thing we didn’t ask about that we need to know about DTEX Systems?
[Mohan Koo] Yeah, so I would say that actually in the last six months or so, insider threats have taken a pretty extreme turn, where we are focused on some big nation-state infiltrations, particularly DPRK. People know that IT workers are now a target and are infiltrating large critical infrastructure organizations.
But what they may not be aware of is that if you are in the supply chain, you might be a small organization, but if you have customers—or your customers have customers—that are large critical infrastructure organizations, we are currently running some pretty serious investigations in partnerships with organizations like Mandiant and the law enforcement authorities across the Five Eyes countries, where it’s actually much more pervasive than we thought.
And in many cases, the individuals inside our organizations are actually the victims, so they are being coerced to do things. In other cases, there are identities of legitimate people out there—legitimate Americans, for example—that do not know that their identities have been compromised and used to gain employment at another organization.
And this is a huge, huge issue that we are now digging in deeply with the law enforcement authorities, with the intel agencies, and with partners like Mandiant to hunt for. And so, I think nation-state infiltrations is now a problem that doesn’t just sit with critical infrastructure.
[Rich Stroffolino] That’s about it for this episode of Security You Should Know. To learn more, head on over to DTEXSystems.com. Thanks to Bethany De Lude and Janet Hines for helping us learn more about DTEX Systems, and thanks to Mohan Koo and DTEX Systems for their time and being game to answer all of these questions.
Thank you for listening to Security You Should Know.
[Voiceover] That wraps up another episode of Security You Should Know. If you like this program, please subscribe, tell your friends, and leave us a review. All companies showcased on this program are sponsors of CISO Series. If your company would like to be spotlighted and interviewed by our security leaders, go to our contact page on CISOseries.com or just email us at info@CISOseries.com.
Thank you for listening to Security You Should Know, connecting security solutions with security leaders.